LibLime's Enterprise Koha Sets Off Debate
Edited by Josh Hadro -- Library Journal,10/15/2009
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 Enterprise Koha 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 Koha, a new Software as a Service (SaaS) version of the Koha open source integrated library system (ILS), along with an entry-level hosted package for a flat annual fee of $299; the latter, called Koha Express, is the model to which most of its existing customers will migrate.
With Enterprise Koha, LibLime will focus all of its development efforts on features requested by its subscribers. The requested Enterprise Koha features would be first incorporated into the version of the software available only to the customer 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."
Responding to a seemingly anticipated pushback from the broader Koha community (those who use and develop Koha with no ties to LibLime), company CEO Joshua Ferraro also stressed in the release that "[these] are process changes, not philosophical changes."
Worries about "Forked" Codebase
Despite these assurances, others see the move as likely to "fork" the software's code—resulting in two incompatible software projects—which is 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, decried the announcement. (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."
Much of the debate surrounds how LibLime will contribute the commissioned enhancements back to the larger Koha community. Many developers are worried that large, infrequent updates increase the potential for incompatibilities and will make it more difficult to resolve software conflicts.
Developers have asked LibLime to make publicly available its under-development codebase, so that other Koha developers could at least keep tabs on new features. But this option has been rejected by the company on the grounds that the code repository "contains customer-sensitive data."
Community Governance
Other aspects of the debate have centered more on the stewardship of open source projects. 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."
While vendors have strong roles to play, he says they should not assume the lion's share of overall project management: "Libraries...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 that end, Breeding recommends the formation of a foundation (modeled on the Kuali Foundation) that would coordinate development activities and take over long-term strategic planning.
Equinox Responds
Finally, open source vendor Equinox Software, which offers development and support to the alternative Evergreen ILS, used the fracas as an opportunity to issue its own open letter entitled "The Equinox Promise." The letter sets out six pledges covering many of the issues raised by LibLime's announcement, including development transparency, code ownership, and community stewardship.
Post a comment Return to article View other article discussions
| Submitted by: | Paul Poulain (paul.poulain@biblibre.com) 10/22/2009 1:45:08 AM PT |
| Location: | Marseille, France |
| Occupation: | Koha vendor & developer |
our position on this matter : www.biblibre.com/content/liblime-koha-biblibre-and-floss (long version)
Short version :
In short, as long time members of the Koha community and an open source support company, we want to make it clear that contrary to recent publications, LibLime is indeed forking Koha. We truly believe, as do many others, that the actions of a single vendor will have no impact on Koha itself as an application, and a short term impact on the community: at best, it has gotten the community to build a proper organization, which would be a nice outcome from this bump in the road
It is important to us at this point to make it clear that we are and will be members of the Koha community, we will not go in LibLime's direction. More on that later.
| Submitted by: | Nate Curulla (sales@bywatersolutions.com) 10/20/2009 12:50:38 PM PT |
| Location: | Connecticut |
| Occupation: | Senior VP ByWater Solutions |
Since the release of Enterprise Koha, ByWater Solutions has done its best to stay neutral with the hopes that a quickly deteriorating situation would eventually turn around for the better. We held this hope not for the sake of the Koha community, for its stability is not under question, but for a fellow support vendor that seemed to be going through somewhat of an identity crisis. Unfortunately for all involved, this vendor chose a path that has stirred up much controversy, mainly surrounding the fact that their version of our community software is no longer open source. Some say it is; most say it is not. The very simple question we pose is this: Can one obtain Enterprise Koha without paying a vendor to install and support it. If the answer is no, then the software is very clearly and undeniably proprietary; and those who use it are a victims of vendor lock in. Unfortunately many of these customers chose Koha to avoid exactly that.
Regardless of the fundamental wrongs surrounding this idea, ByWater Solutions has seen it as inevitable growing pains for a developing software community and has continued with business as usual. However, there is one trend we are beginning to see that has inspired the writing of this post, and that is the growing vilification of the community and the martyrdom of the vendor who has left it. We have been recently compared to religious extremists, hell bent on banishing anyone who is less than pure from our rigid society. This is an unjust picture to be painting because in actuality, we are comprised of very passionate people, some of whom have poured their heart and soul into this project in many cases without compensation.
We think it is important when reporting on a topic such as this that elicits such strong emotions to research all areas surrounding it. An important fact not yet discussed is that the developers of Koha are not the only ones having issues with Koha being forked. Customers of the company that has forked the code are also feeling the pain. Many customers are furious that they are not getting what they signed on for and are having a hard time getting the patches they want implemented in their systems. In one instance, a customer was taken off of the company’s user list for voicing their concerns about the numerous “process changes” even though they were still under contract with the company.
The recent change in policies and participation from this vendor has prompted us to make it clear to librarians that ByWater Solutions is in complete alignment with the true ideas and values of open source. Open source is about so much more than the source code and the license; it is about the community around it. It is for this reason that the community is in an uproar. It is a real shame this major contributor has pulled away from all community participation, communication and general niceties, but thanks to the community model we will only grow stronger from these growing pains. That being said, ByWater Solutions will continue to contribute 100% of their development, continue to participate in as many community activities, meetings, and day to day chats, and continue to deliver the best service to those seeking support from a company that has built its business model around our customer’s and the community’s needs.
| Submitted by: | Nicole C. Engard (nengard@gmail.com) 10/20/2009 9:41:30 AM PT |
| Location: | PA |
| Occupation: | Director of Open Source Education |
To follow up on Owen's comment I had a friend explain it in a great way - I hope he doesn't mind me stealing his words :)
"The easiest way to explain this is, you know in word
processing there is a feature you can see the changes someone made? Well if I can see the changes I made, and the changes you made, then combining the two is much easier. Imagine now you and I take a half finished novel, that we have been working collaboratively on, I keep publishing my changes incrementally, but you instead go away and work for a year and then hand back a book, with 300 new pages, and edits to almost all the other pages."
As an author myself this was a great way to explain the situation to me - like Owen said there is no <i>if</i> about it - eventually the two version of Koha will be so out of sync that it will be too much work for anyone to merge them back together.
That is why a call was made on the Koha mailing list for LibLime to share their code in a public Git repository - allowing developers who have time to make the merges incrementally instead of trying to do it a month or two or twelve down the road.
All that aside - open source is not just about software or licensing or code - it's about community and an open source application developed in isolation isn't really an open source application. It's the community that drives open source, it's the community that keeps open source alive, and it's the community that took Koha to where it is 10 years after a small library trust in NZ decided to share their ILS with the world.
| Submitted by: | Owen Leonard (oleonard@myacpl.org) 10/20/2009 6:37:18 AM PT |
My library has been using Koha since 2003. We were the first public library in the United States to migrate to Koha, and we've made significant contributions to Koha in the years since. All these contributions were made in the spirit of open source: knowing that work done to benefit ourselves could be given away without taking anything away from ourselves. I'm sure there are customers who signed with Liblime because they believed that the contributions they made to Koha would be shared in the same way: freely and without conditions. The "process changes" which LibLime is undertaking are changes that withhold code which should be open source.
LibLime is getting "pushback" from libraries and Koha users because they're breaking the promise that Open Source users and developers make when they work together: share with us and we'll share with you.
You write, "Many developers are worried that large, infrequent updates increase the potential for incompatibilities and will make it more difficult to resolve software conflicts." This is not a worry, this is a fact: Large, infrequent updates <i>will</i> increase the potential for incompatibilities and <i>will</i> make it more difficult to resolve software conflicts. If LibLime is willing to take on this task then the controversy will go away. <i>Until</i> they take on this task, the controversy will remain.
| Submitted by: | Chris Cormack (chris@bigballofwax.co.nz) 10/19/2009 8:37:14 PM PT |
It's not likely to fork it is already a fork and until
the code is committed back it will remain a fork.
Talk is cheap, commit the code.
Post a comment Return to article View other article discussions