Tag Archives: koha

Koha manoeuvres

Very interesting developments in the Koha community, with lots of discussion brewing since Liblime announced its enterprise version last week. Lots of concerns about forks (read also atz’s comments), and a public response from Liblime’s CEO – it’s worth following that thread.

Not being a Koha user, I don’t have much of an immediate stake in the maneuvering going on, but I was struck by Marshall Breeding’s Open Letter to the Koha community where he writes:

There comes a point where an open source software projects grows beyond what can be managed through informal channels…Recent events suggest that it’s time to take a closer look at the governance of the Koha project.

I suggest a shift from a community comprised of developers to that of a community focused on the libraries that use the software.

I appreciate Breeding’s industry reviews, but I have to say that he’s been a bit of a downer and confusion-monger on open source IMHO: late on the train, and mis-reading the terrain. The observation about “informal channels” is both inaccurate and a bit of a red herring, and so is the suggestion that “a community comprised of developers” is what needs to be shifted to one “focused on the libraries that use the software.”

On “what can be managed through informal channels,” what is he talking about? Anybody with even the minimal experience with these communities can quickly see much blood, sweat and effort goes into “formal channels,” however you want to define them: commercial support options, community investment models (foundations, vendors, sponsorships, etc.),  documentation and support, exploring business models, community growing, and so on. But does a small technology startup become Cisco Systems overnight? How many years did it take for some of the more successful FLOSS projects to ‘mature’? The fact is there is running software out there successfully implanted in a fast growing segment of libraries.

Second, many of these developers are straight from the library community and the developer orientation – to the extent that you can imply it’s a dominating community feature  – is and was needed due to the limited leadership and vision coming out of the library land to make sensible technology investment decisions. Without them, you can’t build something from nothing, and that libraries are somehow divorced from this process is ludicrous. You just couldn’t have had the success that projects like Koha, Evergreen and others have achieved without the focus being on  “libraries that use the software.”

In fact, it’s overwhelmingly the case that library involvement and control is one of the key business drivers for the selection of a FL/OSS system.

On the foundation proposal — a brash opportunistic plug for the OLE approach — this is nothing new (the open letter was posted before any of the dust settled – LOL). Foundation support has been discussed in the community for years but there’s effort and organization involved and no shortage of other high priority developments that need to be addressed.  So recent events have Liblime re-examining Foundation development, and other Koha community memberships are looking at options too. But not much interest expressed in the OLE model and further, a very challenging thing to pull off any way you take it.  Foundation support also won’t address the immediate concerns about Liblime’s direction etc.

The periodic ‘spasms’, tweaks in vendors’ business models, blowout discussions about forks, and so on – all of that is important, expected, and part of the terrain to be negotiated.   There should be no surprises here, and I’m glad to see that at least it’s out in the open for all to see and assess…

biblios.net – kudos..

Just signed up and logged onto the new biblios.net site. Although I’m not a cataloguer, this is a very impressive first launch.

It has been clear for many years now that developments towards “One Big Library” were going to radically change workflows and strategies for library automation. The promise of the network, the insane ease and seduction that came with accessible and largely free (or freer) web 2 services, cheap and then more cheaper infrastructure, and so on.

Biblios.net shows how it can be done with a clean, simple interface, and an impressive share & collaborate model that looks very compelling.

We’ve already seen great success and potential demonstrated by other ‘One Big Library’ services like LibraryThing and the OpenLibrary – still largely underappreciated and exploited imho –  and Biblios.net brings its own take on this kind of service.  But unlike LibraryThing and OpenLibrary, they have the potential advantage of being associated with a growing open source ILS community, so they already have a target audience primed for introducing this kind of service and building a community.  Cataloguing workflow is just ripe for this kind of disruption.

Also intriguing is yet another manifestation of the “mini-OCLC” model at play – only minus the Big Brother monopoly control aspects.  I say “mini” in the context of number of contributing libraries (so far), but as we move forward these types of services are not going to be that dis-advantaged by the number of shared records. According to Nicole Engard’s post,  they are starting out with  a “30 million strong shared database of catalog records” – pretty impressive for a start.

I would expect more vendor specific community offerings to be announced for similar shared repositories and types of services, even from the proprietary folks.  All of this is good for libraries, so long as the shared network opportunities are getting larger and more accessible, it can only reduce the size of our silos.

It’s going to be fascinating to see how all of this plays out.

For more details on biblios.net, there is an overview article published recently in  The Code4Lib Journal – ‡biblios: An Open Source Cataloging Editor, and a few recent blog posts from Nicole Engard and from Jonathan Rochkind.