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
To do that, the business model would need to answer some very tough questions:
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.
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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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”).
- 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.
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.
