In my work with libraries, I’m increasingly hearing and being asked about concerns with the new “open” systems and their Application Programming Interfaces (API’s) which many libraries use to meet local needs. I’m afraid these concerns are only going to increase as more of the profession moves toward cloud-computing or hosted solutions. Specifically, the concerns I’m hearing are:
(Note: - Want more advice for your library? Contact me at the CARE Affiliates website)
- A lack of adequate or usable API documentation. I’ve been working with automation systems for libraries since the early 80’s and complaints about software documentation are as constant as the rising and setting of the Sun. These complaints aren’t without reason. Many libraries will, as a result of the move to cloud-computing systems, be more likely to use APIs as a way of providing needed customizations for their library members. This requires greatly increased dependence on API documentation and it’s overall usability. Library staff APIs from suppliers that are difficult to use, require training to use or that are overly complex are, to put it bluntly, examples of poor programming. Organizations developing these APIs should have internal standards that have to be met and their Quality Control group should be checking them in order to avoid these problems. Ultimately, if this isn’t done, your library is going to absorb a substantial cost overhead in lost development time, not to mention staff frustration, that no library can afford in this economy. Solution? Before signing on to buy or upgrade to a new proprietary system, demand to see the API documentation and have the supplying organization give you access to an API of your choice. Ask one of your staff to do some test development using that API. If s/he comes back to your desk babbling and looking crazed, you’ll know to look at other systems. If your person comes back smiling and eager to show you what they’ve done, you’re on the path to the right solution.
- The API/Code-extension developer community doesn’t seem to really be a community. Many organizations and their customers, in moving to what they’re calling “open systems”, are engaging in more marketing than real change. While a proprietary vendor may be quick to adopt the broader terminology of the open source community, including the word “community”, there may not be substance behind that adoption. OSS developer communities understand that part of the obligation they take on as contributors and developers is the need to help provide support for new users entering the community or to help those trying to implement or work with developed code. These communities have their own codes of conduct and recognition and the bottom line is that they usually work well. You can get support out of a well-run OSS community behind a product. However, when suppliers of proprietary systems adopt the phrase “developer community” it may not mean the same thing. They aren’t bound to the same rules as the OSS community. Frequently the code isn’t as openly available because the vendor won’t allow that to happen (check - is it on SourceForge?) or there might be legal restrictions in the contract covering the use of the code contributions, especially if the vendor has supplied them. Code contributions from customers may not be actively supported by those customers due to other demands on their time. Or they may feel that the vendor should do this or at least, should not profit in any way from the support they provide. The result is that the support may or may not be anywhere near as good as you’d find in a total OSS community. Solution? Check to see if the vendor/supplier offers support for code extensions either on a pay-as-needed basis or as part of a maintenance contract. Be aware that most will not as their resources are dedicated to other projects, sometimes for years in advance. See if the vendor/supplier will let you examine support requests that have been placed on a listserv or through other communication vehicles they provide. Verify what the typical response time is and how often such requests go altogether unanswered. Look at the resulting data and make a fact-based judgment of the results to determine if support is really available and if it will meet your needs.
- No pre-notification of upcoming changes to API functionality. In the case of a locally installed proprietary system a library can wait to upgrade until they’ve rewritten their code extensions to work with the newly revised and delivered API’s. However, with the increasing move towards cloud computing or hosted proprietary solutions, that control is moving to the hands of the vendor/supplier. This offers the potential for far more problems. Solution? Libraries should, before buying into one of the new cloud-based proprietary solutions, check to see if people from the user community are involved in reviewing API changes before they’re made. Libraries should also insert into their hosting contracts, language that specifies at least a 90-day notification of changes to the vendor API’s that would affect existing API functionality. Furthermore, the documentation should be supplied at that same time so that libraries can prepare their code extensions to use it. If the changes are adding new functionality, then the notification is not as critical, although it would still be a good business practice.
- Contract restrictions in API usage are unspecified, unclear or can be modified without notification. I understand that many supplier organizations are particularly sensitive to the issue of their APIs being used by their competitors in developing new products or services that will end up competing with the system suppliers offerings. Yet, I’m not convinced libraries should simply agree to this. Librarians should have the right to pick from the best available solutions, whoever develops them. Of course, suppliers/vendors will want to leave usage terms deliberately vague so they can define them as needed. They might want to restrict usage to non-profit organizations (or if they fear OCLC, they may try to restrict usage to your library staff). I’m not saying this is right but at least you can understand their desire not to make it easy for their competitors. In some cases, even if the library is the developer, a vendor/supplier might attempt to stop them from developing a competing offering, particularly if the library intends to place the resulting code in open source (that situation is really NOT defensible in my opinion, but it does happen). It is also the case that many contracts may contain API usage clauses that allow the contractual terms of usage to be modified by the supplier without the consent of the customer. This is dangerous for libraries and I would advocate it shouldn’t be agreed to under any circumstance. Solution? Before signing any agreement covering API utilization, make sure the terms are clearly spelled out and that you retain the right to develop whatever applications you wish. Also, put it in writing that you can share the code you develop with other similar organizations. If you truly want to foster greater innovation in the market, demand the right for all types of organizations to develop software that use these APIs. (Note, it would be fair for the vendor to require that those organizations also be supplier of software or services to your organization). You’ll likely have to fight for this one, but depending on how strongly you feel about innovation and getting the greatest return on your investments, the fight might be worth having. Finally make sure all these legal terms can’t be modified without your written consent.
- The need for standardized API’s. Depending on the system involved, for example a library management system, you might use the system anywhere from 3-10 years. Some systems, like discovery or ERM systems might be in place for a shorter time frame. In virtually all instances and at some point down the road, you’ll likely want to switch to a different supplier/product. At that time, having the capability to switch all the code extensions you’ve developed from your existing system to the new system will be dependent on one thing – the existence of standardized APIs. Most vendor/suppliers want to ignore this request or place it into a standards development organization. There they know the resulting standard will likely be a “lowest common denominator” because libraries don’t participate in the standards process at a level that allows them to prevent this from happening. But this is one of those places where libraries need to take hold of their future and define what it is going to look like. Particularly with the move to cloud based systems. Solution? Libraries should insist on standardized API interfaces. They should join and participate in NISO or other organizations where the standards work is being done to ensure the resulting standards support true transportability of extensions between systems. If you don’t do this you’re setting yourself up to have to do all the development work over (for no good reason) and you’re penalizing your library users/members with loss of functionality while that happens.
- You’re locking yourself to a vendor/supplier and the course they choose. I’ve written before about “The disintegration and redistribution of the library”. If you’re not careful with your usage of APIs, you might be aiding and abetting that process. Think about what would happen if you haven’t done some of what I’ve suggested above and a different organization buys your supplier/vendor? Or, where would you be if an entirely new administration moves into your suppliers operation? What if they shut down access to those APIs, substantially modify them or withdraw support altogether? What if they decide they want to serve your library user/members direct and decide to cripple your library by withdrawing your ability to use these APIs? Be particularly thoughtful about this when you’re buying your discovery interface from the same firms that supply your content. I keep pointing out that libraries don’t overall represent a growing market and in most cases libraries are dealing with shrinking budgets. This makes for a difficult market for vendors/suppliers who are facing owners/shareholders that want to see continual and substantial growth. As a consequence, they will be forced to look for new, adjacent markets or ways to grow beyond simply serving libraries and one way to do that is go around the libraries. Think it can’t happen? I suggest you look at firms like Pearson, McGraw-Hill and others where courses are being bundled with extensive content and offered directly to university provosts, department heads, professors, etc. All without a library in sight. Then also consider what is happening with e-books at the moment. So, yes - you bet it can happen. If you’re not careful, you might be signing a contract that will place your library in this position. Solution? Get advice, do your due diligence, read relevant background materials and proceed quickly but carefully.
(Note: - Want more advice for your library? Contact me at the CARE Affiliates website)
