It's true, that APIs are "how you use" Cloud services, just as source is "how you use" desktop or datacenter function. And by analogy it's true that "openness" in APIs might be a good idea, since it's proven such a good idea for source code.
But the real power of "open source development" is in the "open development" of "source," and only implicitly in the "openness" of the source itself. Cases where the source code is available, but without the right to reuse and extend, are righty recognized as "proprietary," not "open" at all.
Similarly, in APIs what would matter would be "open definition" of the APIs, not merely the openness (documentation) of the API -- in short, API *standards*. But "open standards" is exactly how the UNIX vendors of the 1980's mutually throttled each other to death, and how HTML nearly did the same a decade or so later. "Waging standards" is a well-developed art form, a black hole from which few return.
As long as we are beholden to proprietary interests to provide our cloud services, we're at risk of proprietary variances to ensure "lock in." This makes "Open APIs for Cloud Services" a very delicate opportunity, very un-like the early Open Source moment.
To succeed, an "Open API Standards" movement must enlist the vendors from the beginning, rather than by overwhelming them, post hoc, with success (as Linux, Libre Office, GNU, Apache, and the other stars of the OSS galaxy have done). What can we do to ensure that cloud service participate, rather than sabotage?
|
Headline Feeds
Re: Open APIs Are the New Open Source
the different types of 'open'
