 |
 |
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