Releasing and maintaining an open-source project at a corporation takes a lot of work. I saw this firsthand working for four-plus years on React, a popular open-source JavaScript library developed by Facebook. I started as an external contributor and eventually joined the React team at Facebook, first as an engineer and then as the team’s manager. Like most of Facebook’s open-source projects, React was developed for internal use, then later shared with the world after we saw how much it simplified the development and maintenance of UI code.
React has proved incredibly successful for Facebook, but its success presented unique challenges. For instance, React (though popular) exists in a competitive enough space that we needed to be careful how we planned new versions of the library. The argument for fewer breaking changes is clear: If we changed too quickly, people wouldn’t have time (or wouldn’t want) to upgrade and might switch to an alternative out of frustration. But consider the reverse: If we allowed React to stand still, it would fall behind new, more innovative alternatives. People would leave React for them, just as people left React’s predecessors for React itself.
We also had so many users that there was some objection to any decision we made. (When you’re small, you can please everyone; when you’re large, you really can’t—a phenomenon not at all specific to OSS.) That meant, when planning changes, we also needed to plan our communications strategies very deliberately. We very intentionally avoided posting anything publicly about React Hooks before they were officially announced at React Conf in October 2018: We worried that, with an incomplete picture of our ideas, users would be less likely to understand them. Instead, we waited until we had a complete and cohesive story to tell. The more popular a project becomes, the harder it is to experiment with new ideas without thrashing people.
When React was new and small, most people using it had personally chosen to do so. Now, it’s almost an industry standard. Many people use it without having selected it—whether because someone on their team picked it or because their class is teaching it—and often without understanding its particular strengths. As a result, more people show up with a critical eye and an expectation for polish. React also has so many users and so many people writing about it that it can be hard for new (or even experienced) users to know which resources to trust for advice. Virtually all of the materials are well-intentioned, but that doesn’t mean they’re all high quality.
Many companies hope that releasing an open-source project will pay dividends in the form of code contributions from people outside the organization—but I’ve never seen that work in practice. Responding to issues, answering usage questions, carefully planning release schedules: It all takes time. Even code contributions, despite their reputation as the big reward that’s supposed to make corporate open source worthwhile, are rarely the panacea they’re made out to be. Because new contributors have neither as much context on the existing code nor as clear an understanding of the project’s larger vision as the core team has, their contributions almost always need revisions before they can be accepted. Even the better pull requests often need several rounds of review, and as a reviewer you can’t be sure when (or whether) to expect each update. It’s usually faster to write the code yourself.
Additionally, the vast majority of the pull requests are drive-by contributions: Someone’s working on a project and hits a bug or limitation in an open-source tool they’re using, so they submit a small patch that covers the specific case they’ve encountered. Often, you’ll never see that contributor again. The few who keep coming back to help are a gift. They’ll get to know you, they’ll learn the nuances of your project, and they’ll become personally invested in its reliability and long-term success. With React, our approach was to always treat new contributors well in hopes that they’d return, but they rarely had the energy or desire, no matter how welcoming we were. It’s understandable—everyone has existing commitments, and making meaningful contributions takes a lot of time.
These are problems faced by successful projects. Open-source projects also regularly fail: They may solve for a narrow or uncommon use case, or for a problem for which there are already good solutions. Creators may fail to explain why their project is useful or to provide sufficient documentation, especially for teaching new users how to use it. A project may require a complicated setup or pre-existing infrastructure. It may also be written in an unpopular programming language (or be otherwise incompatible for technical reasons). Even if a project looks promising at first, people will abandon it if it’s full of bugs or doesn’t have good answers to common questions. A project may also lose its users’ trust over time by making major breaking changes or other hurtful project decisions. Projects that ignore the OSS community suffer: Inattention can surface either on smaller topics, such as issue management, or on larger ones, such as a project’s future direction.
Though success brings high maintenance costs and failure is always possible, open source—if done properly—can be incredibly valuable.
Before you start
Documentation and code quality
Some benefits show up before you even announce the release. Preparing to open-source a project is a good forcing function to draw clear API boundaries and clean up code so that your project is actually usable outside of your existing environment and company—facilitating maintenance and making later refactoring easier. Open-sourcing is also a good chance to write proper documentation on how your software works, a valuable resource for new hires even if no one outside your company ever uses your project. And if your project gets popular, other people will write guides for your software, too. You may even reach the point, like we did with React, where any usage question imaginable will have already been asked and answered.
As you scale
Most of the other benefits scale with your project’s popularity. The most successful open-source projects tend to be versatile pieces of infrastructure, core building blocks that can be used in many ways. The less specific to your business a project is, the more valuable other people will tend to find it (and the less you’ll need to worry about giving away your company’s secret sauce).
Engineering brand
Open source can improve the brand of your engineering department. This is true whether you’re a startup no one knows or a gigantic tech company. When Facebook released React in 2013, many people responded, “Why should I listen to Facebook for engineering advice? They don’t know what they’re doing.” Now, because of React and other open-source projects, Facebook is widely known as a leader in the frontend engineering space. This is a major boon for recruiting and hiring: During my tenure, many dozens of candidate engineers I interviewed said they wanted to join Facebook because it’s where React is from. No matter the size of your company, releasing high-quality projects helps showcase the talent of your teams and attract new people.
Improving reliability
When other people use your software, they’ll run into bugs and find edge cases you haven’t encountered. In many cases, these are bugs that you’d encounter later—but with more people using your project in a variety of ways, you’ll have the chance to find and fix them sooner. (Free QA!) Even with over a thousand developers at Facebook using alpha builds of React and finding the vast majority of bugs prior to release, we’d still learn about new issues from external bug reports.
Investing in employees
Often, individual employees who want to give back to the broader programming community are among the biggest internal champions of releasing open source. It’s a chance to be philanthropic at their day jobs and to build a personal brand around their work. Open source can also make their jobs more fulfilling: It can be easier to care deeply about a project if it doesn’t just benefit one company.
Plus, if your project becomes widely adopted, knowledge of it becomes more useful. Employees using the open-source project at your company will gain transferable skills instead of just learning the quirks of a proprietary system. And if you hire people who have used the open-source project, they’ll onboard that much quicker. Proprietary infrastructure can become a liability if it diverges significantly from the rest of the industry, which open source can help you avoid. Authors of related projects may also design them to be compatible with yours, which leads to less integration work if you ever want to use them.
Cultivating contributions
The React team found that encouraging volunteers to help with issue triage was valuable, whether those contributions were one-off or more consistent. By verifying bug reports and reducing repro cases, contributors were able to learn more about the project while saving us time. We started adding a “good first issue” tag to some simpler bugs and writing clear descriptions of how to approach the problem, which led to fewer rounds of code review needed. To our surprise, we found that many of the best tasks for external contributors were tasks we didn’t want to do ourselves, like small pieces of grunt work or mundane changes to build tooling. Often, these tasks didn’t come with time pressure, required little existing context, and helped contributors build familiarity with the project.
Technological honesty
Finally, one of the most important benefits: Releasing pieces of your infrastructure as independent projects helps create technological honesty in your stack. When your company is built on proprietary tech, you risk believing that your infrastructure is working in your favor in cases where you’d actually be better off using off-the-shelf alternatives. Having your project compete on its own merits outside of your company will help you see the truth. (Amazon is perhaps the best-known example of this strategy at a large scale.) If you can make parts of your infrastructure successful on their own, it’s a sign that you’re on the right track.
Is it worth it?
If your company has built software that’s highly specific to your business, it’s less likely that open-sourcing it will pay off. In fact, if potential users don’t find the project valuable, then it’s pretty useless. But if you’ve developed tools that could be broadly useful, then open source is worth serious consideration—even if you screw up some of the other things. It also helps to be clear about maintenance expectations. If you can commit to long-term maintenance, your users will appreciate it. Otherwise, a one-time code drop can still be helpful—but when that’s the plan, tell people up front!
With open source, you get out what you put in. It can help move the industry forward, benefit your company, and inspire current and future employees—though not without time and effort. If the conditions are right, it’s worth the work.