Open Source Software

The Downsides of Open Source Software

CyanogenMod is dead, killed by parent company Cyanogen. The community is attempting to pick up the pieces and create a new project, LineageOS, based on the code. But it’s a reminder that open source software isn’t all sunshine, rainbows, and stability: in fact, it can often be very messy.

Even if a project is open source, it isn’t necessarily even responsive to the community, much less a reliable piece of software you can depend on. Projects vary: Some are run by one or two developers as a hobby, others bring together developers paid by many massive corporations, while others are driven by a single parent company. Each situation has its own problems and drama.

We love open source software—don’t get us wrong—but it presents a certain number of challenges. Let’s take a look at a few.

Open Source Often Suffers Delays and a Glacial Development Pace

Many open source projects seem to suffer from a slow development pace, where new versions are endlessly delayed, new features come slowly if ever, and it’s difficult to prioritize difficult-but-important features.

Just look at Ubuntu’s attempts to launch its Unity 8 desktop and Mir display server, enabling its vision of “convergence”. This new version of the Linux desktop was supposed to be stable many years ago, and still isn’t. The project has moved at a glacial pace, so much so that Canonical was beaten to the punch by Microsoft, which announced its own vision PC-powered-by-smartphone before Windows 10—and delivered on it. Canonical still hasn’t delivered its long-promised vision yet. Maybe it’ll be stable in a few more years.

Mozilla has also had some difficulty prioritizing. They still hasn’t delivered multi-process and sandboxing features in Firefox. These are critical to keep the browser secure, prevent crashes from taking down the whole browser, and better utilize multi-process CPUs. All other major browsers have delivered these features, including the hated Internet Explorer. Mozilla crated the “Electrolysis” project to add these features, but halted it in 2011 because it was too difficult. Mozilla then had to restart it in 2013. This feature looks set to arrive in 2017—which is really, really late. In the meantime, Mozilla wasted time working on Firefox OS, a failed smartphone operating system.

When a project uses so many volunteer developers, it may have difficulty finding the people to do the hard work that isn’t fun to do.

Internal Drama Begets Forks, Forks, and More Forks

An open source project’s source code is available for anyone to change. That’s the point! If an open-source project changes in a way you don’t like, then you—or the community—can take that old source code and continue working on it as a new project. But community projects are often so wrapped up in internal drama that they cause things to split apart into multiple projects, confusing and alienating users.

For example, when GNOME 3 launched and many GNOME 2 users weren’t happy, there wasn’t an immediate obvious path. Developers had to fork the GNOME code into other projects like MATE and Cinnamon. One desktop environment turned into three, and development resources are more scattered between projects. As a result, it took some time for the community to get these new projects going.

Similarly, the OpenOffice community was not happy when Oracle acquired Sun. Oracle even briefly renamed its proprietary, not-open-source office suite StarOffice to “Oracle Open Office”. The community had to create a new fork, LibreOffice, based on the OpenOffice code. It has become the de facto open source office suite for many people, but others still use OpenOffice because they aren’t aware of the better fork and the drama surrounding it. OpenOffice just has a lot of built up name recognition.

And, of course, there’s CyanogenMod. Cyanogen Inc just pulled the plug on CyanogenMod’s online services—meaning they would rather kill the most popular third-party Android ROM than hand it over to the community, instead forcing the community to create a new fork of CyanogenMod named LineageOS. Why doesn’t Cyanogen just hand over the CyanogenMod project to the community? The answer seems to be internal drama (are you seeing a pattern here?). Cyanogen was the company whose CEO promised they would “put a bullet through Google’s head”, after all. It ended up putting a bullet through CyanogenMod’s head, instead.

This all just ends up hurting CyanogenMod’s users, who received very little notice before CyanogenMod’s servers and services will be shut down. Phones will continue working, but convenient updates and other services are going up in smoke almost overnight. Users just have to hope the LineageOS project will quickly become a replacement.

Not All Open-Source Projects Are Community-Driven

Open source projects aren’t always driven by the community. Saying a program is open source just means that the code is available to do what you like with. The company developing the software doesn’t necessarily have to run it as a community project, or they may have an interest in using the project to promote their other software.

CyanogenMod is a good example of this. Once Cyanogen Inc. came about, they didn’t really care about CyanogenMod. Cyanogen’s new goal became marketing the Cyanogen Modular OS platform to manufacturers, trading on CyanogenMod’s great name recognition after killing the project. Perhaps that’s just where the money is.

Oracle never cared about OpenOffice, but initially wanted to use its name to drive sales of its StarOffice proprietary office suite by branding it with the “Open Office” name. It then donated the project to Apache after most of the volunteer developers left.

Google doesn’t really care about Android as a full open-source project, either, which is why more and more parts of the “Android Open Source Project” (or “AOSP”) are being left behind. Google wants to keep Android open so it’s easy for manufacturers to customize, but open source applications like the keyboard and dialer are becoming more and more outdated. On a consumer Android device, Google just bundles its own closed source keyboard, dialer, and other apps. Google seems committed to an Android open-source core, but not an entire open-source operating system people can use without Google’s software and services. After all, improving the Android Open Source Project just helps Amazon’s Fire OS, a competitor to Google’s Android devices. What’s the point of that?

Open Source Can Lack Serious Manpower, Despite Being Used by Millions



If a project is open source, anyone can use it without contributing—even massive companies. This leads to problems when an important, widely-used project has a severe lack of manpower and funds.

We saw the results of this with the Heartbleed security hole back in 2014. Heartbleed exploited a vulnerability in OpenSSL. OpenSSL is an important encryption library used by many giant tech companies and hundreds of thousands of web servers. But it had just one full-time employee without outside employment and $2000 a year in donations. The project did take in additional money from commercial support contracts and consulting, but just a single full-time employee seems shockingly low for a critical piece of infrastructure used by multi-billion dollar corporations like Google and Facebook.

Heartbleed drew attention to just how underfunded this critical piece of software was, so big tech companies committed to chipping in money every year to fund the development of OpenSSL and other important projects as part of the “Core Infrastructure Initiative“.

There’s a good outcome to this particular story, sure—but only because so much attention was drawn to it. When you rely on an open source project to enable your infrastructure, it’s easy to end up depending on it and assume someone else is maintaining it well enough. What other important open-source project is critically underfunded? We may not notice until there’s another big problem.