(For a definition of FUD — Fear, Uncertainty, Doubt — and other open-source terms, see this open source glossary.)
So I’m sitting in my home office studying Docbook, a standard for technical documentation, when a Chrismahannukah Elf draws my attention to two PLA TechNotes on Open Source.
No disrespect to the professional association that commissioned this work, but these documents may well explain some of the “But I heard…” questions we in open source library development encounter.
Mind you, it’s worth addressing the pros and cons on any topic. When I wrote about open source for ASIST, I strove for middle ground. Yes, I do conclude that open source is a worthy path to follow, but I address its limitations and I also provide evidence for my conclusions.
These documents (which share some common language) start out well enough: open source software is free in many senses of the word — free to share, view, download, modify. There are no licensing fees for Evergreen or any other open source software.
But in the “disadvantages” section, one document states that a library may need to “do a great deal more work than anticipated to adapt the software” and that “If local development is undertaken, new
releases may not be compatible with what has been done locally.”
First, I’ve watched large teams of library developers struggled to “adapt” proprietary software, or really, to develop around its inadequacies and hidden source code. For systems of any significant size and political complexity, “turnkey” is a fantasy. What would you rather “adapt”: code that is free to view, share, and download — and discuss and debug on public lists and chatrooms — or some vendor’s super-secret code you can’t entirely view and are often bound by contract not to discuss in the open?
Second, this article doesn’t really get its head around the concept that in open source development, development rarely stays “local” (even if it starts there). After decades of learned helplessness in our own field, the idea that software developers can work in an open “collaboratory” can seem outlandish to those of us who don’t know another model, but it works. Over 150 people contributed to the most recent version of WordPress; thousands contributed to the most recent version of Linux. Evergreen grows not just with the team at Equinox but with contributions from other states and countries.
The proprietary licensing model relies on a finite number of vendors working for a commercial company. That model works very poorly in LibraryLand, where we simply can’t afford the costs that would result in truly agile research and development.
Then one article says:
The decentralized development of open source software means that progress can be chaotic and there may be delays in addressing bugs and in completing planned enhancements. … Not only may there be lack of coordination within an open source development project, there may be little attention paid to integration with other applications.
Every major open source project I know of has a development process, a project development timeline, and well-orchestrated development.
But at this point my question became, where are the examples? The citations? The sources? The evidence?
One of the documents goes on to state, “No training comes with most open source products unless a commercial vendor is retained.” But that’s how most training is provided: somebody pays for it. For Evergreen, some organizations build their own internal training, while other organizations such as SOLINET offer fee-based online courses.
Then comes the statement, “There usually is limited technical support, especially for users of the software. However, a few open source products do have training and technical support available commercially for a fee…” followed later by the sweeping statement, “Only purchasers of proprietary products can expect financial and other contractual remedies for poor response times and loss of functionality.”
Again, more head-scratching. There are really only two models for software support: you do it yourself, or you pay someone for it. Every active open source library system has a corresponding support and development company. I work for one. These companies offer support levels, turnaround times, and anything else you’d expect from a “proprietary” vendor.
Then there is Evergreen; at which point I began to wonder when these documents, dated mid-2008, was delivered to its customer. The ILS document says, “as of early 2007 several public libraries in
Georgia were using the system…” Evergreen, which rolled out in production for 258 libraries in September, 2006, was in operation in over 270 libraries by early 2007, and by mid-2008 was in 275 PINES libraries and in several sites outside of Georgia, with contracts in place for additional library agencies.
I had to struggle to finish reading the documents after this statement:
Open source software may not offer the scalability and speed of proprietary software because the easy-to-use and general-purpose programming languages used are not very scalable and are slower than other languages.
Seriously? Compared to the legacy languages used in older products?
Georgia Public Library Service wrote Evergreen because not one single vendor was able to support the needs of PINES. For PINES to grow, GPLS had to write better software — and that is what it did, building in scalability from the bottom up by choosing the right database — PostgreSQL — and a consortial-strength database schema. The statements about Perl are not just wrong, they’re irrelevant.
There is more… much more. OPALS, a small but highly viable project, was overlooked entirely. Languages are described incorrectly. Mistakes were Made, and FUD was Spread. But honestly, I need to move on to other work tasks.
I do have a post parked away about Marshall Breeding’s ALA Techsource report on open source, but here’s my summary review: while not flawless, it’s a good basic introduction from a recognized authority. Put Breeding’s report in the hands of your library administrators, and perhaps we won’t have so many “But I heard…” questions to deal with.
