For all the criticism that Amazon Web Services has received for allegedly stripmining open source software for corporate gain, the company that should perhaps scream loudest is no defenseless startup. It’s Google. At a recent AWS Summit, Amazon Vice President Sandy Carter told the audience that “85 percent of TensorFlow workloads run on AWS.” Couple that with the 51 percent of Kubernetes workloads that run on AWS, according to CNCF data, and it becomes clear that while Google is releasing some of the industry’s most important open source code, it’s AWS that is profiting most from it.
Is this a bad thing? As ever, it depends.
Google: I give and I give and I give
Google is arguably the world’s most important open source contributor, given the projects that emerge from it on an increasingly routine basis.
With TensorFlow, it’s lowering the bar to machine learning at scale. With Kubernetes, it’s changing how enterprises build and deploy applications. With Android, it defines how most of the world communicates. And so on.
While Google has profited from these projects, other companies—and particularly AWS in the case of TensorFlow and Kubernetes—profit more.
In part this is a people problem at Google, one that new CEO Thomas Kurian has promised to fix. As has been true for some time, within Alphabet the Google Cloud Platform has seen heavy hiring, as noted on the company’s most recent earnings call. More people working with more customers to establish more value should equal more good (and more revenue). But still AWS is there, earning most of the cash thrown at the open source projects that Google keeps building.
Kudos to AWS for figuring out how to outsource some of its R&D?
AWS: Taking by giving
Maybe not. After all, this approach (if accurate) isn’t particularly great for AWS, either. At least, not over the long term. As Pivotal executive James Watters calls out, AWS workloads keep trending away from its own proprietary APIs and toward open source Kubernetes. The same happened with Amazon Kinesis giving way to greater adoption of Apache Kafka (pushing AWS to embrace Kafka and build a service around it). Now imagine a world, as Watters does, “where over 50 percent of [AWS] workloads run against an open source community API.”
Suddenly AWS must change if it wants to keep its cloud leadership, or those workloads will move to the cloud that best helps to steer those projects.
In open source, the currency that matters is code: If you want to influence a project’s direction, you must contribute. It’s fine for AWS to coast along on others’ contributions to TensorFlow or Kubernetes when those are somewhat ancillary to its own services, but when AWS customers start demanding vanilla Kubernetes at scale on AWS? Well, this may require a bit more code from AWS.
AWS may be able to have it both ways
Not that everyone completely agrees: One AWS employee noted that “many of our customers select simpler abstractions that scale, but many also select open source. I do not see a zero-sum game here, and AWS invests in both.” In other words, AWS can keep its feet in both camps, though this doesn’t necessarily obviate the need to contribute (nor does the employee suggest that).
More worrying, however, is Paul Ramsey’s contention that rather than open source forcing AWS to become less proprietary, it might result in the opposite effect. As he writes, “People like PostgreSQL [so AWS] brings them in with slightly proprietary PostgreSQL (RDS), upsells to completely proprietary PostgreSQL (Aurora), [and] locks in with some Aurora-only features ... profit! Aping an open source API is the opposite of a good faith engagement.” In this world does AWS have as much incentive to improve the open source “highway” or does it instead focus on paving the on-ramp to its proprietary services?
Time will tell.
My hunch is that AWS will, in fact, do more of both: more open source contributions to key projects and more value-added services to capitalize on the underlying open source popularity. As cloud competition becomes ever more fierce, this really is the only way.
A longtime InfoWorld contributor and former intellectual property lawyer, Matt Asay is currently Head of Developer Ecosystem at Adobe at Adobe. The views expressed are his own and not that of his employer.