See Full Story
We've seen the rise of open source software in the enterprise and also beyond the IT industry, but the real keys to openness and its advantages in today's technology world -- where efficient use of cloud computing and supporting services are paramount -- exist in open application programming interfaces, or APIs. Open source software continues to be a critical part of software development, systems administration, IT operations and more, but much of the action in leveraging modern cloud computing and services-based infrastructures centers on APIs. Open APIs are the new open source.
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?
It's too long to repost here, but my wiki page on the different types of openness may shed some light on the discussion, see: https://sites.google.com/a/laminack.com/why-open-source-is-good-for-business/home/dimensions-of-openness
Please read the article and not just the hedline. My point is that the APIs are where a lot of the action is and the same kind of buzz that fueled open source. Open source still has its advantages and benefits that cannot be matched by APIs, but OSS supporters and vendors need to be aware the closed competition is also evolving and getting smarter ... and more open.
You wrote that "The fact is, Amazon Web Services APIs are open enough." If I may paraphrase, you are arguing that a proprietary API, used to access a proprietary service, is "open enough" if it is "open for anyone to USE."
Please allow me to respectfully submit that this definition is fundamentally flawed and intensely misleading.
In the 1990's, as a Microsoft employee, I sold this very same argument on Microsoft's behalf: that the Windows API was "open enough."
AMAZINGLY, people bought this argument, back then. Every line of code that they wrote to Windows' API locked them more firmly into (a) the Windows API and hence into (b) Microsoft as the sole vendor of that API (failed "zombie projects" such as WINE, WABI, and Bristol aside). Writing a line of code to the Windows API was like giving Microsoft a line of credit against your future earnings...but people did it, because it gave them a short-term time-to-market advantage.
SURELY, the industry hasn't forgotten Microsoft's utter dominance of the PC computing industry...has it? Have we forgotten that Microsoft's dominance was based ENTIRELY on the choice, by independent software developers, to target Microsoft's proprietary Windows API? Have we forgotten why Microsoft's CEO, Steve Ballmer, worked up a sweat jumping around on stage chanting "developers, developers, developers, developers" (http://www.youtube.com/watch?v=8To-6VIJZRE)?
An API that is 'open for anyone to use,' but which is not defined by "open source, open design, open development, and open community" is NOT open. It is a "proprietary API." There's nothing open about it -- except that it is an "open invitation to vendor lock-in."
API lock-in is inevitable. Every paradigm needs its API standard, and every line of code written to that API locks in that standard even further. The issue, therefore, is not API lock-in; it's VENDOR lock-in. What is needed is a vendor-independent API, backed up by vendor-independent code.
Fortunately, for the cloud computing paradigm, that vendor-neutral API standard already exists: OpenStack (of which my employer, Rackspace, is a co-creator). OpenStack's APIs are truly open, are developed by an open process, with open governance, and are backed up by open source implementations. OpenStack's open source and open APIs have been adopted by a "who's who" of the computing industry (http://openstack.org/community/companies), and their contributions have made it the fastest-growing open source project in history.
Why are these companies adopting OpenStack? In brief, because they understand the difference between 'proprietary APIs' (such as Amazon's) and 'open APIs' (such as OpenStack's).
And now, Jay, I hope that you do, too. :-)
Director, Developer Relations
In this article, Jay Lyman completely ignores one of the most dangerous aspects of closed/proprietary software -- specifically that when you can't examine the source code, you don't know what the code's going to do. Specifically, what will it do to you or your business? How will it use or abuse your data?
Only if a software engineer can examine the source code can you have any level of confidence that the API does nothing nefarious in addition to what the provider claims it does. With Free Software (i.e. free as in freedom, not free as in free beer), there's a worldwide community of programmers who are likely to have taken a look at the code. So even non-programmers who can't understand the code themselves can feel secure that any software that does anything it shouldn't will be found out and publicized very quickly.
Remember, sunlight is the best disinfectant!
The point about Free Software is not that you can write software to work in somebody else's walled garden, but that you can modify it and distribute the results under the same or compatible licenses. This is true just as much for cloud computing as for desktops and other devices. Being able to use only the vendor's instance of software is not nearly open or Free enough.
I work with FLOSS Manuals on collaborative documentation of Free Software, and I have had an instance of their Booki/BookType Free Software set up for my other work as Program Manager for Replacing Textbooks at Sugar Labs. It is vital to what we do that we can modify this software for use on our own server, not least that we can localize it for those writing textbooks for millions of children in more than 40 countries around the world. We are also looking toward the time when we integrate education software into our textbooks, a function not currently supported in Booki/BookType.
Similarly we run customized installations of Wikimedia software for the Sugar Labs Wiki; Pootle for localizing Sugar into a hundred languages; and Moodle for coursework and classroom management on school servers in many of our deployments.
Apparently such freedoms to get on with the mission are inconceivable to many in corporate America and elsewhere. It will, however, be second nature to students in our programs, who will graduate from high school in coming years with twelve years of experience in computers and in Freedom.
If your company is happy under vendor lockin, then good luck to you. You'll need it.