OK, this is a red-letter date; look how long it’s been since I posted.
I just listened to the February 17, 2010 podcast of the Library 2.0 gang. Two of the participants, Francis and Richard, I didn’t know, but I’m somewhat acquainted with Talin, Nicole and John. I was able to hear Talin speak once, and I was generally impressed with his thoughts and apparent technical management abilities. John I know of through his position at PTFS, and Nicole, everybody in the know just knows.
Random responses to some of the discussion topics:
> Open-source projects need a corporate sponsor or organizer (position supported mostly by John).
Well, I’m not going to try to do any kind of scientific citation, but I would like to suggest that has been the case some of the time, and for other projects not. OpenOffice may be a good example–Sun bought/picked up some obscure word processing project way back when, and turned it into the successful Star Office and OpenOffice. I think, if my memory is correct, JBoss is another example.
But then Mozilla Firefox is a counter example. While they have their own foundation now (and have had for some time, of course), and have gotten some funding here and there from corporate sponsors, they are largely self-grown.
Organization of any open-source project is probably a worthy study topic for some grad student. The <lack of> organization of Koha, for example, is at best an example of decentralized management. LibLime (LL) might have been a potential focus point for Koha at one point, but since they have moved to a de facto closed-source, proprietary system (LibLime Enterprise Koha, LEK) the True Koha Community now shuns them. PTFS as corporate leader? Well, hum, maybe. If it happens, that would only come after their purchase of LibLime, which a little birdie says might happen yet if LL has the problems the rumor mill says they might. How would PTFS handle LEK, and how would they treat Koha? If it were in the manner of Red Hat and Fedora, that would be a great, but if they were to become LL 2.0, and perpetuate the facade of an open-source Koha project, then that would provide no organizational structure either. This brings us to Sirsi, which I’ll use as a transitional discussion point.
> Talin didn’t get the air time of the other gang members, but I tried to listen carefully when he did speak. He mentioned several times that he was considering Sirsi’s possible involvement with open-source ILS projects. I don’t think it could possibly happen that Sirsi would ever have any positive organizational effect on Koha; they, especially with their Vista owners, would just be too much out of their league. Talin also mentioned his, what, happy thoughts with regard to open-source. I frankly hadn’t been aware he entertained such, but I haven’t been following Sirsi much lately, so maybe, but the open-source train, including Koha, is zipping right along and if Sirsi doesn’t want to have to make a running jump for the caboose they better stop thinking and get themselves to the station.
I’ll reiterate one of my previous complaints; one of the reasons we are unhappy with Sirsi is that we are tied to Workflows, which doesn’t run on Linux. The server runs on *nix, and Java Workflows (JWF) runs on Windows and Mac, so why the Heck doesn’t it run on Linux? That simple little thing right there raises my blood pressure 25%. I remember a year or so ago they were floating the idea of porting JWF to Linux, and wanted to know if there was any interest, and I thought, “Why the Heck do I need to express and interest? Just port the thing and be done with it!” And while you are at it, why not open-source Workflows? It’s not like you could use it as is with any other ILS, and I even rather doubt that any of the code would be of great competitive advantage to other developers, but it would give you something concrete to point to as your effort to be agreeable with others.
But to get back to the point, Koha could benefit from some structure, and it appears that may be coalescing around their New Zealand/Katipo roots, with the various support companies and users participating more-or-less equally, without a single, strong central figurehead. Nicole made a couple of quick references to this. Unfortunately, the community is certainly resource poor at this point, maybe it will become the little locomotive engine that could.
> Talin also mentioned they have been working more closely with sharing development snapshots with their partners. I’m not sure what the benefits are for the end users, but what happened with the Bluesocket partnership? That went south with hardly a word of explanation. And heck, even Microsoft, the second most secretive, closed source corporation in the history of the world, has developer confabs. None of that compares to Koha, where you can get up-to-the minute development code, alpha or beta releases, or the stable version.
> Confusion over vendor lock-in vs product lock-in? No, we understand the difference.
> What is the community crying foul about? News to me.
>Talin mentioned possibly collaborating with the open-source community on things like indexing, crawling and search. That, to me, means exposing the database contents in a way that’s easier, more comprehensive and more open than Z39.50 or SIP/NCIP.
Things have moved on since the podcast. PTFS, although they will continue to offer Koha services, is not going to acquire LibLime after all. The Koha community is moving on as well, having voted to have the Horowhenua Library Trust in New Zealand be the holder of certain Koha community assets such as the European trademark of “Koha” and the new koha-community.org domain.
I would argue that the Koha community is not “resource-poor”, although obviously it is decentralized. A large pool of developers is working on mainstream Koha, including several librarian-developers who are not working for any vendors. If vendor support is important (full disclosure: besides being the release manager for Koha 3.2, I work for company that recent started offering Koha services), there are a number of vendors committed to working on and with mainstream Koha, including BibLibre, ByWater, Catalyst, Equinox, InLibro, OSSLabs, PTFS, software.coop, Xercode, and many others. While obviously that means that coordination of development effort can sometimes be challenging, it also means that collectively there is a larger pool of developers and support staff able to improve and support mainstream Koha. It also means that libraries have a true choice if they need vended support services for Koha – they don’t have to stick to one company.
“although they will continue to offer Koha services, is not going to acquire LibLime after all.”
I maintain that it’s still possible PTFS may acquire LL. Of course, the first try fell through, but we’ll have to see how LL’s fortunes develop. If things don’t go well for them in the future (of course I have no firm knowledge of their bank statement, but something prompted them to consider a sale in the first place) then they may be more willing to come to terms at some later date.
“resource-poor”
Poor choice of words on my part. Certainly there is a wealth of developer talent, and a great user-feedback loop for continuous improvement. What I meant was there is no single, dominant cash-flush corporation playing sugar daddy, like Sun->OpenOffice, Novell->OpenSuse, Red Hat->Fedora. You are completely correct. My apologies. But hey, that did give you the opportunity to make a great point.