Thanks to everyone for participating in the first Code4Lib Virtual Lightning Talks on Friday. In particular, my gratitude goes out to Ed Corrado, Luciano Ramalho, Michael Appleby, and Jay Luker being the first presenters to try this scheme for connecting library technologists. My apologies also to those who couldn’t connect, in particular to Elias Tzoc Caniz who had signed up but found himself locked out by a simultaneous user count in the presentation system. Recordings of the presentation audio and screen capture video are now up in the Internet Archive.

Lessons Learned

Second, some comments I got were about cranky Java applets and applications. LYRASIS has two conference tools at its disposal — Java-based Centra and Flash-based Acrobat Connect — and I chose Centra because running Flash on LINUX is an issue. Maybe this will need to be revisited (or maybe there is another Java-based conference system that can do better).

Third, since we were not limited by space and other timing constraints, can the five-minutes-per-presenter limit be relaxed? I have mixed feelings about this; I think defined time limits promote better presentations, but the four presentations this first go-around went to the end of the five minute time limit and there was no opportunity for questions or audience interaction.

On the whole, it seemed like a positive experience from my perspective and from that of the feedback I’ve received so far. I’m going to start a conversation thread in Code4LibCon (where all of the Code4Lib meeting planning discussion takes place) to see if it is worthwhile to do again and to identify what should be done differently. If you are interested, please consider joining and contributing to the discussion. Or e-mail me privately and I’ll reflect your comments into the group discussion.

This year has seen the release of two personal repository services: http://PublicationsList.org/ and the U.K. Depot. These two services have an admittedly different focus, but I think it is still interesting to compare and contrast them to see what we can learn.

The Depot

The deposit interface, for those putting content directly into the centralized Depot repository, has four main stages. First, the “Type” stage, specifying whether the object is an article, a book chapter, or a conference paper:

Next, the “Upload” stage, where one can upload the file and supply a few more properties:

Then the “Details” stage, where the descriptive metadata (minus the controlled vocabulary subjects — that comes in the next screen) is input:

And finally, the “Subjects” page, with an AJAX-driven expanding-and-collapsing hierarchy of subjects:

To retrieve contents from the repository, there is a “browse” interface for looking by ‘year’ or by ‘subject’ — no other browse facets and no search interface. The Depot was just formally released this month, so I would bet that functionality like that is in the works.

PublicationsList.org

The single item entry page is a just-the-facts interface. Note that the content hosting service is only available to those who have upgraded to the “Publications List Professional” version (which costs £9.99, or approx $20/€15, per year).

The system can also accept a variety of citation manager file formats for bulk entry. (See snapshot to the right.) PublicationsList also has a built in search-and-select interface to PubMed for finding publications matching your name and automatically populating the metadata fields in your personal citation.

Then end result is a web-based bibliography with links to the publications (either hosted on PublicationsList or on other sites). The free version is hosted on PublicationsList.org (see the service founder’s page as an example) and the professional version can embed the publications list in your own page.

PublicationsList does provide discounts and additional functionality for groups (such as departments, research centers, etc.).

Observations

The one-stop, redirection service in The Depot is a good concept, too. If a researcher wanted to deposit their content in a repository and they weren’t sure if their institution had a repository to hold it, OhioLINK would be a natural place to look for a content hosting service in the state and we could redirect the author to the appropriate location on a campus. OhioLINK could also be playing the role of repository-of-last-resort for Ohio academic researchers by providing a space and services for published content, whether or not the institution in question has set up a formal repository space on the DRC.

Footnotes

1. For a really good discussion of that problem, see Davis, P.M., & Connolly, M.J.L. (2007). Institutional Repositories: Evaluating the Reasons for Non-use of Cornell University’s Installation of DSpace. D-Lib Magazine, 13(3/4). Retrieved March 14, 2007, from http://www.dlib.org/dlib/march07/davis/03davis.html.

This is a summary of a presentation by James L. Hilton, Vice President and CIO of University of Virginia, at the opening keynote session of Open Repositories 2007. I tried to capture the esessence of his presentation, and omissions, contradictions, and inaccuracies in this summary are likely mine and not that of the presenter.

Setting the stage

This is a moment in which institutions may be willing to invest in open source development in a systematic way (as opposed to what could currently be characterized as an ad hoc fashion) driven by these factors:

• Fear. Prior to Oracle’s hostile take-over of PeopleSoft, the conventional wisdom of universities was that they needed to buy their core enterprise applications rather than build them. In doing so, they sought the comfort of buying the security of a leading platform. Oracle’s actions diminished that comfort level. Blackboard acquisition of WebCT and lawsuit against a competitor does not help either.
• Disillusionment and ERP fatigue. What was largely thought to be an outsourced project was found to be an endless upgrade cycle. Organizations need to build entire support units to handle the upgrades for large ERP systems rather than supporting the needs of the users.
• Incredulity — we’re supposed to do what? The application of technology typically has a disruptive impact (cannot predict the end), the stakes are incredibly high (higher education and/or research could be lost in a decade), it tends to be expensive, and the most common survival strategy is to seed many expensive experiments in the hopes that one will be in the right place at the time the transition needs to happen. The massive investment anticipated for technology to support academic computing (libraries, high-performance clusters, etc) will pale in comparison to the investment in administrative computing.
• Rising tide of collaboration. This is a realization that the only way to succeed is through collaboration. To paraphrase Hilton, “In the new order it will be picking the right collaborative partners where the new competitive advantage will come from.”

Distinctions

Hilton offered these definitions and contrasts as a way to frame the rest of his discussion. First was Open or “free” software. Free as in beer, or free as in “adopt a puppy.” The software comes with the ability to do with as you want with the code, not just the ability to use the code. They he defined the term License as a contract — what ever you agree to you are bound to; you cannot use copyright law to protect you. The rules and conditions that are applied to the software do matter.

Lastly, he talked about Copyleft or “viral” licensing. There are different interpretations of “open” in open source. “Copyleft” has come to mean that code should be freely available to be used and modified, and it should never by locked up. GPL is an example. This is often called “viral” because if you include software with this license in any other work that is released, the additional software must be released under the same license. This is seen by some as valuable because it prevents open source from being encircled by proprietary code. Copyleft is contrasted with an “open/open” license — you can do whatever you want to do with a code under this license. An “open/open” license places no restrictions on what users do with code in derivative software packages.

Case Study — Michigan’s Sakai Sojourn

Hilton briefly described why UMich went down the Sakai path in 2001-2002:

• Legacy system with no positive trajectory forward. It could never be released into open source; all of the development would have to be carried on UMich’s shoulders forever.
• Saw market consolidation in CMS. This was mostly evident in the commercial sector with Blackboard and WebCT being the dominant choices. They had concerns about the cost of licenses in this environment down the road.
• Saw the potential of tapping the institution’s core competencies and starting a virtuous cycle of development, teaching and research. Or, put another way, they didn’t want core competencies in teaching and research held hostage to a commercial development cycle.
• Strategic desire to blur the distinction between the laboratory/classroom and between knowledge creation/digestion. They realized that the functions of a research support tool and a course support tool were pretty much the same under different skins, and they sought to blur that distinction even more.
• NRC report and the need for collaboration. UMich was willing to fund the project two years internally but knew after that need to find collaborative partners by the fifth year in order to be declared a success.
• A moment of time opportunity that synchronized the development process of several partners with funding provided by the Mellon Foundation.

There were also specific goals for the Sakai project. The new system had to replicate the functionality of existing course and research collaboration environments. They also wanted experience in finding partners willing to collaborate. Hilton said, “Sakai was/is at least as interest from a collaboration perspective as it is from the technology perspective.” Bringing together disparate organizations with different beliefs on how things should be done is a challenge. Additionally, they wanted to get better as an institution at discerning open source winners; it shouldn’t be like a lottery. Lastly, they wanted to implement software parts that were not built at UMich. Each partner institutions committed to implementing the same thing even if wasn’t built at that institution. This is tough to do, but they knew they needed to do it for their own good in the long run.

What happened? Not only did the original partners show up, but the community came, too. Even more interesting was that the community was formed with dues-paying members — even in a world where the software is free. It became a vibrant community, too, with a conference every six months. Sakai was released under an open-open license model, and corporate partners showed up as well (selling support services, or hosting services, or hardware for the software). The software did grow up and left its home; a separate foundation now holds the intellectual property of the code (originally partners assigned copyright to UMich). They also positioned Sakai to be a creditable threat to the commercial entities in order to force them to the standards table.

Takeaway lessons that generalize to open source development

First, the benefits of open source development.

• destiny control (but only when you really need to drive). having the control is not always a good thing. Is it worth the effort? Is the project core to the institution’s mission? (Does it directly support scholarship and teaching?)
• builds community and camaraderie (in the case of Sakai, both locally at UMich and internationally)
• unbundles software ownership and its support. inspires more competition in the implementation and support space.
• community source provides institutions an opportunity to leverage links between open source, open access and culture of the academy/wider world (a.k.a. put up or shut up)

Then, the challenges of open source development.

• Guaranteeing clean code (IP) is hard (read as “impossible”). A certain amount of faith about the code they get and there needs to be consideration for mitigating risks.
• Figuring out who is authorized to license institutionally-owned code is challenging and then you have to convince them to give it away. No one in the institution typically has been appointed or given the authority to release code. One of the things that the sakai licensing discussions highlighted was institutional differences in requirements and aesthetics.
• Patent quagmire always looming. How do you know your software is not infringing? How do you make sure you don’t inadvertently give away all institution patents? Be careful when looking at licenses from an institutional perspective versus an individual perspective.
• There is also the inevitable lawsuit risk. Or, as your counsel might say to you, “Let me get this straight, we can get sued but there’s no one we can sue.”

Then, some discoveries that they made along the way.

• An open source project not a silver bullet. The commitment to build rather than buy must align with institutional priorities and competencies; it is not right for every project/application.
• Licensing does matter; it is a contract: whatever you stick in its rules is what sticks. There are probably have too many open source license options and some sort of standardization is needed. Also keep in mind that if you release something under an open/open license, you can’t include any copyleft components.
• Communities don’t just happen, they require: specific shared purpose (when visions vary, or when they change, collaborations struggle); and governance (e.g., separate board with dedicated developers sitting between institutions). Cooperation (“I won’t hurt you if you don’t hurt me”) is not collaboration.
• Open (community) source requires real project discipline. “It is as spontaneous as a shuttle launch.” Along the way one needs to learn to balance pragmatics and ideals. One also needs to learn to trust your partners. “It really requires learning to let go.” Letting go, and having the community make the decisions, may be the quickest path to efficiency.

Reflection on open/community source for repositories

Repositories are at the center of everything at the institution. It connects with the library, with the presses/scholarly publishing operation, with classroom teaching, with the laboratory, and with the world. It is a core piece of of infrastructure for the university of the 21st century. As institutions, we need to make sustaining investments in our repositories.

Hilton sees three different approaches to “community” in the existing projects:

• dspace: community of user/developers. The come together to talk about what they want to do, write code, and support each other. Clearly there are enthusiastic users as developers.
• eprints: appears as like a vendor talking with customers wanting the community help shape the direction.
• fedora: in transition from a combination of the previous two models moving towards a Sakia-like model. it will require institutions to make commitments to it.

In the end, Hilton asked some thought-provoking questions. Is now the time for institutional investment in open/community source? Will a coherent community (or communities) emerge in ways that are sustainable? — is there a shared vision?

The text was modified to update a link from http://www.virginia.edu/vpcio/bio.html to http://www.virginia.edu/vpcio/biography.html on January 19th, 2011.

Open Repositories 2007 is coming up next year, and it looks to be an interesting meeting. The first day is open user group meetings for DSpace, Fedora, and Eprints, followed by general conference sessions that cover issues that cut across all of the open repository systems. This year, the user groups will partition their programs into Plenary, Technical Issues, and Management Issues and the partitions will be staggered so that IT managers can attend all plenary sessions, technical staff can attend all technical sessions, etc.

The call for participation for the general conference has gone out. Its Program Committee is seeking submissions in the form of an extended abstract of no more than 500 words by October 2, 2006. The contributions must be written in English and should be double spaced. The Program Committee will select relevant submissions. Selected speakers will receive an email by November 6, 2006 with guidelines for their presentation. Presentations will be limited to 20 minutes, plus 10 minutes for questions.

This looks to be a really good meeting. You can track it on HitchHikr at http://hitchhikr.com/index.php?conf_id=75.

The text was modified to remove a link to http://openrepositories.org/call on October 29th, 2010.