Choose Open Source

Published on March 10, 2021

Why adopt open-source tools?

On a long enough timescale, open-source always wins.

Even with 100,000 engineers, no single company can compete in the long-term with a worldwide community of millions of software engineers operating around the clock.

All companies eventually perish. Corporations are constantly reevaluating and adjusting their priorities to meet business needs. As such, it is always unwise to tie one's fortune up to another's success. Ask anyone who adopted ColdFusion.

With open-source, when the original authors perish with open-source, the community will inevitably breathe life back into the project.

Why should we open-source our software?

In 2021, the only places where a closed-source strategy is still particularly effective are applications designed to have a short shelf-life (1-5 years) and gaming. In some industries, such as developer tooling, a closed-source strategy is especially detrimental, as you are hurting the demographic that would otherwise contribute to your success.

In the short-term, salary is often a more effective means of rallying people around a single goal. If you intend on your software being relevant for longer than this period, it should probably be open-source. This effective time horizon of closed-source software decreases yearly as open-source tooling gets better and community adoption grows.

Paid participation is especially critical when the project requires experts from people outside of the software engineering community, such as artists and musicians. The combination of artistic contributions and short time-scale is why popular open-source games are rare.

Arguments against open-sourcing

1. There is no benefit

Arguable, but it is also unlikely you will suffer because of it either. In the unlikely scenario where you receive no significant external contributions, your project will improve significantly:

In the same way that scientific advances from space exploration bubble down into the lives of everyone on the planet, the additional focus on documentation, testing, and code quality bubbles down into an improved product and better engineers.

2. Accepting patches incurs too much overhead

You are already accepting patches internally. It is no more difficult to code review external contributions than code from members on your team, yet you do so as it builds a better product.

3. The code quality of contributions is too low

In my experience, it's no worse than accepting patches from a new member of your team. The best defense against this is automated testing to enforce code quality and documenting standards: These are also things that you should be doing for closed-source software projects.

4. Open-sourcing will undermine our security model

No more than a debugger will. If open-source worries you from a security perspective, it may be a sign that your security model is flawed.

5. Open-sourcing gives away our competitive advantage

Sometimes, but not as often as you might think.

Your competitive advantage is your people and your ability to execute. Consider whether it makes sense to open-source your platform but limit the availability of certain features or datasets to paying customers.

What else in it for me?

We've spoken a lot about why open-source is good for community and longevity

https://www.youtube.com/watch?v=ZtYJoatnHb8