Open source in libraries: community = strength

Karen G. Schneider has a great post on Enterprise Open Source on the ALA TechSource blog:

But the truly significant activity in LibraryLand technology hasn't been vendor-driven. It has been the maturation of what I call "enterprise open source": products such as Evergreen and Koha that are robust, well-implemented library automation packages with strong development communities and equally strong funded-support models.

Hear hear! Karen examines the value of open source, and finds that it's not so much in that it's a lower-cost alternative (although that can be a persuasive argument), and not so much that you have the ability to modify the code (although that can also be a persuasive argument), but that it depends on the strength of the community to continue to exist and improve. And that makes it a very good match for libraries, because we seem to do "community" better than most other industries.

So let me take a different tack than Karen, and assume that if you've read this far that you're interested in supporting open source for your library, but maybe you don't have a programmer on staff. How can you help?

Well, there are many ways other than programming to contribute to an open source community. Evergreen, for example, just posted a call on its development mailing list for help in defining and prioritizing the requirements for its acquisitions and serials modules. If you have experience with these areas, and have blue-sky ideas for how you could build a better system, this is a great opportunity to step into the conversation. There's a bit of a parallel here to proprietary systems, although with a proprietary system it's called a "request for enhancement" and most of those tend to get filed in the distant future. With Evergreen's invitation for discussion, you _know_ the developers are happy to listen to the ideas for making the best possible product. They don't have prior baggage holding them back, so they really can start from square one - and they have a huge incentive to do better than the existing options, because they want to convince you to pick Evergreen the next time you're thinking about your next ILS.

Or you can contribute your hard-won experience and knowledge to the documentation wiki. Evergreen and Koha both have wikis to which you can contribute. Interestingly, there is a parallel here to at least one proprietary vendor, which set up a wiki (behind a password-protected site) after many requests from their user group. It boggles _my_ mind, but some of these same customers have also argued that they (the customers) should pool their efforts and write a new set of manuals for the product for which they are paying support and licensing fees. I'm sure the Evergreen and Koha projects would really appreciate your assistance in writing a good set of manuals, and they won't charge you for the privilege, either.

You can also participate simply by joining in the conversations on the mailing lists or chat rooms (#OpenILS-Evergreen on Freenode for Evergreen, #koha on Freenode for Koha). You'll take some time to get familiar with the products, no doubt, but once you've climbed over the brick walls (with the help of the others on the mailing list), you will have the opportunity to pay it back a dozen times over as others face the same walls that you faced. I see this same principle on our proprietary vendor's mailing lists. The customers do a far better job of supporting each other than the vendor to whom they're paying support and licensing fees.

And it feels good, working together to build something that belongs to an entire community. For the little bits that I've been able to do, I get a huge sense of satisfaction. It's a nice little addiction.