“Open source purity contests are not uncomfortable, they are just boring,” said Andrew Shafer, and he’s right. This latest “contest” in question arose from Kelly Sommers’ reaction to Amazon CTO Werner Vogels’ tweet, complaining that Microsoft was hiking the cost of running its software on rival clouds so as to push customers to run workloads on Azure. Sommers’ argument was hardly germane to Vogels’ tweet, but it nonetheless kicked off a contentious discussion of what cloud providers like AWS “owe” to the open source code they monetize.
It’s an abysmally tired debate, but this time it did yield some interesting insights. Here are three.
For one thing, measuring open source value isn’t as simple as counting up lines of code. Or contributors. In Linux, for example, it was long the strategy of interested parties to simply hire the top contributors to the Linux kernel. You could go from zero to hero simply by hiring a top 10 kernel committer, without really doing much beyond supporting their salary. This is one way of fostering open source, but hardly the best.
It’s also perhaps not helpful to point to big-name projects as the truest indicator of open source bonafides. AWS recently released Firecracker to much industry praise, but is that better than smaller, less visible contributions? Not according to AWS engineering exec (and previously Red Hat engineer) Matt Wilson: “I personally see much more value in multiple small, scalable, secure building block projects, compared to extremely large ones. Combine it with a lot of funding of 501(c)(3) type Foundations and basically catapulting open source via the invention of modern cloud infrastructure.”
SEE: Vendor comparison: Microsoft Azure, Amazon AWS, and Google Cloud (TechRepublic Premium)
In such a world the cool projects aren’t monetized by a single vendor, because that leads to them closing off code in order to pay the rent. By pushing important projects to foundations (as Google did with Kubernetes, moving it to CNCF), true communities can flourish around them.
But regardless of the foundations, Wilson’s point about smaller building-block projects rings true. Large-scale projects like Firecracker are of course important, but smaller projects that developers can assemble to build larger projects/products can make a bigger difference over time. Things like s2n, which fixed the OpenSSL security problem, can have a huge, positive effect that ripples throughout the industry.
Everyone is a taker
However, the biggest problem with pointing fingers at this or that company for not contributing is that it is always a completely arbitrary and incorrect assessment. Why? Because while we rightly laud Google, for example, for its incredible contributions of TensorFlow and Kubernetes, no one seems to remember that it’s the same Google that ran over 100,000 servers using Puppet…without paying Puppet Labs a dime (and, as near as I can tell, without contributing code, either).
This isn’t to criticize Google. The same sort of thing happens at every organization on the planet, as Shafer indicated: “The implication of OSS [open source] is more value will be created than captured…[T]he imbalance is inherent….[I] can’t think of one big company that couldn’t be criticized for their open source citizenship.” Even open source-only organizations like Red Hat benefit dramatically more from inbound open source than they make available as outbound open source. It’s not that companies are greedy–it’s just how open source works.
SEE: 20 quick tips to make Linux networking easier (free PDF) (TechRepublic)
Indeed, Miguel de Icaza, the developer behind the GNOME, Mono, and Xamarin projects, remembers that his former company (Ximian) was nearly bankrupted by Red Hat giving its software away for free. Red Hat was just abiding by the freedoms the open source license afforded, as AWS, Microsoft, Google, and every other organization you can name do today.
That’s the bargain of open source.
We should keep that implicit bargain in mind when figuring out what the future of open source looks like. Lately, it has looked less open, as companies increasingly close off code in order to make a buck. But, as de Icaza has stressed, this experimentation will likely continue: “The key here is that you might have a great product, but you might not have an ideal or viable monetization channel. All these licensing discussions are rooted on repurposing the existing assets (tangible or not) to monetize the channels.”
Makes sense. But along the way let’s not criticize those who take advantage of open source freedoms (every single one of us) while giving back far less than we give (every single one of us).
Author’s note: The original version of this story incorrectly stated that Redis Labs had not actively contributed to Redis before 2015. This is inaccurate. In fact, Redis Labs has been a longtime, important contributor to the project, as it is today.