A sagely guru by the name of Yogi Berra imparted some words of wisdom that I periodically revisit: “In theory there is no difference between theory and practice, while in practice there is.” Though intended for comedic effect, it rings true (as all good comedy does).
It’s easy to get so wrapped up in what we believe something to be, or should be, that we mistake it for reality. The more invested one is in a theory; the closer theory and practice can appear.
For its many devotees, open-source software is a paradigm of unparalleled beauty. Chief among its charms is that open-source software is of, by, and for the community. This is why large, traditional proprietary software companies assumed their battle stations when open source appeared on the radar: if users could collaborate to make their own software, who would pay money for theirs?
Roughly 30 years later, open source did not lay the tech giants low, as they feared. It played out that way because, after seeing what open source could do, rather than distancing themselves from it, many traditional tech powers lined up to grab a piece of the open-source pie. The cozying up didn’t happen all at once, but brick by brick, open source rose from a foundation to a towering evidence.
So why am I discussing this now? Not to dispense an open-source history lesson — there are plenty of those — but to discern the locus open source has reached, and extrapolate its trajectory from here, in light of recent indicative developments.
Open Source Meets Open Arms
Let’s first tackle the now, and then address the future (seems sensible, right?).
Last month, Google and Microsoft led a cadre of tech companies in creating the Rust Foundation. Obviously, this is neither the first nor largest contribution to an open-source project by private tech vendors. The Linux kernel has been flush with cash from the most dominant tech companies out there for many years.
Still, the creation of this new body marks another noteworthy instance in which proprietary software companies took the initiative to found and steward a nonprofit project. It’s not groundbreaking, but it doesn’t happen every day.
The key difference between the birth of the predecessor organizations that would merge into The Linux Foundation and that of the nascent Rust Foundation is context. In essence, Big Tech is comfortable with open source now.
Today, dozens of open-source projects, such as FreeBSD and Chromium, enjoy the Linux treatment, running on donations from tech companies valued in the billions; and when companies want a closer relationship than patronage, they’re fine with buying up open-source companies, as IBM did Red Hat a few years ago.
Big Tech companies not only fund open source, but actually develop open source. It’s common to see pages at the “opensource” subdomain of major tech company websites. Microsoft, Google, and Facebook, among many others, all have such pages.
Follow a few links and you can get from any of them to actual source code released by otherwise proprietary developers. In some cases, proprietary tech companies have gone as far as handing off their software completely. When Google announced in January that it was abandoning its Tilt Brush augmented reality creator software, it simultaneously handed it to the open-source community to keep alive.
Against this backdrop, you’d be hard-pressed to argue that the atmosphere between for-profit tech companies and open source is anything other than convivial.
We Need to Have the Relationship Talk
For open-source software users, robust independent cashflows enable one to enjoy a project’s work even if one can’t kick in money to fund it. But that’s not why corporations write checks. To avoid assuming that the reason is obvious, let’s take a minute to grasp the incentive dynamics at work, taking the Linux kernel as an example.
Google’s choice of the Linux kernel when designing Android and Chrome OS was pragmatic. By then, Linux was already able to run on a wide range of hardware. Moreover, it had proven to be a viable frame on which to build profitable products for other companies.
But Linux gave Google more than a solid base. It also yielded significant cost savings. Google could have amassed the talent to write a kernel in-house, but why do that when it could let the Linux devs write a kernel and contribute cash and code to it as needed?
Under this latter model, Google has all the benefits of a battle-tested kernel, but with Google devs freed up to add to preexisting work instead of banging out a kernel from scratch. The annual donation it sends to Linux probably funds more total developers (between the Linux project and its own kernel customization team) than if it spent the same amount completely internally.
Google is just one of many companies who recoup on investing in Linux. A similar cost-benefit calculus is likely at play in Microsoft et al. establishing and underwriting the Rust Foundation. Although Microsoft primarily writes its products in C and derivatives, the company is seriously experimenting with Rust. Cofounder Google is putting money toward writing components of the Apache Web server in Rust as well.
So just as Google did with Linux, these companies are literally betting on the future of Rust. The dollars of Google, Microsoft, and their cofounders will go further backing a project that checks in code from themselves, the Rust developers, and Rust community pull requests than if spent solely within their respective headquarters.
Where Do We Go Now?
The real question is: what does reinforcing this trend of for-profit investment in open-source nonprofits portend for open-source generally? Making predictions isn’t my strong suit, but I’ve had practice at gaming out consequences.
First, now that it’s no secret that investing in open-source yields an n-fold return, companies may start jockeying to prevent each other from assuming too much control over a project. If company X invests in project A, company Y may not want to let X be the only big-dollar contributor, and in turn may increase its own contributions. It’s the same reason why your little sister bought the last property you needed to start building houses in Monopoly.
We may also see tech players compete to get more pull requests accepted by a project than their co-contributors. Returning to our example, if X has one view of how A should develop, and Y has another incongruent one, the company that advances its vision within the project would wield a considerable edge over the other. In the case of profound architectural considerations, committing the project to your preferred mode over your competitor’s could force them to restructure or even abandon their internal projects.
Finally, there are the subtle shifts in open-source development priorities that will unconsciously result from where the concentration of funding in aggregate settles.
Because corporate funding is now a dependable means of keeping an open-source project afloat, projects may more commonly bend their development decisions toward what will make theirs most attractive to private-sector actors.
These are just the possible paths forward I perceive from where we currently sit. If my read on these dynamics does indeed play out, it will be interesting to see if the open-source community embraces them, or if they’re viewed as a threat to the spirit and ethos of open-source. In this sense, the future of open-source will be up to the open-source community to decide — as it should be.
What do you think about Big Tech’s role in open-source projects and the formation of the Rust Foundation? Please use the Reader Comments feature below to provide your input!
Loading ...
