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 not.
Jonathan
