When to open-source as an engineering organization

Engineers love open source for different reasons:

Things that engineers forget that open source also is:

There’s a fantastic article, The benefits (and costs) of corporate open source by Sophie Alpert. It describes similar challenges, but from a large company’s perspective. A lot of points are going to be true even for a smaller company, although the argument that open-sourcing something is a huge investment is likely going to be perceived differently by people in a 100+ company than it is in a 1k+ or 10k+ companies, even though the size of the project’s audience is what really matters, not the size of the team behind it.

A team, to determine properly whether they can afford open-sourcing a project, should do a couple things to increase the chance of being lucky:

Ideally, it should really be the team of engineers who own the project and decide, through a robust decision-making, to open-source it. If it’s driven, risk-managed and decided by engineers, and it happens in the org consistently, it’s a win. What likely wouldn’t work is if there’s not a single team behind the project, but rather a group of individuals from many teams (think workgroup or guild model): their direct teams will always remain a top priority, which will gradually reduce their motivation to maintain the open-source project.

In a healthy org, the path is usually clear as long as the team members are honest with each other about the motivation for open-sourcing something and about how things will change once a project that was private becomes public, and whether there are or aren’t any other unproductive factors at play.

  1. People expect a net-positive response from the broader community, otherwise it would be irrational to push for open-sourcing anything. But the response would be just a single event, or it would be a sequence of events of one kind. We also need to think in higher-order ranges: we are going to maintain it over time — what series of events can we anticipate? Which of those are going to be positive or negative? Who is doing what in which case? (up)

  2. An open-source project rarely starts with great documentation — if any whatsoever. It’s okay because the core value is in the code, not in the docs. Nevertheless, decently made documentation is very important for project adoption. Which, of course, requires skills and effort, which the team may not have at that moment. (up)