Having done battle with the koha code base for a few months, there have been too many times when something conceptually simple has been surprisingly difficult to express in code.
With KohaCon coming up soon, I thought I’d throw out this hypothetical question to get your creative juices flowing.
If you could do it all over again, how would you go about creating a Free library automation system from scratch?
There is much talk in the United States right now, between conservatives and liberals about “values.” The conservatives feel that we’re compromising the values that made this country wonderful, and that the liberals are doing it, etc, etc, ad nauseum. I’ve watched that discussion with aloofness, because I’m of a third opinion altogether.
But my RSS feed threw this little tidbit about “values” at me yesterday, and I just couldn’t resist. Consider the values that make an open-source software project great–it varies, of course, but Eric Raymond established in The Cathedral and the Bazaar that what made them awesome was that they served some useful purpose, and people found it, and liked it enough to chip in and help. I’m okay with that definition, for now.
In Kier Thomas’s article, he moans a little about Firefox and Ubuntu losing track of those features that made them so incredible successes, and I think he may well be right. If so, I think it behooves every FOSS project–including Koha–to pay attention. What makes this project so great? If you’re not currently developing, that’s okay, but have you told someone who is why you use Koha? What value does it fill for you and your institution? What’s the slickest part of it, that impresses you and your staff?
As developers, we’re frequently isolated from the day-to-day users of the software we develop, so we don’t know what sorts of real-world uses you’re putting it to. It happens, from time to time, that we make obsolete some feature you like. Trust me, we’re not doing it out of meanness! Tell us about the things you love, as well as the things you think need work. We need to know these things, or we run the risk, as Firefox and Ubuntu seem to be, of developing toward our own idea of what you need–which is not always correct.
A colleague of mine is very frustrated with his campus IT people just now. The library would like to run MediaWiki, but the campus IT boss will have none of it. “It’s open-source, and open-source is insecure,” he claims.
I have a big communications gap with such people–we might as well not be speaking the same language, because we have no common frame of reality to work from. This individual just doesn’t realize that, like high-fructose corn syrup, open source is in just about everything these days. This particular institution is using Apache, for instance, for all of its’ web servers. The journalism department standardized a year ago on MacBooks and iMacs (which run OS X, which has lots of open-source bits at its’ core). And yet, a huge percentage of their security-related helpdesk tickets relate to security problems on Windows Server instances. Go figure.
It’s been contended before, and I agree, that open source software is inherently more secure. In a closed-source project, the only white-hats that are looking at the code work for the project, while the number of black-hats is effectively limitless–and in fact, the bad guys take it as a challenge, I suspect, to try to hack at those programs. In LibLime’s open-source world, the number of security-positive, well-trained people that are looking at the code, finding and fixing problems, is also not artificially limited.
But the head-in-the-sand IT boss persists: “But then, everyone can see the vulnerability!” What he’s ignoring, clearly, is that anyone can fix the vulnerability, instead of having to wait for the vendor to come out with a patch. Maybe we’ll never get through to some people. But they’ll retire, eventually.
What about you? Find an open source project that does important things for you, and support it. Even a little help, with documentation, say, or even a little bit of code, or testing it out on a platform that the developers haven’t got access to, will help that project move along, and is greatly appreciated by the project team. If you’re not equipped to do that, just send the team a note, and let them know you’re using their work. They’ll appreciate that, too!
Among the tougher proprietary platforms for Open Source to gain ground in, consumer mobile devices is arguably the toughest. Google is hoping to challenge that with the release of their Android mobile computing platform and the first phone to use it, T-Mobile’s G1. Maybe now is the time to replace that chunky Nokia 3650 I’ve been hauling around for 7+ years…
I’m attending the NISO forum on collaborative library resource sharing, and heard a cautionary tale about making sure that a software project meant to be open source actually gets there.
Gail Wanner from SirsiDynix spoke today about the Rethinking Resource Sharing Initiative, an effort to revolutionize sharing of materials and services among libraries and their users. One of the products of the initiative was a Firefox plugin called GoGetter (previously known as GET-IT) that could grab information about a book from a web page and give the user a list of ways to get it, including online bookstores, the local library, resource sharing networks, Google Books, and so on.
A proof of concept was ready by June 2007 and was successfully demonstrated. However, work on it stalled — while the plugin was meant to be open source, apparently not all of the institutions involved in writing it (or employing the programmers involved) were prepared to let it go. Over the past year, various institutions have been signing off on releasing it under an open source license; while there’s been progress recently, GoGetter is not yet free. In the meantime, nobody has been able to play with it, improve it, or make it compatible with Firefox 3.
Lesson of the day: if you want to start an open source project, particularly if multiple institutions will be involved in writing it, it’s a good idea to make sure from the beginning that all parties are willing to release their work under an open source license.
A number of Koha developers and users met recently on the #koha IRC channel to discuss various project issues. Several project positions were voted on and are now filled:
The position of QA manager for 3.2 remains open. The two candidates are Frédéric Demians (Tamil) and your’s truly. No decision was made, and the discussion will be continued on the koha-devel mailing list.
Several announcements were made:
Various issues were raised that will be further discussed on the mailing lists:
The full log of the meeting is at
http://koha.org/cgi-bin/logs.pl?recall=recall&saved_query=2008-09-12%20meeting
or equivalently,
http://koha.org/cgi-bin/logs.pl?look=plain&startdate=2008091212:00:37&enddate=2008091213:30:01&search=Search
Google spiced up things in the browser world recently by releasing their own (beta) standalone web browser called Chrome. Interestingly enough, the name seems to derive from the Mozilla Firefox term for the user interface layer. The code is based on WebKit and V8, as part of Google’s Chromium project, operating under a permissive BSD license. There may be some confusion here, since Chromium is BSD-licensed, but Chrome itself seems not to be.
So does it mean that we’re seeing the return of the browser wars? Maybe a bit.
IE is still going to be on more systems, by virtue of inclusion on the most common pre-installed OS’s. But some analysts have noted that Google doesn’t need to “beat IE” in market share in order for Chrome to be effective. Rather, Google intends to influence the direction and feature-set of future browsers by providing their own freely-available, freely-applicable version. Core features are going to include powerful, reliable javascript interpretation and XML parsing, of the kind you might need for, say, Google Docs or Google Gears web applications. That is to say, this is the browser that intends from the beginning to be an application base, not just a page viewer with additional features strapped on.
In the long term, one might expect Google to use Chrome to make it easier for them to place ads more intelligently and reliably. Eventually, it is conceivable they might go whole hog and mint their own linux distro, thereby cutting directly at Microsoft’s main advantage in establishing IE’s userbase. It is quite interesting how the competitive strategies tie into each other at various levels.
The main downside for web developers now is having another level of cross-browserness to test against… and the potential privacy implications when relying on Google for so many aspects of business. Note also, the current beta is Win32/64 only. MacOS and Linux versions pending.
So it looks like this will be the week of the new browsers for me, talking my XP virtual machine to IE7, FF3 and now Chrome.
Last month in Portland, Oregon at the code4lib 2008 convention (a most impressive assemblage of library geekiness), a few of us broke out to the 24-hour bakery Voodoo Doughnut for this:
A donut, with bacon on it. A bacon donut.
I’d expected it to be strange, but the remarkable thing about the bacon donut is how unsurprising the taste is. The sweet maple and salty flavors are, as it turns out, very compatible. So it strikes me that the work I’ve been doing on Koha recently is a lot like the bacon donut: take two things people already like, we do the voodoo and make them work together in a new way.
For the OPAC, the place where this comes up most often is external content, like book cover images. Koha libraries have been using jacket images from Amazon for some time in production, internationally. It’s free and it’s broadly populated: a great feature, especially for small libraries who don’t have the advantage of a lot of subscription content services. Using their API, we can also pull and display content like user reviews, really fleshing out OPAC content.
I recently completed some commissioned Koha code for integrating Baker & Taylor images and content as an alternative to Amazon. Koha can now link to B&T ContentCafe excerpts, ratings, etc. and to their MyLibrary BookStore retail site. For design, my code followed the Amazon model, and certainly something similar could be crafted for other proprietary sources like Blackwell, Syndetics, etc. But upon reflection, I think that the entire model is already on it’s way out!
Enter Google Book Services. I’ll have more to say about GBS later, but suffice to say we now have a second, very widely available source of free book jacket images. (In fact, it may be enough to deflect calls some have been making for the Library of Congress to provide access to cover images like they do for other metadata.) The Google API is essentially javascript based and remarkably easy to integrate. How easy? Code4lib members were posting working example code back and forth within hours, and then within a day or two, other Koha users adapted their own servers to start using Google’s images. This is a great example of how OSS enables agility and adaptability.
So pretty soon we should expect that every current OPAC will have some images from somewhere, and that won’t be a distinguishing feature anymore. The next model to evolve will be to allow ajaxy failover from a ranked menu of many possible image sources (both free and subscription/keyed like B&T/syndetics). In fact, several coders have reported implementing this for their favorite sources already! I’m looking forward to seeing this code synthesized, providing the broadest possible coverage for images. Then we can start to get some abstraction around the other data in common, like reviews, ratings, etc.
Some of my colleagues have already started on LibraryThing and xISBN. If you have other external data sources you would like to see integrated in Koha, feel free to mention them here!