Google Cloud gives open-source data vendors a break. Will that save open source?
We've been getting early warnings from a number of open-source vendors that they will be "announcing something big at Google Next" for a few days now. Yesterday, the announcements from seven -- if not magnificent at least leading -- open-source vendors all came at the same time. An evaluation on the status quo, and the quo vadis, of enterprise open source has been long time coming for us, so this is a good time to do this.
What was announced by Google Cloud yesterday was a series of strategic partnerships with leading open source-centric companies in the areas of data management and analytics. The companies are an all-star cast of sorts: Confluent, DataStax, Elastic, InfluxData, MongoDB, Neo4j, and Redis Labs.
The partnerships will offer fully managed services running on Google Cloud, a single user interface to manage apps, and unified billing -- one invoice from Google Cloud that includes the partner's service. What this means is that the services will be fully integrated in Google Cloud, users will pay one bill, and vendors will get a cut of the profits from Google.
Also: Everything you need to know about the cloud, explained | Top cloud providers 2019
At a first level, this seems like a good move, and a good thing. It's a win-win-win situation for all sides: Open-source vendors, users, and Google. There are nuances that deserve highlighting, but let's start at the beginning.
A way out for open-source vendors?
For vendors, this is a good thing, because it lets them do what they do best, which is build open-source software, without having to worry about building their own cloud infrastructure, or cloud vendors stealing their lunch.
Software vendors have a job, which is to build software. The kind of infrastructure software that these vendors build clearly has an interplay with hardware, and the evolution of the cloud has largely influenced software architecture. But the job of these vendors is not to procure, build, develop, or maintain hardware. Cloud vendors do a pretty good job there.
What complicates things is the fact that today a significant part of software such as data management software runs in the cloud. The economy of scale and technical leadership that cloud providers offer can't easily be matched by on premise infrastructure. So as workloads move to the cloud, the expectation is for infrastructure software such as data management software to run there, too.
Google is giving open source vendors a break, but that's not the end of open source's woes.
Of course cloud vendors can, in many cases do, offer infrastructure software as well. So rather than just rent out hardware, pre-packaged software such as a database can run on that hardware. This is convenient for users, who don't have to put the extra work of setting up the software in the cloud, and get one bill including hardware and software cost from their cloud provider.
Sometimes, this is proprietary software developed in-house by cloud vendors. This is fair game, and users can choose whether they want to use this, or keep using their software of choice by another vendor. AWS, for example, has an entire product line of databases it has developed (or acquired, e.g., Neptune) and is offering on its cloud, and many people choose to use these.
Some obvious issues for users that choose this option is cloud vendor lock-in and best of breed: Proprietary cloud vendor software by definition only works on the specific vendor's infrastructure, and its quality may not be on par with products developed not as part of a big portfolio, but as the only thing a specialized vendor does.
Strip mining
What's not fair game, however, is when cloud vendors attempt to take open-source infrastructure software and offer it as a service on their platform. This practice, known as strip mining, is essentially an act of appropriating something cloud vendors have contributed very little, if anything, to. Even worse, this is practically endangering the very existence of the vendors who have built this open-source software.
In order to fully explain this, we need to take a step back to look at the origin and properties of open source, as well the business models for monetizing open source.
There are small scale open-source projects, projects for which development and maintenance is funded through subsidies, donations, or crowdfunding, or by people who have a day job on a best-effort basis. For this type of project, a loose organizational structure, and gift economy business models can work. Some of them may be enough in demand to be able to get people who contribute to and/or are experts on them some income, mostly via consulting.
For large scale/enterprise software, however, this does not work. To build critical enterprise software, organizational structure and capital is needed. But the open-source model brings advantages, which is why it is used. Open source attracts contributions and talent on a much wider scale than proprietary software, facilitating innovation. It lowers friction to use and shortens sales cycles by establishing a toehold in organizations.
Monetizing open source is complicated.
Organizations building this software must be sustainable. Monetizing open source, however, is not easy. The business models they have at their disposal come down to professional services, open core, and software as a service.
The professional services model does not scale, and is only known to be working for one vendor, Red Hat, which has a massive installation base that makes this work for it. Therefore, the most reasonable/successful strategy seems to be the combination of open core and software as a service, largely in the cloud.
Open core means keeping the core of the software open source, and offering proprietary extensions on top of it. The software is still usable without the extensions, but the extensions add value for enterprises. Without them, users would have to develop functionality themselves, so they are better off "outsourcing" this to the original software creators, and happy to pay for it. Paying essentially means one of two options.
Monetizing open source
Option No. 1 is purchasing the enterprise edition of said software, and running it on premises. Even though there are cases in which this may make sense, or maybe has to be done for non-technical reasons such as regulation, less and less organizations are eager to do this. This doesn't just mean spending resources on hardware, it also means spending effort on keeping the software running.
Option No. 2, which is using the software as a service in the cloud, makes increasingly more sense to more organizations. It practically means outsourcing both hardware and software infrastructure to the ones who are best suited to do this, and focusing on their core business.
Must read
- Google Cloud Platform: An insider's guide (TechRepublic download)
- Vendor comparison: Azure, Amazon AWS, and Google Cloud (Tech Pro Research)
This is why open-source vendors are so precious about offering managed versions of the software as a service in the cloud. Doing this across clouds, and on premise, is in fact an edge they have over cloud providers. This is why when cloud vendors do what AWS does, i.e., offering open-source software as a service themselves, it means they are directly competing with the creators of this software, effectively Blitzscaling them out of business.
This, in turn, is why the so-called Commons Clause has evolved as an addition to existing open-source licenses. In effect, what this clause does is to prohibit cloud vendors from using software that way. You could reasonably argue it's a self-defense mechanism, and works to ensure the sustainability of open source in the long run. This, however, is not what the Open Source Initiative (OSI) thinks.
Open source is essentially part of the commons. Elinor Ostrom, who won the Nobel in Economics in 2009 for her work on this, has laid out some design principles which have to be considered when discussing open source, too.
The OSI's mission is "to promote and protect open-source software and communities." The OSI states that for over 20 years it has worked to raise awareness and adoption of open-source software. That may be true, but by sticking to existing definitions, and refusing to acknowledge that the Commons Clause is necessary to ensure the sustainability of organizations building open source, the OSI is not helping open source.
Twenty years ago, the cloud did not exist. A world in which cloud vendors are allowed to do as they please with open source, will eventually be a world in which cloud vendors place a stranglehold on open source, leaving only a marginal role for independent open source development.
We have to wonder if this is really what's best for open source. We also have to wonder if the OSI's own business model, based on sponsorships, with AWS being listed as a premium sponsor, could be interfering with its good judgment.
Google Cloud Next
A step in the right direction, but let's not get excited just yet
It does not have to be that way though, and the Google Cloud announcement shows this. Software vendors use cloud infrastructure, as much as cloud vendors use software, with the goal of offering a service to end users. As opposed to cloud vendors, however, open-source vendors pay cloud vendors for their use, as they can't get away with using it for free.
Google Cloud has just decided to do the right thing and give a cut of this integrated offering to open-source vendors. This is a step in the right direction, but there's many questions that we don't have the answers to right now. For example, we don't know what kind of deal these vendors have gotten, whether it's a fair one based on transparent auditing of actual usage data on Google Cloud.
When it comes to advertising data, for example, Google is not exactly known as the pinnacle of transparency. We also don't know whether Google would be offering that deal if it was in AWS's shoes -- leading the cloud market, that is. Plus, with no "constitutional" mechanism to enforce and monitor a co-existence business model, there's probably not much stopping Google from changing its terms if it so chooses at some point.
Last but not least, those seven vendors are a good start, but there are many -- many more open-source vendors out there who would probably like to cut a similar deal. Who gets to be included is still at the sole discretion of cloud vendors. This could easily create a caste system in the open-source world, with an underprivileged class of vendors being excluded and deplatformed, for one reason or another, which would lead to their marginalization.
This announcement is good for Google Cloud: It positions it as a good open-source citizen, hoping this will translate to bigger market share. It's good for open-source vendors, too: They get to be prominently featured, they have one less headache, and one more revenue stream -- though it remains to be seen how substantial that will turn out to be. And it's good for users: They get frictionless access to the services.
But it's far from being a solution for open source's predicaments, which are really the predicaments of the commons. This only solves part of the problem, on uncertain terms, and has uncertain future. We will continue this note to show some of the issues it does not solve, and explore possible solutions, in the near future.