suggested requirement and what funding is for

[Mike Stump]

On Tuesday, December 10, 2002, at 12:54 AM, Tom Lord wrote:
> So, what, in the free software world, does one do in such a state?  I
> don't know -- but I'm certainly disinclined to just throw up my arms
> and walk away from it.

The usual method is to find a few unhappy users of other systems that 
want/use features that their current system doesn't have, or does 
poorly, and convince them to use your system.  Congeal them into a user 
community, with visibility into each other.  Start small, one two 
person teams.  Treat those users well (one user cannot be that 
demanding).  Finish off the rough corners they find.  Have them tell 
two friends.  Lather, rinse, repeat.

Kenner's company is exactly the type of place you need to use the 
software, to bad you don't understand it.  Find someone that does 
understand it to help you spread arch.

 From my perspective, cvs started from rcs, already popular, already in 
use here and there, easy import methodology (and easy export 
methodology should one want) and got into places like Cygnus (little 
tiny company), and from there to hacker communities and from there into 
sourceforge and the rest was history.

We won't notice arch, we'll notice that in 5-10 years arch is still 
around and kicking and people are _still_ using it, then we'll consider 
it.

If you have a system that can operate beside an existing system, you 
could have people use arch in front of their repository to provide them 
additional benefits for a decent cost.  The more people that do this, 
the more natural it will be for the thing just behind arch to become 
arch.

Let's take a few scenarios:

Say I have an intolerably slow cvs server (I do, meta comment, it is 
faster to pound on the gcc cvs server than our in-house cvs server, 
despite the fact the one is across the internet and the other is 
connected via a 100 mbps local connection), say I could say:

arch co backed-by:cvs:gcc.gnu.org:/cvs/gcc gcc

and then:

arch update, arch diff, arch ci, arch merge...

and have all these operations be blindingly fast.  Maybe I would want 
to use arch, even though, I could not use arch, because my central cvs 
server is just a hair beyond my control.

Maybe you haven't made that work yet, or maybe you've not told me that 
it works.

Maybe people have an overloaded cvs server that is very slow on 
branches and they now have tons of extra branches now that they never 
had before.  Maybe arch could be plugged into the server on the side of 
cvs, with cvs commits triggering arch pull commands and arch commits 
going into cvs directly.  The people on branches start using arch, 
because, well, it just kicks butt compared to cvs.  Then maybe a few 
other users start using it because they can manage their local changes 
better with all the extra neat merging functionality and ease of use 
arch provides.  Maybe over time, people just turn off the cvs part, as 
no one uses that `side' of it anymore.

Find one user willing to try arch, and make him happy.  Then find just 
one more, make him happy, then find one more...  Pretty soon, either 
you will stop and go away, you'll have oddles of users, or you find an 
equilibrium point.  The best case, is find a project that will be where 
gcc and Linux are today in 5-10 yaers time, and get them to use your 
software.  There was a time when sourceforge only had 100 projects on 
it.

gcc is a large, demanding project.  We'll consider arch, after 20-50 
other smaller less important projects use arch for a while, and have a 
good experience.  arch needs users to have good experiences with it, 
desite its shortcomings.  Maybe you should start an I hate cvs web site 
where uses can go to complain about cvs, and then find users from that 
pool.

Certainly there were shortcomings with cvs, but they were overlooked 
because it offered something that rcs didn't have, that people wanted.

Free software is hard work.