The biggest news in higher education yesterday, at least in the technology sector, was the merger of Blackboard and WebCT. It seems the impact on academic libraries will be far less than on our colleagues in IT who, to a greater extent, will be dealing with the cascading consequences of the merger. There is no immediate impact as all of the merged company’s products and platforms will be maintained. For academic librarians who are actively involved in their campus courseware at some level, and I hope this is the case at a growing number of institutions, particularly at the administrative and support levels, the eventual impact may be more significant especially for those at WebCT institutions. It’s a merger but it appears the new company will be called Blackboard and I would expect that the products and resouces supplied by WebCT will eventually diminish, perhaps even more so than for customers of Dynix after the creation of SirsiDynix – at least this one keeps the Dynix name intact. One common element in these mergers: all the companies say “the merged company will give customers the best features of both products, no matter which system you own now.” That sounds great but can they deliver? Or will this elimination of one more competitor allow the new company to grow more powerful, eliminate smaller competitors (as Blackboard has done in the past through outright purchases), and ultimately raise product costs? The Blackboard discussion lists (and I imagine those for WebCT folks as well) were abuzz with speculation on the meaning of and potential outcomes of the merger. One comment got me thinking though. The writer said, “These guys must really be worried about Moodle.” If you’re not familiar with it Moodle is an open source courseware system. It initially was used more heavily in K-12 settings, but in the last year more IHEs (institutions of higher education) started using it as well – primarily to save money (well there is that argument that open source has its costs too) but also to escape the bureaucracy and control of behemoth system vendors. This leads me to look at our own library automation systems industry and ask why no open source solution has evolved. There is certainly no dearth of OPAC complainers. You have Andrew Pace (OPACs suck), and Roy Tennant (You Can’t Put Lipstick on a Pig) writing and presenting about the need for change (more simplicity) in the OPAC world. I can appreciate their arguments for a simpler OPAC (not to mention the rest of the system) but other then present their arguments, neither has much in the way of suggestions nor have they sparked a movement among librarians or the automation vendors to do anything about the situation. I’m not criticizing Andrew or Roy, after all, someone needs to at least start the ball rolling. But what’s not happening is any development, coming from within our profession, on an open source library automation system. I am not sure why that is, but I can think of a few reasons. Perhaps these systems are far too complicated for someone to step up and create an open source version (you mean courseware systems are not that complicated – right!). Is it possible that because we’re not IT folks we lack the programming knowledge needed to create an open source library automation system? Perhaps to do something of this sort requires extensive organization and some financial support from IHEs (think the SAKAI project). Heck, with all of our associations and networks we’re so overly organized almost nothing happens in our world without some sort of inter-organizational collaboration. You’d think we could get organized over this issue. I suppose these are all possibilities for why we will continue to complain about our automation systems, but the vendors will continue to hold us over a barrel and give us products that too frequently do not work for us or our user communities. Perhaps the number one barrier is organizational support. Until our parent institutions truly understand the extent to which our libraries are dependent on these systems, until they truly recognize how deeply these systems impact each and every student, and until they are willing to provide the financial and human resources to create a coalition effort to develop an open source solution, I don’t think much will happen and we’ll all just continue to complain and hear compaints from folks like Andrew and Roy. I can only imagine what might be happening in the library automation arena if we did have an open source alternative emerging as profoundly as Moodle has in the courseware marketplace. And what is even more amazing about Moodle – a lesson about open source that we must follow – is that it was simple enough for K-12 schools to implement. An open source automation system that requires a team of programmers to implement and support will be of use only to ARL libraries and their peers. I am looking forward to a talk next month at PALINET’s annual user conference. A good colleague, Gregg Silvis, the systems librarian at the University of Delaware, will be presenting about an intriguing topic, “The Impending Demise of the Local OPAC.” I will be interested in what Silvis has to say, and wonder if he’s been thinking about the potential of an open source library automation system.
An off-shoot of the BB discussion is their announcement last week (right before the merger) of the availability of a new BB module designed to “ease” copyright management for faculty wishing to use e-reserves in their BB courses. The immediate response on my campus (and on the BB Users lists) was that this could cause a major problem if faculty start using BB to directly access the Copyright Clearance Center without library intervention (i.e., they will incur charges for materials already licensed centrally for campus use).
Another discussion on the BB Users list had to do with the fact that the module legitimized the CCC interpretation that copyright use costs should be tied to class size (which is not a traditional factor in determining fair use), and that it is important for everyone to remember that CCC interpretations of fair use tend to lean toward the collection of increased copyright fees for publishers and other copyright holders.
All of which returns us to the critical issue of copyright management as an important feature of faculty development initiatives related to scholarly communications (which is, yes, a shameless plug for our new essay in this month’s C&RL News).
Thanks for bringing the copyright development. All the more reason for librarians to be involved in the administration of Bb on every campus.
Scott, I had the same reaction reading about this “innovation” – great, another way for the publishing industry to push its version of copyright. We’re in for some real battles ahead when it comes to course readings, whether through course management systems or e-reserves.
On the subject of open-source OPACs there are a couple of real (by which I mean in use by real libraries) projects which are worth taking a look at.
KOHA was originally developed in New Zealand and is in use at about fifty libraries worldwide, including the Nelsonville Public Library in Ohio.
http://search.athenscounty.lib.oh.us/cgi-bin/koha/opac-main.pl
http://www.koha.org/
There is a consulting company that specializes in making this work for actual libraries, LibLime.
http://liblime.com/
You might also want to take a look at the list of open-source library projects at OSS4Lib.
http://www.oss4lib.org/projects/
Having just spent a year trying to get our vendor-supplied OPAC to behave, I can’t imagine that it could be that much harder to learn how to maintain a program that we would control.
When the Nelsonville Public Library needed a few features they paid a consultant less than their previous annual maintenance fee to design them according to the library’s specs. Think about that for a minute.
Open source makes sense. If we support it we can have the systems we want, rather than the ones our vendors care to provide.
See also the Evergreen project, http://www.open-ils.org/ . In initial coding stages, but some modules are available for demo. The project maintains a weblog at http://open-ils.org/blog/ .
Unfortunately, ILSes are heinously complicated pieces of software, not least because of thirty-year-old baggage they have to haul along. Open-source processes grind slow, but they do tend to grind exceeding fine. Patience.
This just in via Inside Higher Ed: Tarleton Gillespie expresses (better) my initial reaction to the integration of CCC into the MegaBlackBoard: “Between What’s Right and What’s Easy.” Fared use indeed.
As part of the team at CCC that helped design, develop, and market the Copyright Permissons Building Block, I would like provide some clarification on it’s functionality based on the comments above. The Building block can be set-up in either a decentralized mode (in which faculty get permissions directly from CCC) or in a centralized mode. The centralized mode requiries faculty to submit a “permissions request” (not an order) to a “Central Copyright Administartor” on campus (i.e librarian, copyright expert, etc.) who reviews the request and either sends it on to CCC for processesing or cancels it for various reasons (i.e. already have permissions to use, fair use, too expense, etc.). The Building Block allows them to send a note back to the faculty member about why their request wasn’t process and leaving an audit trail. The centralized process is used by the majority of the Copyright Permisisns Building Block users and prevents the double/over payment problem mentioned in the above responses. Also, since CCC doesn’t invoice until 60 days after the start of term, the central copyright administrator can modify the number of students in the class if there were drop outs or they didn’t access the material resulting in the insitiution only paying for what they have used. We did a lot of research with faculty, staff, and librarians before we developed the Building Block and I encourage you to check it out. For more information on the Copyright Permissions Building Block, please visit http://www.copyright.com/blackboard.