As I discussed in a previous essay, it’s the collaborative power of the internet that makes the open source phenomenon possible. The ability to collaborate cross-institution and develop a ‘community support’ model is what can make this round of library-developed software much more successful than the ‘home grown’ library software of the 1980s.
So how does this apply to APIs? Well, library customers are finally demanding APIs, and some vendors are starting to deliver. But the point of an API is that a third party will write client code against it. If that client code is only used by one institution, as I discussed, it’s inherently a more risky endeavor than if you have client code that’s part of a cross-institutional collaborative project. For all but the smallest projects involving API client code, I think it is unlikely to be a wise managed risk to write in-house software that is only going to be used or seen by your local institution.
The problem is if a vendor’s licenses, contracts, or other legal agreements require you to do this, by preventing you from sharing the code you write against the API with other customers.
On the Code4Lib listserv, Yitzchak Schaffer writes
here’s the lowdown from SerSol:
“The terms of the NDA do not allow for client signatories to share of any information related to the proprietary nature of our API’s with other clients. However, if you would like to share them with us we can make them available to other API clients upon request. I think down the road we may be able to come up with creative ways to do this – perhaps an API user’s group, but for now we cannot allow sharing of this kind of information outside of your institution.”
To me, this seriously limits the value of their APIs. So limiting, that I am tempted to call them useless for all but the simplest tasks. For any significant development effort, it’s probably unwise for an institution to undertake a development effort under these terms. That’s assuming that an individual institution even has the capacity tod o this–the power of internet collaboration is that it increases our collective capacity by making that capacity collective. Both that increased capacity and managed risk through a shared support scenario requires active collaboration between different institutions—even SerSol’s offer to perhaps make a finished product available to other clients “upon request” is not sufficient, active and ongoing collaboration between partners is required.
If I’m involved in any software evaluation processes where we evaluate SerSol’s products, I am going to be sure to voice this opinion and it’s justification. If any existing SerSol API customers are equally disturbed by this, I’d encourage you to voice that concern to SerSol. Perhaps they will see the error of their ways of customers (and especially potential not yet signed customers) complain.
Ross Singer notes that this is especially ironic when SerSol claims their APIs are “standards based” (http://www.serialssolutions.com/ss_360_link_features.html). What proprietary information could they possibly be trying to protect (from their own customers!).
Bibliographic Wilderness 
We would like to say up front that the non-disclosure agreement which we ask libraries to sign before receiving the documentation for our API’s does not limit the library IN ANY WAY from contributing their own code to other institutions. The posting on code4lib from one of our support staff was incorrect.
We ask libraries to sign a non-disclosure agreement before receiving the API’s and accompanying documentation because once signed, API users have access to propriety information through communication with our development staff.
Obviously, our software is our primary asset. While we are pleased to tell libraries how this works, we ask for the non-disclosure so that the technical details of that asset are not shared with a potential competitor. However, the code that the library develops using the API belongs to the library. The library is not limited from contributing that code to the community. In fact, we would encourage you to do so.
Thanks for the clarification/correction Harry. That is welcome news.