When to open-source as an engineering organization

Engineers love open source for different reasons:

Things that engineers forget that open source also is:

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 by engineers, risk-managed and decided by engineers, and it happens in the org consistently, we win.

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 if there are no other unproductive factors at play.

  1. Side-note and a personal opinion: being in a team that runs an open-source project has been a somewhat stronger indicator of teamwork and performance than being sole maintainer. (up)

  2. 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)

  3. 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)