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.
Open source, open standards, open clouds, and particularly open data continue to serve as pillars of modern IT openness, but APIs have quickly emerged as equally if not more critical. Here’s why: Many organizations may inquire or investigate open source software as they set about leveraging cloud computing infrastructure, services and practices, but they soon find that they are dealing much more with APIs than with source code. Both customers and providers indicate an initial interest in open source and source code, but they soon find the APIs to be the more appropriate point of interface and integration.
Open-API Buzz
Several other trends are playing into this shift — which does not negate advantages of open source, but rather seems merely to overshadow them in many instances today. Environments and strategies are defined by cloud computing, services and devops — the confluence of application development and deployment via IT operations.
Devops is a driver of API importance, given it is often a common meeting place among both software developers and system administrators. Another trend driving open API significance is polyglot programming, whereby several different languages and frameworks, including Java, HTML5, node.js, PHP, Python, Ruby, Scala, Erlang and many other languages are the basis for applications, whether mobile, Web, enterprise, consumer or all of the above. Polyglot programming is also apparent in today’s PaaS offerings, which continue to broaden their language support.
We also see services and architectures such as SOAP, REST and JSON contributing to an API-centric world, given they all hinge to some extent on API integration. Another trend that increases the importance of open APIs is the data deluge and so-called “big data,” which marks an explosion in both the sources of data and technology for storage and management of it. Here, open source continues to play a significant role with open source MySQL and PostgreSQL databases, NoSQL databases, memcached, Hadoop, Cassandra and other technologies increasingly in the mix. Open data and open APIs for handling and managing data are also rising in prominence.
What’s more, it seems open APIs are getting some of the same buzz and consideration from decision-makers that marked the rise of open source software a decade ago. When it comes down to what many large customers and users are trying to do, whether enterprises or service providers, open APIs are crucial.
‘Open Enough’
There was a time 10 years ago or so when open source was “good enough” — that is, it served as a viable, often lower-cost, lower-hassle alternative to the proprietary software of the day. Today, all software is generally more open, and I believe we’ve reached a point when non-open source software is often “open enough.” The prime examples are cloud APIs from Amazon, which are neither open source nor open standards, necessarily, but are readily and widely available and tend to serve as the de facto standards of the day, including for open source plays on top, such as Eucalyptus. The fact is, Amazon Web Services APIs are open enough to facilitate the creation of integrations, connections and services despite the fact the underlying code is not open source.
Connections to open source continue to be critical, and it appears open source code has become a standard expectation among customers, many of whom are finding out that openness in APIs is just as important. This is also happening as we see the drivers of open source software shift from cost savings and flexibility innovation, performance and ROI. It turns out that, indeed, openness matters — and the growing significance of and respect for open APIs also serve as further validation of open source software methodology.
Loading ...
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.
JL
Jay —
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. 🙂
Respectfully,
Jim Plamondon
Director, Developer Relations
Rackspace
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.