Remember the Companies Making Vital Open Source Contributions (infoworld.com) 22
Matt Asay answered questions from Slashdot readers in 2010 as the then-COO of Canonical. Today he runs developer marketing at Oracle (after holding similar positions at AWS, Adobe, and MongoDB).
And this week Asay contributed an opinion piece to InfoWorld reminding us of open source contributions from companies where "enlightened self-interest underwrites the boring but vital work — CI hardware, security audits, long-term maintenance — that grassroots volunteers struggle to fund." [I]f you look at the Linux 6.15 kernel contributor list (as just one example), the top contributor, as measured by change sets, is Intel... Another example: Take the last year of contributions to Kubernetes. Google (of course), Red Hat, Microsoft, VMware, and AWS all headline the list. Not because it's sexy, but because they make billions of dollars selling Kubernetes services... Some companies (including mine) sell proprietary software, and so it's easy to mentally bucket these vendors with license fees or closed cloud services. That bias makes it easy to ignore empirical contribution data, which indicates open source contributions on a grand scale.
Asay notes Oracle's many contributions to Linux: In the [Linux kernel] 6.1 release cycle, Oracle emerged as the top contributor by lines of code changed across the entire kernel... [I]t's Oracle that patches memory-management structures and shepherds block-device drivers for the Linux we all use. Oracle's kernel work isn't a one-off either. A few releases earlier, the company topped the "core of the kernel" leaderboard in 5.18, and it hasn't slowed down since, helping land the Maple Tree data structure and other performance boosters. Those patches power Oracle Cloud Infrastructure (OCI), of course, but they also speed up Ubuntu on your old ThinkPad. Self-interested contributions? Absolutely. Public benefit? Equally absolute.
This isn't just an Oracle thing. When we widen the lens beyond Oracle, the pattern holds. In 2023, I wrote about Amazon's "quiet open source revolution," showing how AWS was suddenly everywhere in GitHub commit logs despite the company's earlier reticence. (Disclosure: I used to run AWS' open source strategy and marketing team.) Back in 2017, I argued that cloud vendors were open sourcing code as on-ramps to proprietary services rather than end-products. Both observations remain true, but they miss a larger point: Motives aside, the code flows and the community benefits.
If you care about outcomes, the motives don't really matter. Or maybe they do: It's far more sustainable to have companies contributing because it helps them deliver revenue than to contribute out of charity. The former is durable; the latter is not.
There's another practical consideration: scale. "Large vendors wield resources that community projects can't match."
Asay closes by urging readers to "Follow the commits" and "embrace mixed motives... the point isn't sainthood; it's sustainable, shared innovation. Every company (and really every developer) contributes out of some form of self-interest. That's the rule, not the exception. Embrace it." Going forward, we should expect to see even more counterintuitive contributor lists. Generative AI is turbocharging code generation, but someone still has to integrate those patches, write tests, and shepherd them upstream. The companies with the most to lose from brittle infrastructure — cloud providers, database vendors, silicon makers — will foot the bill. If history is a guide, they'll do so quietly.
And this week Asay contributed an opinion piece to InfoWorld reminding us of open source contributions from companies where "enlightened self-interest underwrites the boring but vital work — CI hardware, security audits, long-term maintenance — that grassroots volunteers struggle to fund." [I]f you look at the Linux 6.15 kernel contributor list (as just one example), the top contributor, as measured by change sets, is Intel... Another example: Take the last year of contributions to Kubernetes. Google (of course), Red Hat, Microsoft, VMware, and AWS all headline the list. Not because it's sexy, but because they make billions of dollars selling Kubernetes services... Some companies (including mine) sell proprietary software, and so it's easy to mentally bucket these vendors with license fees or closed cloud services. That bias makes it easy to ignore empirical contribution data, which indicates open source contributions on a grand scale.
Asay notes Oracle's many contributions to Linux: In the [Linux kernel] 6.1 release cycle, Oracle emerged as the top contributor by lines of code changed across the entire kernel... [I]t's Oracle that patches memory-management structures and shepherds block-device drivers for the Linux we all use. Oracle's kernel work isn't a one-off either. A few releases earlier, the company topped the "core of the kernel" leaderboard in 5.18, and it hasn't slowed down since, helping land the Maple Tree data structure and other performance boosters. Those patches power Oracle Cloud Infrastructure (OCI), of course, but they also speed up Ubuntu on your old ThinkPad. Self-interested contributions? Absolutely. Public benefit? Equally absolute.
This isn't just an Oracle thing. When we widen the lens beyond Oracle, the pattern holds. In 2023, I wrote about Amazon's "quiet open source revolution," showing how AWS was suddenly everywhere in GitHub commit logs despite the company's earlier reticence. (Disclosure: I used to run AWS' open source strategy and marketing team.) Back in 2017, I argued that cloud vendors were open sourcing code as on-ramps to proprietary services rather than end-products. Both observations remain true, but they miss a larger point: Motives aside, the code flows and the community benefits.
If you care about outcomes, the motives don't really matter. Or maybe they do: It's far more sustainable to have companies contributing because it helps them deliver revenue than to contribute out of charity. The former is durable; the latter is not.
There's another practical consideration: scale. "Large vendors wield resources that community projects can't match."
Asay closes by urging readers to "Follow the commits" and "embrace mixed motives... the point isn't sainthood; it's sustainable, shared innovation. Every company (and really every developer) contributes out of some form of self-interest. That's the rule, not the exception. Embrace it." Going forward, we should expect to see even more counterintuitive contributor lists. Generative AI is turbocharging code generation, but someone still has to integrate those patches, write tests, and shepherd them upstream. The companies with the most to lose from brittle infrastructure — cloud providers, database vendors, silicon makers — will foot the bill. If history is a guide, they'll do so quietly.
this will be fun ... (Score:4, Funny)
Generative AI is turbocharging code generation, but someone still has to integrate those patches, write tests, and shepherd them upstream. The companies with the most to lose from brittle infrastructure — cloud providers, database vendors, silicon makers — will foot the bill. If history is a guide, they'll do so quietly.
over linus' cold deady body :D
Re: (Score:2)
Linus already said he's neutral regarding AI thinking it is overhyped and he will integrate it when useful and otherwise not. Probably a sane position between the "Everything needs to be AI!" and "We all die because of AI" people.
Companies still getting a free ride* (Score:5, Insightful)
What you should be remembering is that these are not examples of companies providing "vital contributions" but that the vast majority of companies are freeloaders who do nothing to help the very open source community that they rely on every day. These companies are still getting a free ride, they simply have their own requirements for the software and so the community benefits. The GPL is written specifically so that individual efforts to assist in improving the software will benefit everyone that uses that software.
Oracle only spends money when theyt benefit from. This isn't charity or "mixed motives", it's entirely profit motivated and it should be recognized as such.
Open source developer should de-prioritize all communications from companies that aren't making contributions proportional to their profits because they are doing less than the average user which makes zero profit.
Re: Companies still getting a free ride* (Score:2)
I do not understand this attitude at all. While I think that we definitely should not mistake the open source contributions of these companies as benevolence, demanding a certain amount of contribution based on the company size is like bring the Oracle licensing structure to open source.
The way I see it, freeloaders should be welcome. All contributors started as freeloaders. If the point of open source is anything other than making technology available to everyone, then what is the point?
Re: (Score:3)
There is a world of difference from freeloading (appropriating someone else's work for personal use) and repackaging someone else's work to make a profit (AI companies take note). Me making my own Mickey Mouse t-shirt is perfectly appropriate. Me selling them is a different animal entirely.
The point is that it is not making technology available to everyone, but more akin to the tragedy of the commons. Littering in the local park because you are free to do so eventually means the commons won't be worth havin
Re: (Score:2)
Re: (Score:2)
demanding a certain amount of contribution based on the company size is like...
Except that's not what I wrote. I wrote that they should be de-prioritized. For-profit users (businesses) that don't contribute should simply be less important than non-profit users (normal people). Why? The simple fact is that non-profit users care about the software and improving it because they use it while for-profit users only care about making profit from the software. If they aren't going to share the profits that would support the project then you are better off serving normal users who want to see
Re: (Score:2)
It seems to me that if you're going to use this "deprioritization" as a form of leverage to extract concessions from the company. . .you are making a demand.
This idea that companies should be required to tithe to open source has been gaining popularity recently and it's really antithetical to pretty much any open source license and the entire spirit of open source. We shouldn't worry about who the users are or what they're doing with the software. Users are users and they should all be treated the same.
Re: (Score:2)
It seems to me that if you're going to use this "deprioritization" as a form of leverage to extract concessions from the company. . .you are making a demand.
Except the company's use of the software is entirely voluntary. They can replace your project is with something else. Nobody is entitled to anything more than your source code.
This idea that companies should be required to tithe to open source has been gaining popularity recently
Not at all because the software is still 100% free for them to use and modify. The issue at hand isn't the software, it is software support. You are free to have the software, share it, fork it,, report flaws, or submit patches. Meanwhile, the author is free to ignore you entirely or simply abandon the project.
and it's really antithetical to pretty much any open source license
What you are entitled to
Re: (Score:2)
It's open source. If a company wants a feature because it helps them, they have two options - do it themselves (and either release the change or keep it to themselves), or ask someone to do it.
Asking the maintainer for a feature request happens all the time - most software projects have feature requests lists a mile long. It's up to the maintainer to pick and choose what they want done - maybe a Fortune 20 company makes a feature request that sounds fun to the maintainer - should the fact that company never
Spin Man (Score:5, Interesting)
Not surprising that a person hired to sell to developers has positive things to say about their big corporation's gracious donations. Yeah, self interest is great but that only goes so far. If they want developers to feel like they are gracious, they have a long way to go.
Like for example they could donate the JavaScript trademark that they have little stake in. Or stop using Java or VirtualBox as license traps to ensnare. Weaponized generosity isn't very generous.
Re: (Score:2)
Just what we need, a boat made of floppies. It's cool until your boat becomes the Great Pacific Garbage Patch.
I have to wonder (Score:4, Insightful)
How much of this long, rambling story is just an attempt at self-justification for taking a high-paying job from a company that's actively evil? Maybe he's hoping to work for Meta next...
Re: (Score:3)
Re: (Score:2)
Well, it is Oracle.
The company is infamous for buying Sun Microsystems and shutting down the OpenSolaris project, inspiring the forks LibreOffice and MariaDB, fiercely protecting the 'Java' trademark in spite of OpenJDK releases by other parties and letting OpenSPARC wither and die.
Why should we remember them? (Score:5, Insightful)
Lines of Code (Score:2)
And that's why we need Torvalds. If nobody tells people "your code is crap" if it is, companies will maximize the lines of code they submit instead of the quality. Lines of code can be measured, quality is hard to measure and only reported delayed and anecdotally. Yeah, there are five bugreports three months later when the distributions ship the kernel. But the companies already got praised months ago for contributing so much.
Back in the day... (Score:3)
I remember when IBM, SGI, Infornix, Oracle, and HP first got involved in Linux. At the time, I included patches from some of them in the Functionally Overloaded Linux Kernel.
I proposed, back then, a simple league table for commercial support of Linux: Every new major feature or software product got so many points, and every bugfix release got a smaller number of points. Kernel features that made it into the mainstream kernel would qualify as goals for, kernel features and products discontinued were goals against. Closed-source contributions got half points, and were also considered goals against.
It would then be obvious which companies were serious and which were piggybacking, and it would also be clear who understood the philosophy, not just the opportunity.
Such a table would have ensured that nobody forgot the companies who contributed. Quite the opposite. There'd be an incentive to encourage the team you supported to improve position in the table.
Of course, no such league table ever happened. I could have maintained such a table without difficulty, but it would require the vendors to openly say what they'd contributed. I couldn't invent one out of thin air.
So I'd say Oracle has to look at themselves, not just the Linux community.