Koha installer software.coop has recently changed its standard terms of supply to allow us to add users to listings unless they say otherwise.

As I wrote in response to a previous comment, “My primary issue with the jargon is that it seems to be institutionalizing decisions that no longer make sense. Amazon has a website. We have an alphabet soup of software that’s getting better, but still doesn’t come close to competing with the user experience Amazon offers.”

Here’s what I was trying to get across: programmers should call the components of library website software whatever makes sense to them, but people who are buying the software (or making the decision to use open source software, whether they buy support for it or not) should focus on their website, not its components.

I think the reason we don’t focus on how people use our websites is because of our history. Some of the terminology predates widespread adoption of the graphical web and we’ve been slow to change it because, as you point out, it’s widely understood. But I think that’s the secondary reason.

I think the primary reason we’re all expected to learn arbitrary terminology is because vendors want us to buy each piece individually: the more pieces we buy, the more we have to negotiate, and each negotiation favors the vendors (they negotiate sales all the time, and as often as possible; we negotiate purchases as infrequently as possible). I’ve already been scolded by one vendor for revealing in an earlier Lead Pipe article how hard they made it for me to get an answer to a simple question: “What’s the least it will cost us to share the Collingswood Public Library’s catalog on your website?”

The answer to the Europe question is simpler: I asked someone who’s actively involved with the Koha community and that’s what was reported to me. In addition, I noticed that France’s BibLibre is the only company, aside from LibLime, that is listed as “a Major Community Contributor.” Note: I’m not diminishing other community contributors–I don’t follow Koha closely enough to have formed my own opinion–I’m just quoting what I read on the Koha Pay for Support page.

The other aside concerns the distribution of Koha. You mentioned that it has an active community in Europe. A student of mine (Germany) just wrote a thesis about Koha and noted how rarely it is used in Germany, and that it is generally not widely used in Europe. A glance at the Koha showcase (http://koha.org/showcase) shows this, although I am aware of how graphical representations like that can be skewed base on who chooses to enter themselves there. It is hard, in general, to say what Europe is these days. Countries such as Germany and, say, Hungary, are about as dissimilar as can be in many ways.

there’s a good chance that a lot of the code will be contributed by volunteers—people who aren’t even employed by libraries, but are interested in the problems and possibilities presented by creating software for library users and employees.

The work that volunteers do for our libraries can and should never be underestimated. With the current economic climate, libraries are cutting programs and staff. Hiring new programmers to write code may be unlikely. Therefore, finding knowledgeable and willing volunteers could be our saving grace.

@David – Koha uses/builds-on Pazpar2, YAZ and Zebra. IndexData are a pretty interesting company.

I haven’t changed any text in the comments above, but I’ve made some comments conform with how we try to handle links (criteria: our readers’ convenience, accessibility, and fairness). As of now, only the first mention of a company is linked, and I’ve gone back and added links to the companies that provide Koha support even if the commenter did not.

The companies listed on the Koha “pay for support” page I linked to in the original article but which have not yet been mentioned are: Strategic Data; Turo Technology LLP (see link to the Software Coop, above); CALYX information essentials; inLibro; OpenLX; Pakistan Library Automation Group; National Centre for High-Performance Computing; Tamil; Sabinet; Nucsoft OSS Labs; Anant Corporation; and LibSoul.

IRSpy (registry software for maintaining Z39.50/SRU gateways; developed by Mike Taylor)

Metaproxy (metasearch middleware; developed by Index Data)

OPALS (an ILS; developed by MediaFlex)

Pazpar2 (metasearch middleware; developed by Index Data)

YAZ family of programs (tools for building Z39.50/SRU applications; developed by Index Data)

Zebra (db server & indexing engine; developed by Index Data)

David

Yes, the decision to initiate and support an open source development project is one that should not be taken lightly. Darien Library chose to make a commitment to SOPAC on the basis of several criteria. 1) No other product exists that will do what we wanted. 2) We incorporated the design an implementation of SOPAC into our existing service model. 3) SOPAC, as a product, fills a giant, gaping hole in the next-gen catalog market and we were very confident that we would be able to pull together a development group to share in the development burden in the long-term.

With regards to the third point, that is exactly what has happened–to the extent that commercial support is now available for SOPAC through Craftyspace, who has committed back to the project some very valuable work. Biblibre (mentioned earlier) has also contributed back to the project (they did the scut-work for internationalization support, and a French translation). Add to that, active development work being done at three other libraries beyond Darien and it becomes apparent that SOPAC is a very healthy OS project.

Beyond that, your argument that these pursuits dilute our core mission makes some assumptions about what our core mission is that I might not necessarily agree with.