It was just before midnight on New Years Eve, 2011, when Stephen Henson broke the internet.
The 43-year old British software developer had accepted a small change to the code for OpenSSL, an open source encryption protocol that secures a substantial portion of the web. The fact that it was open source meant that anyone could see its code online and volunteer to help write code for the project. But just because anyone could contribute didn’t mean many people did.
Videos by VICE
Henson had spent more than a decade working on OpenSSL with a small team that never consisted of more than three or four other core developers. By late 2011, he and the other core OpenSSL developers were responsible for maintaining a codebase that consisted of nearly a half million lines of code, the vast majority of which was either written or approved by Henson himself. This was no small responsibility, either. OpenSSL was used to secure the web servers used by two-thirds of all active websites on the net, as well as email servers, chat servers, VPNs and the network infrastructure of military, government, and financial institutions.
The code change that Henson approved on that fateful night in December had been submitted by a German developer named Robin Seggelmann who helped write the “heartbeat” standard in OpenSSL. Henson and Seggelmann had been workshoping the code for weeks before it was approved, but nevertheless failed to catch a bug that would allow an attacker to intercept information that was passed to any site secured by OpenSSL.
Seggelmann would later admit that the bug in the code, now known as Heartbleed, was “quite trivial,” even though it will go down in history as one of the most dangerous software vulnerabilities ever discovered. For someone as experienced as Henson, it should have been easy to spot and fix—but everyone makes mistakes. In fact, Heartbleed lived in the OpenSSL code for nearly two and a half years before a coder at Google spotted it in 2014 and the vulnerability was fixed. Still, the bug continues to live on hundreds of thousands of devices, many of which are unlikely to ever get patched.
OpenSSL is just one of thousands of open source software programs that millions of people rely on everyday for tasks that range from browsing the web or watching videos to real time translation or using voice recognition on their smartphone. Each of these projects is open source, which means its code is freely available for anyone to look at or use as they see fit.
Since its inception, one of the biggest selling points of open source development was what the software developer Eric Raymond called “Linus’s Law,” or the idea that with enough people looking at some code “all bugs become shallow.” Thus, after the Heartbleed bug was patched, the biggest questions on everyone’s mind was how such a critical vulnerability could go unnoticed for so long and whether similar bugs lurked in the code for other open source projects.
As Steve Marquess, the former CEO of the OpenSSL Foundation noted in a blog post after the fact, the cause of Heartbleed was attributable to developer burnout and lack of funding. According to Marquess, the foundation was operating on a budget of less than $2,000 in donations and under a million dollars in contract revenue annually. The foundation couldn’t take on more contracts because its developers, many of whom had full time jobs and families, simply didn’t have the time.
In fact, Marquess wrote, Henson was the only OpenSSL developer working on the project full time—and for a fraction of what he could have made taking his considerable technical skills elsewhere. “These guys don’t work on OpenSSL for money,” Marquess wrote. “They don’t do it for fame. They do it out of pride in craftsmanship and the responsibility for something they believe in…knowing that [they] will be ignored and unappreciated until something goes wrong.”
Clearly, something was broken with a system where the security of the global internet was almost entirely supported by the selfless efforts of one overworked and underpaid programmer. As for who was to blame, Marquess pointed to the “commercial companies and governments who use OpenSSL extensively and take it for granted.”
“I’m looking at you, Fortune 1000 companies,” Marquess wrote. “The ones who include OpenSSL in your products that you sell for profit. The ones who nag us for free consulting services when you can’t figure out how to use it. The ones who have never lifted a finger to contribute to the open source community that gave you this gift.”
Marquess and Henson both left OpenSSL in 2017, but not before securing the immediate future of the project. In their absence, the OpenSSL core development team has grown to seven people and the project is funded through at least 2021. This is mainly due to a substantial grant from the Linux Foundation Core Infrastructure Initiative, a project dedicated to distributing resources to open source projects that are critical to the security of the internet. The Core Infrastructure Initiative itself is funded through donations from major tech companies such as Amazon, Google, IBM, Microsoft, Facebook, and Intel. This grant means OpenSSL is safe—so long as these companies keep donating.
“I’m looking at you, Fortune 1000 companies, the ones who have never lifted a finger to contribute to the open source community that gave you this gift.”
On the surface, the open source software community has never been better. Companies and governments are adopting open source software at rates that would’ve been unfathomable 20 years ago, and a whole new generation of programmers are cutting their teeth on developing software in plain sight and making it freely available for anyone to use. Go a little deeper, however, and the cracks start to show.
The ascendancy of open source has placed a mounting burden on the maintainers of popular software, who now handle more bug reports, feature requests, code reviews, and code commits than ever before. At the same time, open source developers must also deal with an influx of corporate users who are unfamiliar with community norms when it comes to producing and consuming open source software. This leads to developer burnout and a growing feeling of resentment toward the companies that rely on free labor to produce software that is folded into products and sold back to consumers for huge profits.
From this perspective, Heartbleed wasn’t an isolated example of developer burnout and lack of funding, but an outgrowth of a systemic disease that had been festering in the open source software community for years. Identifying the symptoms and causes of this disease was the easy part; finding a cure is more difficult.
Like Marquess, many developers see open source’s growing pains as a mostly financial problem that could be fixed if giant tech companies would contribute more resources to the open source software projects they depended on. This would, in theory, allow developers to dedicate more time to focusing on open source projects and incentivize other programmers to contribute to projects.
It’s not enough to just throw more money at the open source community, however. Increased funding creates its own problems in terms of how that money is distributed and what the organizations supplying the funding demand in return. Indeed, there is a risk that an influx of capital could destroy the community-driven foundation that has sustained open source development for nearly half a century.
FREE AS IN BEER: THE ECONOMIC FOUNDATIONS OF OPEN SOURCE SOFTWARE
To understand the current debate about the economics of open source software, it’s necessary to consider it in the context of its historical development, which can be traced back to the MIT Artificial Intelligence laboratory in the early 80s.
This was a time when pioneers of computer science like Marvin Minsky rubbed shoulders with a new generation of hackers such as Richard Stallman and Guy Steele, who would go on to fundamentally change the world of computer programming in their own right. Steele was instrumental in documenting and creating programming languages like Lisp and Scheme, while Stallman laid the foundation for the free software movement, the most significant challenge to the arbiters of technology since Luddism.
In a recent interview with New Left Review, Stallman described how MIT’s AI lab fostered a culture of collaboration and radical openness to the point where the lab’s giant computer wasn’t protected with passwords and the doors to the lab were always unlocked. To be sure, Stallman acknowledged that some of this culture of openness was a product of circumstance: Minsky, for instance, was always losing his door keys and the researchers in the lab couldn’t help but share the room-sized computer because it was the only one. Nevertheless, the spirit of the lab made an impression on Stallman.
In 1983, he posted a message to a Usenet group—basically a proto-forum—in which he declared his intention to create an operating system and “give it away free to everyone who can use it.” Stallman called the operating system GNU, a recursive acronym for “Gnus Not Unix,” a challenge to the dominant proprietary OS of the time—Unix, which was used internally at Bell Labs—embedded in its very name.
GNU was the opening salvo in the free software movement, whose principles Stallman summarized in the 1985 GNU Manifesto: “I consider that the Golden Rule requires that if I like a program I must share it with other people who like it. Software sellers want to divide the users and conquer them, making each user agree not to share with others. I refuse to break solidarity with other users in this way.”
The way that Stallman uses the word “free” when discussing free software is not immediately obvious. As he likes to put it, the “free” in free software means “free as in speech, not as in free beer.” In other words, free software was defined by an ethical imperative to liberate code from restrictions on how it was used, but that didn’t necessarily mean the software must be given away at zero cost. The underlying principles of the free software movement were formally codified in 1989 when Stallman published the GNU General Public License (GPL), now more widely known as copyleft, which set the stage for an explosion in free software development.
Two years later, Linus Torvalds, a Finnish student with a hot temper, used the GPL to release his free operating system kernel, Linux. The kernel was often used in conjunction with GNU software and in the three decades since it was released, GNU/Linux has become one of the most widely used operating systems in the world for web servers and personal computing. Following Linux, dozens of other notable free software programs were released under GPL or a GPL-compliant license, including the Apache web server software and the MySQL database engine, both of which are still widely used today.
In the midst of the orgiastic dotcom bubble, when tech companies that barely existed were able to command obscene valuations, Stallman’s ethically-driven free software movement offered a starkly alternative vision of the future. Unlike the digital castles-in-the-air being churned out in the offices of Silicon Valley venture capitalists, free software worked. Stallman and his acolytes had demonstrated that it was possible to make great software that could be modified to meet the individual needs of users by combining ethical conviction and technical chops. For a brief moment in the mid-90s, it seemed like the future of software was free—as in freedom.
Read More: The Culture War Comes to Linux
Then in 1997, a programmer named Eric Raymond published The Cathedral and the Bazaar, an essay that analyzed the process of developing free software. At the core of Raymond’s seminal text is an idea that he has termed “Linus’s Law,” the idea that if enough people are working on a software program, any bugs hidden in the code will be caught and patched quickly. In essence, Raymond was making the case for the efficiency of free software development. Since it was developed out in the open, anyone could look under the hood of free software programs, which meant that any bugs that might be lurking in the code were more likely to be discovered quickly. A corollary to Linus’s Law was that free software could develop more rapidly since anyone could come up with their own improvements for the software and send them to the core developers on the project.
“The success [of open source] after Netscape would depend on replacing the negative Free Software Foundation stereotypes with positive stereotypes of our own: Pragmatic tales, sweet to managers’ and investors’ ears, of higher reliability and lower cost and better features.”
It’s difficult to overstate the impact that Raymond’s analysis had on the free software movement. After its publication, Netscape, a web browser that was one of the most valuable software properties in the world, made its source code public and cited Raymond’s essay as a “fundamental inspiration” for the decision. Clearly, Raymond’s manifesto had caught the attention of a number of Silicon Valley luminaries who realized the latent business potential in free software.
There was just one problem: The free software movement was burdened with a major ethical component, and ethics are bad for business. So in 1998, at the behest of Raymond and the budding media titan and “meme hustler” Tim O’Reilly, a group of high profile free software evangelists gathered to figure out how to make free software attractive to industry. As Raymond later described the gathering, the developers at the meeting mounted a “marketing campaign” in order to “re-brand the product and build its reputation into one the corporate world would hasten to buy.”
“It seemed clear to us in retrospect that the term ‘free software’ had done our movement tremendous damage over the years,” Raymond wrote in an essay published in Open Sources: Voices from the Open Source Revolution, noting the term’s “strong association with hostility to intellectual property rights” and “communism.” According to Raymond, “the success [of open source] after Netscape would depend on replacing the negative Free Software Foundation stereotypes with positive stereotypes of our own: Pragmatic tales, sweet to managers’ and investors’ ears, of higher reliability and lower cost and better features.”
The stereotype the group settled on is encapsulated in the term “open source,” which eschewed the ethical dimension of free software by focusing entirely on the efficiency of making software’s source code “open.”
In retrospect, the marketing campaign was a phenomenal success. Open source software is now at the heart of the tech platforms and services most of us use every day, including Microsoft, whose former CEO Steve Ballmer once famously described Linux and other open source projects as a “cancer.” These days, Microsoft positions itself as a champion of open source development, as does Google, Facebook, Amazon, IBM, and even the US government. Free software, if it is mentioned at all, is usually brought up under the umbrella term Free and Open Source Software or FOSS.
THE ECONOMICS OF OPEN SOURCE
Although open source software was rapidly embraced by many of the biggest tech companies in Silicon Valley, economists struggled to explain how these projects, which bucked all the conventions of the marketplace, could be so successful. By that point, the standard explanation peddled by the free software crowd—that free software development could be sustained on the basis of the ethical imperatives of freedom and altruism—no longer seemed adequate to account for the rapid emergence and adoption of a project like Linux. To that point, no other industry in history had ever produced such a technically demanding project on that scale by relying solely on the goodwill of its contributors.
This apparent anomaly resulted in a brief flurry of research in the early 2000s that sought to explain how developers “profited” from their voluntary contributions to the FOSS ecosystem. In short, these economists sought to explain open source development such that these programmers still conformed with economists’ conception of the rational producer/consumer: The so-called “homo economicus.” In 2000, Josh Lerner and Jean Tirole, economists at Harvard and MIT, respectively, published what became the defining economic explanation of open source development. Titled “The Simple Economics of Open Source,” Lerner and Tirole identified multiple immediate and long term benefits gained by open source developers such that the role of altruism in open source development was reduced to an accidental byproduct. In short, Lerner and Tirole claimed to demonstrate that the main motivating factor in open source development were the economic benefits that accrued to the developers, not some deep-seated desire to give the world free software.
In terms of immediate benefits, Tirole and Lerner argued, open source programmers are either directly compensated for their work through their employment at a company that develops the software or they make the software more useful to themselves by fixing a bug or adding a feature. As for long term benefits, open source development was used to advance a programmer’s career by demonstrating their talents to a prospective employer or venture capitalist, as well as providing a signalling mechanism whereby developers can gain recognition for their technical chops from their peers in open source.
After publication, Lerner and Tirole’s explanation of the economic incentives of open source development became the new gospel. Today it is the most cited paper on the economics of open source by a large margin.
Lerner and Tirole’s open source community circa 2000 is a system in which everyone wins, but the FOSS ecosystem has drastically changed in the last 20 years, both in terms of the scale of its adoption and the way it is produced. These changes were due in large part to the creation of Git, an open source tool that allows for distributed collaboration on software development, in 2005. Services built around Git, most notably GitHub, have greatly accelerated the pace of open source development and drastically lowered the barrier to entry for new developers. This was a problem foreseen by Lerner and Tirole, who questioned whether “the management of open source projects [can] accommodate the increasing number of contributors” nearly a decade before GitHub.
The rapid rise in the number of open source contributors is often pointed to as a validation of its development paradigm. In the past decade, however, an increasing number of FOSS developers began to speak about burnout from maintaining open source repositories. Many developers pointed to a sense of user entitlement as the main source of this burnout. As the developer William Gross described the issue, the rising tide of companies that depend on open source software means that open source developers are deluged with feature requests and issues with the code and many of these companies expect that their improvements and issues should take priority. In other words, it seemed as though many popular projects in the open source community were poised to become victims of their own success.
In an echo of Lerner and Tirole, many FOSS developers began to wonder whether a software development model that relied on the goodwill of individual volunteers was sustainable at scale. Just defining the problem was tough. Some developers saw it as a cultural problem, one that could be addressed by teaching newcomers the rules of being a good user and teaching maintainers that it was okay to turn down contributions. Others saw it, fundamentally, as an economic problem that could be solved with more funding. Still others denied that there was any systemic problem at all.
THE TRAGEDY OF OPEN SOURCE
In 2015, Nadia Eghbal left her job as a venture capitalist and set out to discover why it was so hard for many open source projects to monetize their work. Eghbal told me she became interested in the economics of open source software after repeatedly hearing about FOSS projects that were widely used, but couldn’t figure out how to fund their development. To Eghbal, there seemed to be a contradiction at play.Many popular open source projects had all the hallmarks of a successful startup: Rapid adoption, a large user base, and low development costs. Yet most of these projects were anathema to venture capital, where investors are only interested in scaling software if it means large returns. The problem, then, was to identify alternative mechanisms that could be used to sustainably fund open source.
To find out solutions, Eghbal went to the source: The maintainers of open source projects. After a year of interviewing hundreds of open source developers, Eghbal published Roads and Bridges, which is arguably most extensive research on the economics of open source software development ever undertaken.
Eghbal’s report frames open source software as a non-excludable public good. This is a technical term in social science that describes a resource that can be used by anyone regardless of whether they have paid for it—like roads and bridges, for example. Non-excludable public goods are a cornerstone of a healthy community, but they’re also subject to what economists call “the free rider problem” and the “tragedy of the commons.”
The free rider problem describes a situation in which a good is either over-consumed or under-produced because there is no way to prevent people who haven’t paid for the good from using it. Open source is, by its very definition, a non-excludable good. For example, a company like Google may spend considerable resources developing an open source tool like TensorFlow, a machine learning platform, but because it is open source, Google can’t stop other companies from using it, too. If enough companies start using TensorFlow without contributing equally to its maintenance, this could lead to the software being under-produced in the sense that the maintainers can’t keep up with the number of feature requests or bug reports submitted by users.
The free-rider problem is related to the tragedy of the commons, which describes a scenario where all the members of a community benefit from unregulated access to a common good, but no one is incentivized to individually bear the cost of maintaining that good. When each member of the community uses the common good according to their own self-interest, the good eventually becomes depleted and available to no one in the community. In the case of FOSS, the common good is the billions of line of open source code. While code itself can’t be used up in the same way as other economic goods like food or land, the resource that can be depleted is the attention and energy of the programmers responsible for developing and maintaining that code.
The tragedy of the commons is a well-studied problem in economics, but Eghbal realized its usual solutions—turning the commons into a private or regulated good—weren’t really applicable when it came to open source software development. Turning the software into a private good would undermine the entire point of open source development: The efficient production of quality software that is available to anyone who needs it.
On the other hand, regulating the production of open source software (for example, establishing an organization similar to the National Science Foundation to distribute publicly-funded grants to open source software projects) undermines the main advantages of open source development. The stability afforded by regulation comes at the cost of efficiency, and in the fast-paced world of software development, this simply wouldn’t fly. Furthermore, regulation would also undermine the spirit of open source development insofar as it could result in gatekeeping that determines who can contribute and who can consume the resource.
“Tech companies make billions off OSS and give almost nothing back. They could solve the problem today and barely dent their bottom lines.”
Some open source maintainers have attempted to regulate how their software can be used in the past, such as by barring companies that work with Immigrations and Customs Enforcement from using the software. This was met with a strong negative reaction from the open source community and the decision was eventually reversed, a testament to the deeply held belief that open source software should be freely available to all. On the other hand, the regulation of access to the open source community has been floated as a possible solution to developer burnout. As the developer William Gross noted in a blog post, this model of “open source, closed community” would essentially charge users a fee if they want access to the community of developers working on a project.
“The message to users should be ‘do whatever you want with the code, but pay us for our time if you want to influence the project’s future,” Gross wrote. “Will this lead to a drastically smaller community and more forks? Absolutely. But if you persevere in building out your vision, and it delivers value to anyone else, they will pay as soon as they have a contribution to make.”
For those maintainers who are unwilling to gatekeep their development community, the next most logical solution seems to be asking open source software users to support its development by hiring developers to work on that project. This approach turns funding open source into an exercise in calculation: Figure out who benefits from an open source project and make sure they contribute back into the ecosystem as much as they take out. Although there’s no central database that keeps track of all the world’s open source contributors, there is something that’s pretty close—it’s called GitHub.
Read More: The Last Independent Mobile Operating System
GitHub launched in 2008 and although it’s not the only place where programmers come to store, review, and discuss open source software it has become the closest thing that the FOSS community has to a town hall. Today, the online software repository hosts over 100 million code repositories created by some 25 million contributors from around the world. The motivations that compelled these 25 million souls to contribute to open source development are manifold, but according to David Hansson, the creator of the open source web development framework Ruby on Rails, over the last two decades there has been a fundamental shift in the profile of open source contributors.
“The vast majority of open source software—particularly as it relates to the web—is funded through companies sponsoring developers to work on issues that matter to those companies,” Hansson told me. “It’s a kind of a different path than Richard Stallman’s free software, which was all about people writing it on their own, but it is an eminent model that has worked exceptionally well and has provided us with this wonderful array of open source software.”
This isn’t to say that the archetypal open source programmer who pushes code in their freetime isn’t well-represented in the FOSS community. Hansson was quick to praise the “passionate hobbyist” who forms the bedrock of the FOSS ecosystem. But a perusal of GitHub’s top contributors for 2017 suggests that Hansson is right: Google, Microsoft, Amazon, IBM, Facebook, TenCent, Baidu, Red Hat, and Intel employees are the most active open source contributors by a large margin. Each of these companies is for-profit and brings in tens of billions of dollars in revenue each year from products that are based on open source code. I reached out to several of these companies to ask them to respond to developer charges that they are not giving enough back to the open source community. The companies that did respond to my query were quick to defend their substantial contributions to open source development.
Todd Moore, the vice president of IBM Open Technology pointed to the fact that the company has been contributing to open source projects since the mid-90s, including their patronage of Linux and Apache when these projects were still finding their feet. According to Moore, there are over 1,200 IBM employees contributing to 1,000 open source projects on both company time and in their freetime. Moore said that “many” IBM employees work on open source projects such as Linux, Kubernetes, Java, and Node.js full-time and that the company offers annual rewards to top IBM developers in various open source communities. (Moore declined to give more information about the nature of the rewards or which developer communities they affect.)
“We have helped to build the open source revolution into what it is today, by helping to found every major open source foundation for the last 10 years,” he said. “IBM encourages its people to work in open source, period.”
Moore told me that IBM also runs an annual certification program “to help IBMers understand both the value and risks relating to open source and to remind them of internal governance processes.” This educational workshop also includes “best practice guidance on being an effective member of a project or community,” and according to Moore over 72,000 IBM employees are certified with the program.
Chris DiBona, director of open source at Google, offered similar sentiments.
“Free and open source software has been part of Google’s technical and organizational foundation since the company’s early beginnings,” DiBona told me. “Larry [Page] and Sergey [Brin] built on Linux and commodity hardware [and] over the years Googlers have released millions of lines of code under open source licences.”
Although DiBona declined to offer an exact number of Google employees that work full time on open source projects, he said that the company has over 2,000 active open source projects on GitHub. In particular, DiBona highlighted work on the programming language Go and the container software Kubernetes as examples of widely used open source projects created at Google that employees work on everyday.
“You’d be hard pressed to find a technical Googler who hasn’t made a contribution to an open source project”
“Googlers are encouraged to work on open source projects that are relevant to their work, fun, or interesting to them,” DiBona said. He pointed to data from 2018 that showed that Google employees accounted for more than 1 percent of all activity on GitHub as evidence of the company and its employees’ commitment to open source development.
“You’d be hard pressed to find a technical Googler who hasn’t made a contribution to an open source project,” DiBona said.
By mandating or encouraging some of their employees to work on open source code, companies like Google and IBM are directly contributing to the open source community. Many of the companies also dole out monetary contributions to non-profit organizations such as the Linux Foundation, Apache Foundation, or Mozilla Foundation, each of which have multimillion dollar endowments.
The question raised by independent developers, however, is not whether major tech companies are contributing to open source. Rather, it is whether these companies are contributing enough, and whether these contributions are going to the right projects.
Jacob Kaplan-Moss, the co-creator of the open source web development framework Django, has argued that these multi-billion dollar companies need to contribute much more to the open source community at large. Kaplan-Moss specifically pointed to GitHub, which was recently acquired by Microsoft for $7.5 billion, and suggested that if GitHub really cared about open source, it would give half the proceeds of that sale to the maintainers and contributors actually creating the software.
Read More: Thousands of Projects Ditched GitHub for GitLab After Microsoft Acquisition
“The root cause of OSS burnout is money,” Kaplan-Moss tweeted. “The only way to solve it is money. Tech companies make billions off OSS and give almost nothing back. They could solve the problem today and barely dent their bottom lines. If companies actually cared about OSS instead of virtue signaling, they’d turn those massive exits into windfalls for open source maintainers and foundations.”
Hansson, although not opposed to more funding for open source projects in general, has taken a more cautious stance when it comes to the “perils of mixing open source and money.”
“If you have a project that has a few hundred contributors and you start introducing specific monetary rewards for slices of work here and there I think you get into very dicey territory very quickly,” Hansson said. “People who haven’t valued their work in an economic sense, who were doing it for the community, for fun, or for the creativity, are all of a sudden forced to think about their investment of time in market terms. I think in many cases that can do a great disservice.”
As an example of this disservice, Hansson cited his own contributions to Ruby on Rails. When he first started Rails, Hansson said he would get inundated with feature requests, bug reports and so on, and that many of those emails expected him to fix all these problems as if he were a software vendor. Yet by eschewing market values, Hansson was able to adopt a “fuck you” mentality, which he said has proved to be the “number one defense mechanism” against the developer burnout that runs rampant in the FOSS community. If he were to accept money for his work, he would be obligated to meet the demands of his customers. Yet because he is freely contributing to a community project, he isn’t beholden to anybody.
“I’m giving my software for free so if you want to help make it better then that’s amazing, let’s work together,” Hansson told me. “But if you want to stand over in the corner and yell at me and say this is shitty, then my answer is fuck you, I don’t work for you.”
Almost no one in the open source community thinks more funding for FOSS is an outright bad idea. Even those like Hansson, who are often painted as the biggest critics of mixing money and open source, advocate for increasing funding under certain circumstances. In short, the difficult question for the open source community isn’t whether more funding is a good idea, but rather how this funding should be distributed.
FREE SOFTWARE ISN’T FREE
Hansson, for his part, sees corporate patronage as the most promising avenue for supporting open source projects. This can take a number of forms. Some companies make monetary donations to the non-profit foundations created to support specific open source projects. IBM, Intel, Google, and Microsoft, for example, are all “platinum donors” to the Linux Foundation, which employs developers to work on the Linux kernel full time. Another way companies support open source projects is by hiring developers to work on that project full time at the company or by allowing employees to spend part of their work day coding for an open source project.
Foisting the burden of supporting open source projects on to major tech companies is not without risks, however. Open source development is, by its nature, decentralized. Yet if a single company becomes responsible for supporting most of the core development work on a single project, this centralization becomes a serious risk since the company can decide to stop funding the work at any time.
Moreover, a company that invests employee talent into an open source project is obviously going to prioritize developing that project in a way that best benefits the company itself. While this isn’t necessarily bad in itself—what’s good for Google is probably good for many other companies that use the software as well—it may come at the cost of diversity in how the software is used.
A good example of this is the development of the Android operating system, which is found on 86 percent of all smartphones sold in the world. Android is open source, but almost all of the development work on the OS is done internally at Google. At the same time, Google is also paying engineers to develop some of the proprietary applications that are generally seen as the biggest selling point of an Android operating system such as Google Maps and Gmail.
So anyone is free to create their own Android operating systems from the open source code, but Google has a policy that forbids using its applications on any non-official Android OS. This policy was justified on the grounds that it would help app developers from having to modify their apps to fit dozens of slightly different versions of Android, but the most noticeable effect is that the open source Android OS has become inextricably bound to proprietary Google products. Companies are free to use a custom version of Android without Google products on their phone if they want, but it’s at their own peril. Amazon was foolhardy enough to try this in 2014 with the Fire phone, which ended up being a $170 million dollar mistake. Although the lack of Google apps wasn’t the only reason the phone failed, it was a major cause of its demise.
Yet even if an open source project wants to accept corporate sponsorship, many lack the organizational structure to do it, according to Deb Nicholson, the director of communications at the Software Freedom Conservancy, a non-profit that provides infrastructural support to open source projects. Indeed, Nicholson said the SFC’s main job since it was founded about a decade ago has been acting as a sort of umbrella organization that can accept money on behalf of the 50 open source projects that are its members. These projects range from small operations that only have a handful of contributors to giant projects like PHP and Git that have fundamentally changed the way we use the internet.
The SFC is one of many non-profits offering institutional support to open source projects. Other organizations, such as the Software in the Public Interest and the Free Software Foundation offer various other services, such as legal advice or the physical infrastructure (servers, office space, etc.) needed to run a successful open source project. In each of these projects, the programmers knew how to write good code, but often didn’t have the time or resources to deal with the hassle of creating a legal entity and establishing a governed organization for their project. The role of these nonprofits is to help projects address these organizational dilemmas that prevent FOSS projects from getting the support they need so that the programmers can focus on what they do best: Making software.
Historically, the role of supporting FOSS projects has fallen on the shoulders of these non-profit organizations, but a new company called Tidelift is betting on a market-based solution to the open source community’s funding woes. Founded by four former employees of Red Hat, a company that sold Linux support services and recently became the third largest acquisition in tech history after it was bought by IBM for $34 billion, Tidelift hopes to increase the funding flowing to open source projects by bolstering their security.
Tidelift CEO Donald Fischer told me that the biggest barriers to the adoption of open source projects, especially in heavily regulated industries like banking, is the lack of assurance that the software will work like it was supposed to. Unlike proprietary software, there’s generally no customer support line for an open source project. If a company is using open source code and then the maintainers stop working on it or don’t immediately address a bug, there’s not much the company can do.
As Hansson pointed out, from a maintainer’s perspective, this ability to selectively engage with users is part of the luxury of not monetizing open source projects. Fischer agrees that if programmers don’t want to monetize their development time providing customer support to users that’s just fine, but for those that do want to monetize their work, there ought to be a space for them to do that. Enter Tidelift.
Read More: Major Open Source Project Revokes Access for Companies That Work With ICE
Tidelift is sort of like what Red Hat did for Linux, but for all the other FOSS projects: Businesses pay for support services related to the open source projects they’re using. As Fischer described it to me, Tidelift is applying the same logic to the FOSS community that AirBnb brought to the hospitality industry and Uber brought to the transportation industry.
Tidelift uses a custom program to track changes across hundreds of open source libraries so it can track how code changes affect companies that have registered with the service. If a code change in one of those libraries result in security, licensing, or maintenance issue, developers that have signed up with Tidelift work on any issues associated with that change. Under this model, companies pay a flat rate to Tidelift, which then takes a cut and distributes the rest to the developers, who are paid according to how many companies are using the code that they are maintaining.
Tidelift’s model is similar to one of the oldest funding mechanisms within open source: Bug bounties. These are basically an agreement to pay a developer who discovers and/or fixes a known bug in some open source code. A number of services have cropped up to fulfil this need ranging from Gitcoin, which pays out bounties on the blockchain, to the European Union, which launched its own bug bounty program for 14 open source projects in December. In 2017, a company called Code Sponsor aimed to monetize open source projects by connecting them with companies who could place advertisements in the readme files of the open source project. Code Source has since changed its business model and reorganized as CodeFund which is leveraging ethical digital advertising to fund open source projects.
Some of the more active developers on popular open source projects have taken fundraising into their own hands by soliciting support through crowdfunding services like Patreon. For well-known developers working on well-known open source projects, this can be quite lucrative. Evan You, the creator of Vue.js, an open source JavaScript framework for creating user interfaces, pulls down over $17,000 a month on his Patreon, for example.
Got a tip? You can contact this reporter at daniel.oberhaus@vice.com
You is, of course, something of an outlier among developers. Other programmers working on open source projects earn much more modest sums through crowdsourcing. Henry Zhu recently left his job to work full time on Babel.js, an open source JavaScript compiler. He relies entirely on crowd sourced support for his income, which is currently around $1,500 a month on Patreon.
In January, GitHub’s open source project manager Devon Zuegel wrote a blog post on the site titled “Let’s talk about open source sustainability.” The post highlighted a number of problems in the open source community, which included inadequate resources and governance, lack of communication, and work overload. Zuegel implored the community to give input to the company on how it could improve these areas for open source maintainers and contributors.
“For us it’s all about giving a lot of support to these developers who are building software, listening to them and building tools that are going to help them in the future,” Kathy Simpson, the senior director of product management at GitHub told me on the phone. “We have an obligation to protect the connective tissue between these projects and communities and help them grow it.”
“Being a maintainer can be a really challenging and thankless job,” Simpson added. “We’re very aware of that and we want to do everything we can to move forward holistically.”
“If you’re going to make an argument that there’s a sustainability crisis, you have to point to diminishing contributions, or fewer projects, or somehow more than just a handful of outlying events.”
Despite GitHub’s ostensibly earnest attempt to help the open source maintainers, the call for suggestions was met with mixed reactions. Some developers welcomed GitHub’s attempt to improve the experience of running an open source project while others took issue with the company’s insinuation that there is a sustainability problem in open source.
“The sustainability argument in particular is grating for someone who has been here for two decades,” Hansson told me. “If you’re going to make an argument that there’s a sustainability crisis, you have to point to diminishing contributions, or fewer projects, or somehow more than just a handful of outlying events. I think there are projects that do fall into this weird space where there isn’t an active core of maintainers who can do it as freelance work and there isn’t an individual company that sees a need to sponsor it directly, but I don’t recognize that as the general story.”
The issue of whether there is a generalized sustainability crisis in open source is a contentious one, but that doesn’t obviate the need to find a solution for open source projects that do struggle to find funding and volunteers to support development. Whether these are marginal examples or a rising epidemic, the fact that they continue to work on open source projects in spite of this shortcoming is a testament to their dedication to the goals of the project and open source development more generally. Yet most developers are in agreement that if there are ways to sustainably fund the open source community, this will ultimately lead to even better software.
As Zhu noted on Hope in Source, a podcast series he hosted with Eghbal last year, the open source community is a lot like a religious community, especially where money is concerned. People give freely to organized religious institutions so that the people who work there can continue to carry on the organization’s work without having to find outside work. These organized religious communities need some money to function at a basic level, but their most important assets aren’t monetary—it’s the people coming together to make the religious community a reality. Even with all the money in the world, one person does not make a religion, nor can they sustain a widely used open source project.
“We want to encourage people to be involved,” Zhu said. “In open source, time is way better than money.”
Still, it is unfair of tech companies and other users to rely on poorly funded and overworked developers to maintain the open source software that powers modern society. While the extent to which this is a problem is an empirical question that deserves to be researched, the fact that it is happening is not. As Eric Raymond pointed out over twenty years ago, one of the best features of open source is that its openness and community-driven development model produces better software by reducing security risks and bolstering efficiency.
The world is only becoming more dependent on open source software for both consumer products and critical internet security infrastructure—and it shouldn’t take a cataclysmic vulnerability like Heartbleed to convince companies and users that sustaining this open infrastructure is something worth paying for.
