How Open Source Projects Collaborate
A Rising Tide Lifts All Boats
In a previous article, I explained why there are so many open source projects solving the same problem. But there’s more to this open source story. Open source projects often collaborate, even when they seem to be competitors. Why is this?
They Can’t Avoid It
Sometimes it can’t be helped. If projects share dependencies or use the same tooling, any improvements they make will benefit all users — even their “competitors.” KDE and GNOME are two open source projects that make competing desktop environments. But they both use GitLab for managing their source code. When a GNOME developer fixes a GitLab bug, KDE benefits. When a KDE developer fixes a GitLab bug, GNOME benefits.
The relationships go even deeper than tooling and dependencies. Competing projects can learn from each other’s code. The shared learning includes more than just “hmm, let me look at the other project to see how they implemented this feature that I can’t figure out.” Though it does include that! Projects can learn from each other’s bugs, too.
Let’s say you developed your own SSL implementation (you almost certainly shouldn’t). When a major bug is reported against openSSL, you can look to see if your implementation is affected too. Because your implementation isn’t widely used, it doesn’t get the same level of scrutiny as larger projects. But you can still benefit from the scrutiny placed on other projects.
All of this makes it sound like open source projects don’t want to cooperate, they just can’t avoid it. That’s not the case at all.
They Want To
Most projects actively encourage collaboration. It’s foundational to the open source ethos.
A natural place for projects to collaborate is on the basics they have in common. As with the “they couldn’t avoid it” scenario, these collaborations are on infrastructure and upstreams. But it’s more than just “oh, fancy seeing you here!” Projects can — and do — make intentional efforts to work together on things that will benefit them both.
Open source projects also directly contribute to each other. Typically, a person is employed by one company at a time. But open source projects aren’t companies. People contribute to multiple projects, even seemingly competitive projects at the same time. If you run multiple Linux distributions, you’re probably going to contribute to both. People will contribute translations to multiple projects — even ones they don’t use — because that’s how they can make it more accessible to people who speak their native language.
If you’re not used to working in open source projects, the idea of helping your competitors might be hard to accept. But when we work together, we all do better.
Be sure to check out Ben Cotton’s book from The Pragmatic Bookshelf:
