I attended the fall CNI Membership meeting recently and, as always, it’s a great meeting. Cliff Lynch always opens the meeting with an excellent overview that clearly defines current trends and issues in the field. One issue he raised (starts around minute 71:00) caught my attention in particular. That was the thought that we need to be concerned about the sustainability of so many open source initiatives in this field. While clearly calling out the positives that some projects are moving under the Kuali umbrella and the combination of DSpace and Fedora into the DuraSpace effort, he also called for some focus on the part of the profession. Since I’ve raised this very issue in some of my previous posts (here, here and here), this deeply resonated with me. I applaud Cliff for raising it. His voice is widely heard and deeply respected.
So, I was a bit surprised (and worried), when I attended the session on IR+, a new open source repository offering being developed by the University of Rochester. I think this project is a perfect example of precisely the point Cliff raised in his opening remarks. On one hand, they’ve got some obviously talented and hard-working developers who’ve developed some interesting new repository features with their project. Yet, because it is a new project, they were also strongly making the appeal that they hoped others would see the value and thus join their community to help develop the product yet further. All of which underscores the question that Cliff (and I) are asking – how many of these types of initiatives can the shrinking resource pool of academic programmers (focused on libraries) support and support well?
Of course this question can’t be simply answered as it is tied to a variety of related questions, like:
- How big a community does a product need to be viable?
- How many sites are using the product?
- How clean is the code? and on and on…
The questions can keep mounting, but I think there is a larger and more important issue at stake here. Again in his remarks at CNI, Cliff used a phrase that I'm going to borrow here: “redundant and poorly coordinated investments.” It captures, at a high level, the need for administrators, be they in the library or on the campus, to ask these questions when considering investments in open or community source to determine if their project/product addresses a need:
- Is there a product (proprietary or otherwise) that can substantially address the needs being expressed and, if so, has a full and accurate cost comparison of those options been prepared? The questions should be extended to ask: if the proprietary solution was put into place and thus into production more quickly, would the time savings realized by so doing result in the ability to invest in other OSS projects that would offer a greater return on the investment because they’re meeting new end-user needs through new and possibly innovative feature sets?
- When the needs of one institution are found to be totally unique, is it an indication of innovation or lack of focus? When we encounter these situations are we taking the time to ask if is a call for a revised workflow, a new best-practice, or is it something truly unique and that clearly adds value?
- Is it possible for academic librarians to agree to establish a criterion for OSS projects that says, if an OSS concept proposal can’t enlist “x” people in its community within “x” time, it should not be undertaken and that no code should be developed until such a milestone can be achieved?
- Finally, we should always be asking how any OSS project contributes to the larger agenda of the institution. Is it supporting the mission, goals and objectives as defined by the administration? If not, why are we doing it? If it does, be sure to understand how it will not only support those things, but be self-sustaining in doing so.
I’ve long been an advocate in this blog that librarianship is in need of a clear definition of the future of the profession and to examine how technology (open source or proprietary) will move that definition to fruition and, at the same time, leverage librarianship. We have scarce resources and large needs. I think we all need to make sure we wisely balance innovation and focus.
Posts
4 comments:
None of this is specific to Open Source Software (OSS) and signally out of OSS is a non sequitur for me. I agree that many libraries could use more focus when implementing new technology but I strongly disagree that this is any different when it comes to OSS. Many proprietary applications, including some of Ex Libris' offerings, require a great deal of customization and often just as much, if not more, staff to implement and maintain as Open Source. I was talking to a proprietary ILS administrator at another University last year and they had more than twice as many systems people working on their ILS then Georgia Pines had to original develop Evergreen. Another example is about three years ago a University had four new job advertisements to help them implement a new proprietary discovery layer. People like David Walker have put into a lot of work implementing a custom interface on top of Metalib. Are these wasted, redundant efforts? Why is this different then focusing efforts on OSS? It's not any different. Or if it is, one could argue that at least a library would have the software to change and modify like Rochester did with Dspace in creating IR+ which the couldn't do if they put all their previous efforts into a proprietary product that ended up not suiting their needs. This is not an OSS issue, it is a technology issue and a management issue. It is just as easy to say that Ex Libris building Primo Central (or whatever product you want to name) is "redundant and poorly coordinated investments” considering other vendors are in similar spaces.
Your underlying point "that librarianship is in need of a clear definition of the future of the profession and to examine how technology (open source or proprietary) will move that definition to fruition and, at the same time, leverage librarianship" is well taking and I agree. Libraries should evaluate each technology acquisition carefully considering need, budget, skill level, mission, etc. This evaluation may or may not lead to an existing OSS or propitiatory solution, developing a new OSS or home-grown solution, partnering with a vendor on a new product (such as the URM development partners are doing with Ex Libris, or not implementing anything at all. But dividing the world between Open Source and proprietary applications only serves in muddying the water and weakening the message.
BTW: Do you have any sources for your statement that there is a "shrinking resource pool of academic programmers (focused on libraries)"? It seems to me that (current economic downturn not withstanding) more academic libraries are hiring programmers then say 10 or 15 years ago.
That's a lot of text for a non sequitur, no?
I heartily agree, Carl. I've advocated for a new library organization to leverage technology for libaries across the nation. (See An Inflection Point for American Public Libraries.)
We need trained technologists who can fully utilize the products of open source developers and high-value service providers like ExLibris. These professionals could also help guide your future development efforts. It would be a win-win-win for the developers, the libraries and the people they serve.
As a member of the URochester River Campus Libraries and the IR+ team, I found your comments very interesting. The path that led us to build IR+ started in 2003-2004 when we took the time to study the actual work practices of our faculty to see where IRs aligned, or not. We shared our findings on DLib. Among our conclusions were that IRs were to focused on the institution (as exemplified by the name "institutional repository") and not the individual researcher. Also, we saw that faculty had a significant number of authoring, versioning, and other document management related needs that were so pressing that the value of the IR was largely lost on them.
We tried to address the first problem through the creation of what we called "research pages;" to put the focus of the repository on the researchers themselves and not the institution, academic departments or collections of texts. We built the code on top of DSpace 1.1, but by the time we were finished, the code was up to DSpace 1.3 beta. It is a long strong, but the end result is that between Rochester and the work of Tim Donohue of UI, Urbana-Champaign, the researcher pages code was rewritten 4 times to work with 4 versions of DSpace ((1.1; 1.3; 1.3.2, and 1.4.1) but the code never became part of the core code, and it became cost prohibitive for us to continue to create new versions of the code.
However, we still had documented, unmet needs from our local Rochester community of users, and the problem-space of faculty needing a document management system tied to an institutional repository was one that we believed the River Campus Libraries should have a local role in. At the end of the day, we are accountable for addressing the needs of our local community of users and that is what caused us to create IR+. I do not think that the document management problem is unique to the University of Rochester faculty community; however, we only have our local evidence to guide us, which consists of 1 year of studying faculty and 2 years of studying graduate students http://hdl.handle.net/1802/6053.
We could have built IR+ as a local product only and not invested the time and effort to make it available to the wider repository community. But we strongly believe in the importance of sharing ideas with our colleagues, and in this case, it seemed best done by sharing our source code. We are testing a hypothesis (i.e., IRs could benefit greatly from having a document management system back end) openly and inviting others to learn from our successes and mistakes. If our hypotheses are proven wrong, then it will be a very good thing that we did not drag the full DSpace community and code along with us. If our hypotheses are proven correct, then there is code out there for programmers to study and understand how it works.
What you see as a proliferation of code, I see as a proliferation of ideas and an institution willing to invest a lot of time and effort in not just tossing ideas out there, but acting upon them. It is not as though anyone is claiming success with their IR, so it suggests that there is still work to be done.
But I think you are overlooking the very important fact that each library must respond, first and foremost, to their local user needs; just as companies need to respond to their stock holders. If we don’t, then there is no reason for our institutions to support the work we do; which would certainly end the problem of code proliferation!
Susan:
Thank you so much for commenting and providing this background. It provides some much needed information (and links) for readers to use in evaluating all the points being made.
There are a couple of points I’d make after reading your comments.
First, I totally agree that meeting local user needs is critical and must be done. My concern remains with the process by which those needs get addressed. As I stated in my initial post, you and your group clearly have some great ideas and some talented developers to move those ideas forward, but the fact that you had to not only build the code to implement those ideas, but you also had to reinvent all the core infrastructure code underneath -- which is what led me to express concern. When I titled the post: “Balancing innovation and focus” I was trying to point out that while we should value “the proliferation of ideas” we also need to value focus in order to; a) make sure those ideas are sustainable given the resources that are available and b) hopefully contribute to a larger vision/agenda all of these ideas support and move us collectively forward in achieving. (Of course, you’re right, we fight this same battle in business as well, but again the difference for me is that we have largely established mechanisms for determining this balance – cost, customer acceptance of the product, etc.) Whereas the variables that will determine the winner(s) in the OSS world are considerably more at flux in the market, particularly in a market is substantially smaller (as libraries in the information processing landscape clearly are as compared to IT in general) or under massive economic stress (again, as libraries clearly are at the moment). My post above this one, details what I think we as software vendors can help contribute to this.
The question I think Cliff was asking at CNI and that I was following up on is how many of these OSS initiatives can realistically be supported, and at the same time, be successful in this market? If we simply allow all to be brought forth and tested via the mechanisms currently in place, will we, because we’re essentially duplicating much of the same ground with so many initiatives, be frittering away valuable opportunities/resources to accomplish a larger and far more coordinate vision of librarianship? Again, this would require massive coordination to move us beyond, as you point out, just answering local needs. But I just keep wondering if that isn't a place we should all be devoting some of our efforts?
You’ve explained, in detail, why that happened in this instance and clearly, for your organization you didn’t have much choice. I appreciate that now that you’ve provided the background.
At the end of the day, I still think the questions I posed remain valid and deserve continued discussion (such as you've provided! Thanks again.)
Post a Comment