Open APIs fall far short of open source
Useful in short term, but long-term leads to vendor lock-in
A new-ish meme is floating around the tech sector these days that has caused more than a little bit of consternation for advocates of free and open source software: the idea that open APIs are somehow the equivalent of open source.
The latest person to roll this idea out is my friend and colleague Jay Lyman, a 451 Group analyst who’s opinion I respect greatly. In a LinuxInsider column yesterday, Lyman put forth the theory that because of open APIs, “non-open source software is often ‘open enough.'”
I would argue that this is very much not the case.
Lyman makes excellent points, ones that live right where I like arguments to be: in the realm of practicality and not high-falutin’ theory. The crux of his thesis is this:
“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.”
Which, I gotta say, is a darn good way to put it. On a day-to-day level, most developers aren’t interested in digging into the entirety of the source code, however it’s licensed. They just need to plug their code into the existing project, and the APIs are the best way to do that. Couple this with the trend that proprietary software, such as the web services offered by Facebook, Google, and Amazon, are also featuring open APIs, which third-party developers are loving, and you get a recipe for success with open APIs.
But that recipe is like a chocolate cake: it looks great, tastes great, but you can’t live off of it. A chocolate-cake-only diet would soon lead to nutritional problems. That, I would stipulate, is the problem with open APIs: they are tasty and fun to plug code into and hopefully generate more interest/revenue for your own software–but they fall well short of the true benefits of open source code.
To be clear: Lyman doesn’t argue against these open source benefits: he recognizes them, even as he points out that the hoopla about open APIs are overshadowing the broader advantages of open source. Instead, Lyman is making the point that open APIs have risen in prominence and are at least as important as open source as a whole.
Here’s the thing: I think they’re a bit of a trap, no different than the vendor lock-in that comes up when companies use the “open core” gambit: the strategy of releasing a community-based, open “core” version of your software, and then charging more for vendor add-ons. It’s not really lock-in, these open core vendors argue, because you still have a majority of the code for the application and you’re certainly welcome to go use another vendor working in the same space.
Except migrating from vendor to vendor can be costly, contracts usually require a certain amount of time to finish, and the dependency on the vendor is still there, it’s just shifted from the core to those nifty add-ons.
Open APIs shift that dependency into even subtler perceptions: you’re just tacking on to an API, how can that be lock-in? It can be lock-in because you’re still putting in effort to connect your code to the functionality offered through the API channel, and you’re still getting the benefits of the larger software to which you’re connecting.
If you think of vendor lock-in like addictions, then proprietary software is like crack, open core is like X, and on down the line. Open APIs are far less addictive on the lock-in scale: perhaps at the level of cigarettes–but they can still hook you in.
To be fair, any software can be addictive in this metaphor–including free software. Humans love to get dependent on familiar, beneficial things, and that includes making business decisions to stick with a particular free software application just because it’s easier than migrating.
Beyond the problem of lock-in, there’s also the matter of destiny: truly strong open source projects have the huge advantage of communities that can guide the direction of the software’s development to levels that might not otherwise be achieved in a proprietary or open core environment. If open APIs are the only connector to a software project, the destiny of that code lies solely in the hands of the owners. Which means that anyone connecting into the application will have to deal with the changes imposed from the top down.
For me, even more than the lock-in argument, this is why I think that open APIs, while useful at times, are not really as important as true open source.
It’s at this point the free software advocates might be tempted to ride in and start flinging around “we told you so”s at every one in earshot. But they need to be careful: these kind of shenanigans with open core and open APIs happen just as much in the restrictive copyleft family of software licenses as they do with licenses like Apache. Alfresco moved its community edition to the LGPL in 2010, for instance, but they still offer their enterprise edition. In 2009, Lyman’s colleague Matthew Aslett reported:
“In our report, ‘Open Source is Not a Business Model‘, …we found that 23.7% of the 114 vendors we covered were using Open-Core as a vendor licensing strategy. Looking at the stats, over 70% of Open-Core strategy users also used a variant of the GPL or LGPL.”
This is not, as many would try to argue, a purely free software vs. open source licensing issue. That’s another argument for another time. It’s about settling for the easy thing rather than the hard. Open APIs are the easy: there’s no community involvement, there’s few arduous licensing requirements… just a nice plug into a big software ecosystem that might immediately provide a small developer access to more attention and revenue. What’s not to like?
Increased dependency on those larger software vendors who are offering those APIs–and along the way, capitalizing well on the increased third-party enrichment of their product’s ecosystem, thank you very much–is the price paid when open APIs are used in place of open source.
Open APIs are indeed rising in prominence… but their true value needs to be questioned by anyone looking to make use of them.
Read more of Brian Proffitt’s Zettatag and Open for Discussion blogs and follow the latest IT news at ITworld. Drop Brian a line or follow Brian on Twitter at @TheTechScribe. For the latest IT news, analysis and how-tos, follow ITworld on Twitter and Facebook.
Originally published in www.itworld.com