Francis Kayiwa wrote:
> IMHO good open source software is driven by people with an itch to fix. 
> The community develops and can be cultivated around this itch rather 
> than "world domination". The project _MUST_ well documented [0] ideally 
> actively maintained. The support of this software will mostly be taken 
> care of with good documentation.

If your organization has local development capacity, and is willing to 
use it to meet a need, and is confident they will have the capacity to 
maintain the software as long as it's needed (which may be short or 
long-term) -- that's great. (Or if you personally have development 
capacity, and your organization is hands-off enough to let you get away 
with it. :) ).

And we defintiely do need more library organizations with development 
capacity that choose to use it on open source start-ups. That is indeed 
how succesful projects start. (And in a related but different topic, I 
think succesful software is seldom designed by committee).

But if you're an IT staff of one who isn't a programmer, it may or may 
not make sense to adopt an immature project. That's up to such a person 
to decide -- and if they aren't taking into account the balance of 
software maturity and local development capacity, I think they're making 
a mistake. If such a person does so without realizing the factors and 
risks involved, then if things don't go well (as I think they often will 
not), odds are someone will end up blaming 'open source'.   This does 
not do the 'open source' cause any good.  

Maturity of a product and it's community is ONE of several factors to be 
considered in evaluating an open source project, and should be balanced 
against the potential benefit of the product, with local capacities 
factored in.  It's just one of several factors, but it's an important 
one, and I think it's really a disservice to try to convince people it's