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.

React has proved incredibly successful for Facebook, but its success presented unique challenges.

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.