Eric Lease Morgan wrote:
> I heard someplace recently that APIs are the newest form of vendor
> lock-in.  What's your take?


When they are custom vendor-specific APIs and not standards-based APIs, 
they can definitely function that way. I'm still not sure if even a 
vendor-specific API is more or less lock-in than NOT having an API.  On 
the one hand, you will start to have software written against the 
vendor-specific API, that won't work without changing it up if you 
switch vendors.  But on the other hand, with SFX and Umlaut, for 
instance, Umlaut does so much more than SFX, and the SFX adapter piece 
is such a small part, that in that case, for us at least, having SFX 
with an API and Umlaut on top of it it definitely makes it _easier_ for 
us to switch link resolvers without disrupting our services built on top 
of it. 

But really, what you want is standards-based APIs, not vendor-specific 
APIs. That would give you the best of all worlds. There are a couple 
challenges that keep us from getting there though. One is that the 
library community, historically, is, well, pretty AWFUL at writing 
standards.  We come up with standards that don't actually accomplish 
what they were intended to accomplish, are too complicated for anyone to 
implement right (on either producer or consumer side), and leave so much 
wiggle room that someone can claim they support the standard but not in 
a way that any other software will ever understand.  (NCIP anyone?)

So there are a couple ways to try to get better at this. One is 
definitely looking outside the library world for standards to use. But 
unlike code4libbers, I don't think (from my experience) that's always 
possible or easy.  We have priority problems that, while they are not 
entirely foreign to the larger world, aren't as high a priority for most 
of the non-library world, meaning they don't yet have robust standards 
solutions. However, especially when standards are extensible (like XML 
ones often are), you can sometimes start with a general standard and 
extend it for the library space.

Secondly, instead of creating standards before anyone has actually tried 
solving the problem the standard is meant to solve (as we often seem to 
do), the BEST standards are created by generalizing/abstracting from 
existing best practices. A buncha people try it first, you see what 
works and what doesn't, you see what the actual use cases and needs are, 
you take the best out of what's been done, and you standardize it.   But 
doing it this way means you need to go through a period of 
vendor/product specific (eg) APIs before you can get to the standard.  
The library world is still immature in developing good software 
infrastructures, we're going to need to through some more pain for a 
while, no way around it.

But another problem in all of this is that vendors may not have the 
interest OR the in-house expertise to actually provide standards-based 
APIs.  The APIs we often get now from vendors, frankly, are kind of 
kludgey, and do not fill me with confidence that the vendor actually has 
the proper staff or resources allocated to create good standards-based 
APIs -- which, definitely, takes more time than creating a kludgey 
vendor-specific one-off.   Or maybe the vendor actually is 
dis-interested in this because they want lock-in.  Or maybe it's just 
the case that the quality of your APIs doesn't effect your sales at all, 
so it doesn't make (short term at least) business sense to do it well.  
(Heck, the _presence_ of an API has only just begun to effect sales, but 
libraries aren't good enough at judging how good it is, that even a 
crappy API is probably 'good enough' for sales).

One way out of this is definitely open source. We'll work out the best 
practices and standards ourselves, and then we start insisting that 
vendors follow them.  The DLF-DI API is perhaps one example of an 
attempt at this, created from a generalization of the experience of 
library developers.   But the library developer community is also small, 
and generally fairly in-experienced. Creating APIs is done best by 
experienced developers who understand what's going to make the API 
useable or not.

But, anyway, one step at a time. I firmly believe that even 
vendor-specific kludgey APIs are better than no APIs at all -- we learn 
how to do better by trying.

Jonathan