“Open” is one of the most nebulous terms in technology, yet it’s also a label that oddly carries huge emotional baggage. To be open is to be on the side of truth and righteousness. To be closed or proprietary is, well, on par with drinking unicorn blood. (Hint: only Voldemort does that.)
The problem, however, is that there are no hard and fast rules for “open” or “closed,” yet we act as if there were. Perhaps the best way to sniff out true “openness” is to look to developers to see what they feel comfortable building upon. With developers as our guide, the stark differences between open and closed become much more subtle and interesting.
In the good old days of open source…
Once upon a time in open source land, there was a clear definition of what constituted “open”–the Open Source Definition. Shepherded by the Open Source Initiative (of which I’m a former board member), the OSD defined the license terms that could count as open source. Everything else was, by extension, not open source, also known as closed, proprietary, evil.
In that day, all you needed to be counted among the open crowd was an OSI-approved license that adhered to the OSD. I worked for a few such companies, and behind the scenes one thing became clear: You could hide a lot of proprietary behavior behind an ostensibly open source license. In fact, the more freedom-loving the license (read: GPL and its variants), the easier to disguise a proprietary business model.
Developers picked up on this, and started to move en masse away from “copyleft” licensing toward the more laissez-faire/permissive Apache-style licensing. At the same time, developers figured out a much more nuanced definition of “open,” one sometimes at odds with prevailing notions.
What developers think about open
Again, the litmus test for “open” used to be an OSI-approved license governing the code, but a software license says nothing about all the other (and arguably more important) attributes of software services. For example, in a world governed by data, “open data” suddenly becomes more important to have than an open license to the underlying software.
The problem, however, is that even “open data” isn’t super meaningful. As Tim O’Reilly, a longtime advocate for open source, has noted, “cheap and easily accessible” is a reasonable surrogate for “open data.” Google Maps, by this calculus, isn’t open in any OSD sort of way, but it’s readily accessible to developers, and has thrived as a result.
Or, take the cloud.
Redmonk analyst Stephen O’Grady is right to characterize public cloud computing as a clear and present danger to open source vendors, even as its impact on open source software, more generally, may be benign. In fact, we used to castigate the cloud companies like Google and Yahoo! for hoarding open source code–using but not contributing back–and yet, as the market evolved, these same companies have become the biggest beneficiaries of open source because they can freely give away software without it negatively impacting their revenue. If anything, it helps.
I suspect the same will be true of public cloud companies like Amazon Web Services and Microsoft (Azure), which today mostly guard their code. At some point, they’ll likely start sharing it. Today, we’ll criticize them as “closed” and tomorrow we’ll herald them as “open” but if we watch our developer friends, we’ll see that they already view these vendors as open, given that developers increasingly build the future on these ostensibly closed platforms.
Developers aren’t stupid. If they turned first to Linux as a server platform because it gave them power and authority to build what they needed to build, their shift to public clouds is arguably open in the same way. It’s a matter of convenience, as O’Grady told me recently, but that convenience points to a deeper subtext of openness.
Are developers right?
Ultimately, as Facebook data engineering impresario Mark Callaghan noted of Amazon’s Aurora database, “I hope it raises the bar for what we expect from a cloud DBMS, open or not.” Spoken like a true developer with a highly pragmatic view of openness: Give me access at a reasonable price and get out of the way.
I’ve argued that this quest for convenience could cause developers to code themselves into a closed box, but developers have proven adept at skirting around true traps to their productivity. So, if you want to get beyond labels of “closed” and “open,” just analyze what developers use day-to-day.