LibLime's "Enterprise Koha" Prompts Frank Conversations on Open Source Issues
Josh Hadro -- Library Journal, 09/22/2009
- Enterprise Koha shifts development focus entirely to customers
- Critics worry about division in the community
- Open letters address relationship between users and vendors
Typically, a revamped vendor product line doesn't result in a flurry of open letters to the community and lengthy message threads on mailing lists and blogs.
But LibLime's recent announcement of Koha Enterprise has generated just such a response, prompting many to reexamine the sometimes fluid roles that vendors, customers, and code contributors play in the open source software community.
Enterprise and Koha Express
On September 11, LibLime announced the launch of Enterprise, a Software as a Service (SaaS) version of the Koha open source integrated library system (ILS). Taking its cues from similar open source software development and support models in the broader software industry, LibLime will focus all of its development efforts on features requested by its subscriber community. Though the company currently supports Koha installations for hundreds of subscriber libraries, mostly small public libraries and school libraries, much of the funding for feature development comes directly from its largest clients.
(LibLime also announced an entry-level hosted package for a flat annual fee of $299; the new service, called Koha Express, is geared toward the opposite end of the spectrum from those targeted by Enterprise, including "small public, school and special libraries." Ninety percent of the existing customer base will migrate to this option in October, the company said. A chart comparing features and support options is available on LibLime's site.)
The requested Enterprise Koha features would be first incorporated into the version of the software available only to customers, and later opened up to other Koha users and developers. According to the company, "a public software release of each version of LibLime Enterprise Koha will occur periodically."
When asked about that timetable, LibLime CEO Joshua Ferraro told LJ the "schedule for releasing development projects fall to the sponsoring customer; when they sign off on such a contribution, we will send it to the community."
Responding to a seemingly anticipated pushback, Ferraro also stressed in the announcement that "[these] are process changes, not philosophical changes," adding "[a]ll of LibLime's development efforts will be available to the library community under an open-source license."
Worries about forked codebase
Still, despite these assurances, others see the move as likely to fork of the software's code—resulting in two incompatible software projects—and potentially detrimental to a unified Koha user community.
In a strongly worded blog post, Joann Ransom, deputy head of libraries at Horowhenua Library Trust in New Zealand, blasted what she perceives as LibLime's departure from the all-for-one nature of the development community that had supported Koha. (The Horowhenua Library Trust originally commissioned the development of what would become the Koha ILS from Katipo Communications in 1999.)
Ransom said she finds it "incredibly sad and disappointing that Liblime has decided to breach the spirit of the Koha project and offer a ‘Liblime clients only’ version of Koha. Let's call it what it is: vendor lockin and a fork."
In a post echoing some of Ransom's concerns, LJ Digital Libraries blogger Roy Tennant called the move a "shot across the bow of the open source software community."
Responding to these and other concerns, Ferraro reiterated that LibLime would eventually contribute all code to outside developers under an open source license, and that the company "has not withdrawn, and does not intend to withdraw, from the Koha community."
Code transparencyMuch of the debate over the announcement has surrounded the way in which LibLime will contribute the commissioned enhancements back to the larger Koha community repository of code.
Many developers were unsatisfied with LibLime's commitment to make the code available only after only after features had been "vetted" by commissioning libraries. Specifically, the critics cite the increased potential for incompatibilities after larger updates, making it more difficult to resolve software conflicts.
According to LibLime, the shift was deemed necessary to give priority to its customer libraries. "The main challenge we faced in the past is that our overhead for both doing development and real-time integration of that development with the Koha community was simply too much," Ferraro told LJ. "This shift in our approach moves the contribution phase of development to the end of the cycle, which gives our customers adequate time to vet new functionality and approve its release to the community."
Many on the list have asked LibLime to make publicly available its under-development codebase, so that other Koha developers could at least keep tabs on the development of new features long before they are released as production-quality components. But this solution has been rejected; Ferraro was quoted as telling a representative from a customer library, "we will not be making our [code repository] public as it contains customer-sensitive data."
Community governance
Other aspects of the debate have centered less on code fragments and more on the stewardship of open source projects and support communities representing both users and developers.
Taking a slightly more distanced view, Marshall Breeding, ILS industry analyst and director for Innovative Technologies and Research at Vanderbilt University, published his response in the form of "An Open Letter to the Koha Community." As he put it, "[r]ecent events suggest that it's time to take a closer look at the governance of the Koha project."
In the letter, Breeding (who also writes the annual automation system marketplace article for Library Journal), suggests that the success of open source projects like Koha requires input from a broader community of users and stakeholders, including those outside of the relatively small circle of developers who actually manipulate the underlying code.
Vendors of development and support have strong roles to play, he says, but should not assume the lion's share of overall project management: "Libraries involved in the use of open source software should take action to ensure that they are not vulnerable to the success or failure of any given business or reliant on specific business strategies."
To accomplish this, Breeding recommends the formation of a foundation that would assume coordination of development activities and take over long-term strategic planning. Such an endeavor, he suggests, could be modeled on the Kuali Foundation, which manages a number of higher education open source projects.
Other open source perspectives
Finally, open source peer vendor Equinox Software, which offers development and support to the alternative Evergreen ILS, issued its own open letter entitled "The Equinox Promise." The letter sets out six beliefs held by the company, each paired with a promise to uphold them, covering many of the issues raised by LibLime's latest announcement, including development transparency, code ownership, and community stewardship.
On her personal blog, Equinox Community Librarian Karen Schneider considers Breeding's open letter, and draws some different conclusions. "We simply don’t (yet) have the core competencies to do what we did one hundred years ago — design, build, and manage our own tools," she writes. "We lost our way several decades ago, and we need to acknowledge that we can’t get out of this forest on our own."
Contact the author: josh.hadro@reedbusiness.com
