There's been a lot of chatter about who does and does not contribute enough to open source projects, with AWS taking the most abuse. Even a cursory review of Google developer Felipe Hoffa's GitHub data, however, suggests that there isn't just one open source parasite that takes more than it gives—there are many.
Oh, and you are one of them. Guaranteed.
We take and take and take
After all, no matter who you work for, only a small percentage of a company's engineers contribute to open source projects. True, as my Adobe colleague Michael Marth has highlighted, "Many Adobe employees (heavily) contribute to ASF projects under their private user handle. Potentially same for Google, MS, etc." Actually, it's not even a question of "potentially." It's absolutely the case that many developers contribute code to GitHub under private emails. As such, a great deal of contributions aren't affiliated with their employers.
Even so, it's almost certainly the case that this undercounting is roughly equal between companies. Though we can inflate the numbers arbitrarily, it's doubtful that the numbers change dramatically.
One exception might be Red Hat, which employs thousands of developers yet only 442 show up as contributors on GitHub. Given that the company releases all of its code under an open source license, Red Hat may be the one company whose GitHub count is truly out of whack with reality.
For the others, even accounting for some underestimating of their contributors, no one is giving nearly the same as what they get in return. Even at the top of the open source food chain, companies like Microsoft and Google have orders of magnitude more engineers than they have open source code-contributing engineers. Google can rightly boast of roughly 900 developers contributing to open source projects. By some estimates, however, the company employs nearly 29,000 engineers. That's roughly 3% of its engineering base.
How about Microsoft, the top employer of GitHub contributors, with a whopping 1,303 GitHub contributors. That's impressive, but maybe less so in light of the company's roster of roughly 50,000 engineers on its payroll. That's just 2.6% of its engineering force.
SEE: Linux distribution comparison chart (Tech Pro Research)
The numbers on Amazon's engineers are harder to find (one commentator in 2011 put it at 1,700 software engineers, a number that has almost certainly mushroomed since then), but my hunch is that it's not too different from that of Microsoft's and Google's as a percentage. Ditto IBM which, despite its pioneering work in Linux, OpenWhisk, and more, can only tally 300 GitHub contributors despite tens of thousands of engineers on its payroll.
In other words, everyone is a net consumer of open source, and gives comparatively little back. Every single large company on Earth. (Well, maybe except Red Hat, but it's the exception that proves the rule.)
Not that there's anything wrong with that
As Hadoop founder Doug Cutting asserted: "Expecting contribution to open source proportional to benefit from it is insanity." It's simply unrealistic to expect everyone to give back line-for-line what they get from open source.
It's not unrealistic, however, to ask corporations to self-interestedly pay committers to projects from which they benefit. The problem, as GitHub's Nadia Eghbal described in an excellent talk, is that open source presents the classic tragedy of the commons, wherein firms benefit from others' contributions and have little incentive to contribute themselves.
SEE: How to get an open-source job (ZDNet)
The only issue with this corporate view, however, is that it's wrong.
In a world defined by software, companies that rely completely on the generosity of other companies to build and maintain the open source software upon which they increasingly rely are foolish in the extreme. Adam Rackis has highlighted why it's weird to be unwilling to pay for open source software because it's free, but Shiya Lou has an even better takedown of the inanity and how it hurts the companies unwilling to pay:
Engineer: There's a thing in SQL Server Enterprise blocking us
Company: Let's set up a call next week with them an ongoing discussion to resolve it next quarter
Engineer: There's a thing we need in babel, can I spen[d] 2 days with a [pull request] for it
Company: lol no it's their job
Getting involved in the open source projects that matter to a company, in other words, gives them more ability to influence their future today, even as dependence on a vendor results in putting one's future in the hands of that vendor to resolve on their timetable. It's simply not smart business, not if an open source alternative exists and your company already depends upon it.
In sum, the GitHub contributor counts should be much higher, and not merely for those in the business of selling software (or tech, generally). Any company defined by software—and that's your company, too—needs to get more involved in both using and contributing open source software.
- Most companies can't buy an open source community clue. Here's how to do it right (TechRepublic)
- Why serverless computing makes Linux more relevant than ever (TechRepublic)
- How Red Hat aims to make Kubernetes boring...and successful (TechRepublic)
- Google's real Kubernetes magic is all about community, not code (TechRepublic)
- Why DIY Kubernetes projects could be a really bad idea for your business (TechRepublic)
- Amazon jumps on Kubernetes bandwagon (ZDNet)
- Why developer evangelism is the secret to the success of Kubernetes (TechRepublic)
Matt is currently head of the developer ecosystem at Adobe. The views expressed are his own, not those of his employer.
Matt Asay is a veteran technology columnist who has written for CNET, ReadWrite, and other tech media. Asay has also held a variety of executive roles with leading mobile and big data software companies.