Karen Schneider gave a lovely pragmatic talk on understanding open source at the Iowa Library Association 2009 Annual Conference (which was a welcome change from the sometimes cult-ish “Open Source is good, Open Source will solve all your problems” rhetoric). I hope to be able to link to her slides on slideshare as soon as I can find them, but here it is in a nutshell:
I. What is open source?
Schneider started out with a definition of open source from Wikipedia (I love it when librarians aren’t afraid to use Wikipedia!): “Open source software generally allows anyone to make a new version of the software, port it to new operating systems and processor architectures, share it with others or market it.” She pointed out that sometimes you don’t even know when you’re using open source: Audacity, WordPress, Firefox, and lots of in-flight movies are just a few examples of open source software in action.
Open source, open access and fair use are all ways for people to avoid reinventing the wheel and instead build on each others’ work to solve problems more efficiently and creatively. Schneider argued that if you’re hell bent on “protecting” everything, essentially you’ll end up inhibiting progress. We all shared a laugh over cloak-and-dagger librarians who say, “Meet me in a dark room; I’ll hate you forever if you tell anyone what we’re doing.”
Debunking some common myths about open source, she claimed that: a) open source generally generates very high-quality code, which is made better by diverse, heterogenous coding communities; b) open source is inherently secure, because “with many eyes, all bugs are shallow” — enough people are looking, testing, seeing & correcting; and c) open source developers aren’t always guys in a basement with Duran Duran t-shirts.
II. Tips for evaluating open source software – 5 key assessment areas:
How truly open is it?
Is (all of) the code freely and publicly available?
How is it licensed?
Is it easy to find?
Can you follow development activity in real-time or near-real-time?
Is it well-documented?
Also see The Foundations of Openness
2. Longevity and Staying Power:
How widely is the code used?
How long has it been in use?
3. Innovation and Development:
Is there a migration path or roadmap?
What is the development planning process?
4. Community Engagement:
What forms of engagement are available — lists, chat channels etc?
How active are the communities?
5. What Support Models Are Available?:
Self-service: you install it, you maintain it, you rely on the goodwill of the community for assistance
Commercial support: you install it, you pay a company for support and development
Hosted support: you pay for a service hosted on servers maintained by a company