Tuesday, August 4, 2009

OLE; The unanswered questions


After returning from a vacation following ALA, I read the summary of the recently issued draft Final OLE Project Report. While there is much to be admired in what the OLE project has achieved, it is also important to note that OLE is neither the first organization to define these goals nor does OLE represent major unique or innovative technology. Furthermore, it leaves some important questions unanswered that anyone thinking about investing in this project should demand answers for first.

Robert McDonald, Associate Dean for Library Technologies at Indiana University, said in an email about the project:
"The goal is to produce a design document to inform open source library system development efforts, to guide future library system implementations, and to influence current Integrated Library System vendor products."
If you read the Project goals outlined in the document, you'll find it states similar goals:
“to design a next-generation library system that breaks away from print-based workflows, reflects the changing nature of library materials and new approaches to scholarly work, integrates well with other enterprise systems and can be easily modified to suit the needs of different institutions.”
These are all important and readily agreed upon goals. In fact, nearly two years ago, Ex Libris started to define a very similar set of goals, although much broader, more comprehensive and technologically more advanced. This process was the beginning of what was to become known as Unified Resource Management (URM).

The next steps, according to the OLE document are to start
“talking with senior administrators, both internal and external to OLE, to identify those institutions that wish to develop a proposal to carry the project forward into the next phase of building the software. OLE participants also have begun discussions with selected software vendors to explore how they might participate either in software development or software hosting and support as the project continues.”
This statement seems to be a bit at odds with the goals outlined and discussed above. If the goals are to influence and guide current ILS development and/or inform OSS development efforts, then developing the appropriate software is indeed a very large step in a different direction, and it skips an equally important step. So what’s missing? Creating the business model that surrounds this development effort. This is no small task, but it is a critically important one. If the OLE project were a new startup investment opportunity, investors would want assurances that the money being invested would result in a product/service that will provide a measurable return, year after year for a reasonable amount of time.


To do that, the business model would need to answer some very tough questions:
  1. What is the target market for this product? In reading the document as currently drafted, one finds a high-level description (framework) that will appeal to most librarians conceptually. It is clear from the document that the goal is to have a very wide adoption rate for the resulting product. However, it is missing the functional details needed for any specific library to be able to clearly say this product will work for them. Now if the point of the effort is to guide and inform, the document as it exists is fine. But if it is meant to result in a final product, it needs to be considerably more specific. This is where involving vendors that have developed products for the library market will be very important. Vendors that have developed automation products for this market will undoubtedly point out that the devil is in the details. Research libraries are different from academic libraries are different from public libraries, are different from… you know what I’m saying. Each of those segments requires different functionality and workflows. It is stated in the OLE Plan that the ability to accommodate flexible and more modern workflows will be met with the ensuing product. What is not clearly stated is that putting those pieces in place will be left to the institutions that adopt the product. For those institutions, factoring the time, money and resources to add that specific functionality will need to be factored into their cost considerations for adopting this as a development project/product.
  2. Who are the competitors? Clearly there are already competitive products emerging. Ex Libris is developing URM (as mentioned above) its next generation automation product. OCLC is discussing and developing extensions to WorldCAT. Others are also working towards similar goals as outlined in the draft Final OLE Project Report. A comprehensive list should, to the degree possible, be identified and listed so that potential partners understand the competitive landscape being faced by this product.
  3. How much of the market do the organizations above have or are they going to take? How much is OLE hoping to take? Once the competitive solutions are identified, some projections of market share should be developed for all the identified products. Why? Because it needs to be understood that if you have a potential market of “x” libraries (just for discussion sake, let’s say 120 ARL institutions) and OLE is going to hope to obtain a market share of 20%, then the total potential pool of possible participating institutions is 24. So when final costs are developed to fully develop this product, place it into production and maintain it are calculated, the 24 institutions must bear those costs. (For example, if the projection is that it will take 5.2M to build the product, and let’s say it takes another 5M to complete the development needed to put the project in production status by build partners, plus an annual recurring cost of minimally two programmers per institution, at a total of 150K, we’re looking at an annualized cost of nearly $500K per institution before deducting any grant funding the project might obtain). These are big and important numbers that need to be known by any institution that might wish to participate in either the development or adoption of this product.
  4. How many institutions are actually going to put OLE into production status? (Remember, we’re talking an “enterprise” level application here, so institutions have to be willing to bet the future of their organizations on the final result). There are many open source projects in libraries today. Some run in test/development modes for years with no clear date identified as to when it will be a “production” product. While it is equally true there are many OSS products that are in production status, without knowing when a product will be "done" and for how long money must be poured into the development, developing a business case that shows a useful time frame for a return on investment is extremely difficult.
  5. How much money are those institutions going to have to put behind that adoption in order to make it an enterprise, production ready, level product? While these will be projections at best, it is important to factor the answers to these questions into the business model, normally at several different levels of adoption, for the institutions considering the solution to have a comprehensive understanding of how costs might change depending on what happens.
  6. How will that product sustain itself for some defined amount of time (usually 5-10 years)? The current draft Final Report begins to outline the plan for achieving this, but again, a range of numbers need to be applied for a realistic assessment to be performed (i.e if only 50 adopt it’ll cost “x”, if 1000 adopt it’ll cost “y”).
  7. What are the risks? Risk identification is an important part of making any investment. Some of the risks that surround OLE include:
  • Given the scope of what is being proposed and the competitive environment in which the product will exist, can this product develop a large enough following of developers to sustain it in each market segment in which it aspires to compete? The reality is that the library market is one of relatively finite size and given the current economic conditions, the number of institutions that can afford to sustain a staff of developers is shrinking. Given all the other OSS efforts underway, is there a large enough community that will be willing to devote time, energy and resources to this product?
  • The investment represented both by those institutions that will be build partners and those that will end up tailoring the product to meet their needs is very large. A lot of the money to be applied here might come from the Mellon Foundation, a terrific organization that has done more for libraries than can be measured. Yet, someone needs to ask: Is this the best use of that money? Especially when there are clearly competitive products emerging, many of which come from organizations with proven track records in developing this kind of technology. What is the probability of success for this startup effort? What if it fails?
  • The real point here is that risks need to be identified, measured and factored into the investment analysis.
Once gathered, all these answers will need to be loaded into some complex business modeling spreadsheets in order to make projections about what the actual cost will be, per institution, to create and sustain the development of OLE. Given the current economic crisis in both education and libraries, these costs will need to be carefully documented, scrutinized, and compared to other offerings in order to make informed, fiscally sound decisions.

This is tedious stuff. The answers to these questions will probably not be given by the same people who wrote the draft Final Report document. However, these answers will most probably determine the overall direction and success of Project OLE, either as a guiding, influencing, or development force in library automation.

The final question I think anyone responsible for making an investment decision in terms of building OLE should ask themselves is this: If I were investing my own money in a company that said they were going to build OLE, would I do it? If not, I think you know what you should do when it comes to your organization’s money and OLE.

6 comments:

  1. While this post covers a lot of ground, there really isn’t much new here that isn’t entirely predictable based on higher education’s prior experience. I take it as self-evident that it is wise to ask questions, and history demonstrates that vendors’ year-to-year answers to prudent questions – given their essential profit imperative and lack of transparency of decision processes – fares no better than the messiness that is visible to all in community-led efforts.

    As a business school professor and long-term veteran of MBA and Executive Education engagements around the world, I recognize the ‘business model’ focus of wooing profit-motivated investors, dominating a market to create barriers that lock in profits, and maintaining a PR vocabulary as ‘partner.’ This is precisely the imperative for firms that compete to provide a return on invested capital….but it is not the only vocabulary or the only means to solve the problems of higher education.

    What is essential is that some entity play an effective coordinating mechanism among the investments of many institutions – libraries in this case. Small fees in licensing and maintenance can be gathered and coordinated by a diminishing list of firms that sell a product *OR* resources can be gathered and coordinated by an open/community source software community. This is no longer a debatable question. It is a proven model, and much has been written about it over the last five years (see www.kuali.org/press/).

    As a co-founder of Sakai, Kuali, and HathiTrust and also someone who bears institutional responsibility for outcomes at Indiana University, I can tell you without hesitation that the community source model works well as it is highly aligned to the values of higher education. Both Sakai and Kuali software are implemented and being maintained by highly heterogeneous institutions, large and small, that have vastly different missions and operational models.

    The member-led community projects do not need to make a profit or make choices about product features based on quarter ends and returns. Decision processes in all their messiness are transparent, and even small innovations at the edge can be assimilated back (with quality control) to rapidly improve software and services. Communities hold together through enlightened self-interest rather than complex contracts, restrictive licenses, and diversion of resources to sales forces and marketing. Given my experiences since 2004, I can tell you with credibility that it is not simple or easy, but neither is the illusion that we can just contract away the concerns and needs of advancing research and education.

    The arguments advanced here are no different than we saw from Blackboard, PeopleSoft/Oracle, and others in the early days of Sakai and Kuali, nor are they markedly different in theme than Microsoft’s thoughts on Linux. The world is a very big place, and I do believe there is a role for commercial offerings as part of and also separate from community-owned software as is proposed in the OLE Project Report. This is evident in the list of commercial firms that provide for-fee services around the open source intellectual property of various communities and the successful engagements of campuses that have used those firms when needed. I stand by my 2004 assertion regarding “The Inevitable Unbundling of Software and Support”.

    A frame of reference that is based solely on the needs and values of higher education can lead to different vocabulary and frame of reference for ways to coordinate the small and large investments of colleges and universities (and other libraries in this case). There are indeed fair questions to be asked, but the predictable salvo of vendor F.U.D. is unlikely to advance that discussion. The opportunity here may be for commercial firms to engage in a competitive market of support services around the open intellectual property of the community. OLE provides a compelling roadmap for what that path might look like.

    Brad Wheeler

    ReplyDelete
  2. I would additionally point out that Carl Grant's arguments turn on the supposition that "If the OLE project were a new startup investment opportunity, investors would want ...". The fallacy here is that the OLE Project is in fact not a new startup investment opportunity but an entirely different (and as Brad Wheeler points out, proven) business model, so the arguments that follow the assertion simply do not obtain.

    Peter Ivanick

    ReplyDelete
  3. I agree with Brad, and raise you what's in the best interest of the people who pay for libraries with their tax money and not just higher educational institutions. The resources it takes to do OLE would probably equal resources already at those institutions, so the for-profit part of the library world needs to play nice and openly if not to perish. The open-source model is a much stronger solution these days as the libraries themselves are employing people with the right skill-set, or hire people in at reasonable prices who are in tune with the paradigm.

    As an aside to that part about playing with openness, at every point when you want to look at URM you're greeted with copyright statements, legal threats and confidentiality notices (and, uh, even in the *PDF* FAQ document ... that's so wrong on many levels), and to get to the juice I've got to be a binding partner. What libraries are sick of is the restricted tie in to closed systems and the very reason for the existance of OLE. The sooner you learn this, the better, because *you* won't survive without taking OLE very, very seriously.

    I suggest writing systems that plug in or is compatible with the initiative as a much better strategy for all. It's a brand new world, again.

    ReplyDelete
  4. Brad, Alexander & Peter: Thanks to all for you comments. Please see my reply here.

    ReplyDelete
  5. What will be interesting is to see if those institutions who volunteer to be in on the development of OLE will be able to commit their resources to it long-term (by no means assured in the current budget envornment when everyone is working on shoestring), and whether these institutions have the stamina to both develop OLE and continue to support their current (and usually still-developing) infrastructure.

    Open source is a wonderful principle, but it does require development time, and sinking of resources. Unless the institutions who take this project on demonstrate that they can do so without endangering their current operations, making OLE a real product as opposed to an aspiration will be difficult.

    ReplyDelete
  6. Speaking as a librarian, I resonate with Brad's comment:

    "What is essential is that some entity play an effective coordinating mechanism among the investments of many institutions – libraries in this case. Small fees in licensing and maintenance can be gathered and coordinated by a diminishing list of firms that sell a product *OR* resources can be gathered and coordinated by an open/community source software community."

    From what I have observed, this is already happening through state library networks. My small library benefits greatly from the collected expertise and service of Illinois's CARLI consortium. CARLI presently relies on Ex Libris's Voyager software for our shared catalog, but also is actively exploring open source solutions that can fit the varied needs of our many different libraries.

    I also resonate with what I perceive to be one of Carl's primary concerns: I do not see a future that is exclusively run on either a proprietary business model or an open source model. In fact, the present reality already benefits from both, and it seems logical to me that this will prove true in the future.

    ReplyDelete