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  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