Why Are There So Many Competing Open Source Projects?
The Reasons, Drawbacks, and Benefits
It has happened to all of us: you go looking for a software package to solve a problem and you find a great open source project. And then another. And another. Why does this happen?
There’s More than One Way to Pet a Cat
Sometimes multiple projects exist to solve the same problem because there are multiple approaches. The approaches can vary on technical merits or stylistic choices. Why have both a socket wrench and a box-end wrench in your toolbox? They’re both tools for turning bolts, but they have different features.
For example, KDE Plasma and LXQt are both Qt-based desktop environments. But Plasma is designed for a more feature-rich experience while LXQt is lightweight. When version 3 of the GNOME desktop came out, some people preferred the version 2 style and so continued developing it as the MATE desktop.
Apache HTTPD and NGINX are the two most widely-used web servers. Why have both? Apache provides more flexible customization, which is important for some use cases. But NGINX’s architecture gives it a lighter resource footprint. The right choice in a particular case depends on what you need.
Think of it this way: most developers know multiple programming languages and pick what they use based on what they need. When I need to parse a lot of text, I use Perl. When I’m stringing together a few commands, it’s a shell script to the rescue. Python’s pandas library is my go-to for analyzing bug data or survey results.
Take This Code and Fork It!
Competing projects can arise when part of the community decides to take the code and go somewhere else. This is called a fork. This type of fork is not to be confused with the fork you make, for example, on GitHub when you’re contributing to a project that you don’t have commit rights to. Although the mechanism is essentially the same, the GitHub fork is typically short-lived. The forks we’re talking about in this section are permanent.
Forks can be friendly. Friendly forks are created for augmenting or experimenting on the original project with the intent of contributing changes back upstream. One example of a friendly fork is the NeoOffice project, which was created to develop an OS X-native version of the popular OpenOffice suite. The software packages provided by a Linux distribution are often friendly forks, as they include patches to fix bugs or build issues not yet fixed upstream.
On the other hand, forks can get messy. LibreOffice forked from OpenOffice after Oracle acquired Sun Microsystems (and thus OpenOffice). The community did not trust Oracle, so they took the code and started a new project under the ownership of a foundation. If a developer is asked to leave a community (or decides to on their own), they might create a hostile fork of the old project.
Not Invented Here
Project founders won’t usually admit to it, but sometimes the reason they start a competing project is because they want it to be theirs. This reason is not particularly compelling, so it’s usually dressed up in the guise of “the existing project lacks this thing I really need.” I won’t shame anyone by naming names here. I’m sure you can find your own examples.
A special class of not invented here projects are the hobby or learning projects that manage to take off and become big. Linus Torvalds famously introduced Linux as a “hobby [that] won’t be big and professional like gnu.” Today, of course, the Linux kernel runs on more devices than any other.
So Is This…Good?
On the one hand, having competing projects leads to a confusing landscape. A new user can’t just install Linux. First they have to figure out which of dozens of distributions to install. And if they pick a large distribution like Ubuntu or Fedora, there are more variants to choose from within those umbrellas.
This fragmentation poses a lot of challenges. Some have argued that a lack of standardization holds back mainstream adoption of the Linux desktop.
But fragmentation also provides opportunities. Competing projects also cooperate, sharing ideas and developers. Because the code is open, we can learn from each other’s successes and failures. Trying different approaches to solving a problem means we can figure out the best approach. Sometimes a clear winner emerges and becomes the de facto standard. And if not, you’re sure to be able to find an open source project that suits your needs and tastes. If you can’t find one, maybe you’ll found one.
Be sure to check out Ben Cotton’s book from The Pragmatic Bookshelf. You can save 35 percent with promo code open_source_2022 now through November 15, 2022. Promo codes are not valid on prior purchases.
