Rants About Open Source

I am an extensive Linux user, and am a huge fan of open-source projects, software or otherwise.  There is plenty of proof of the potential in communal contributions, and even when there may only be a small group of developers involved, open-source software can benefit many beyond the intended scope (such as compiling for another architecture, or updating to better comply with dependencies/dependents).  However, the openness and freedom of sources is very political, and some people push the open-source agenda to the point where it becomes annoying or destructive without even realizing it.  Please note – I am aware of all the benefits of open-sourcing something, but there are downsides, too.


The most long-term complaint of mine has to do with people who insist a closed-source project/product be converted to open, regardless of the consequences of doing so.  If the product isn’t fully-open, they will boycott the product (even if it is free to use).  Usually, this motive seems to be entirely out of principle.  Companies and individuals close their work for a few reasons that open-source advocates seem to intentionally ignore, such as:

  • Protecting their IP and Patents – If you’re a company and you paid a team of people to develop something that you intend to generate revenue from, open-sourcing that product gives anybody the ability to take what they please from it and redistribute it.  That includes competitors.  Even if the license prohibits this, nothing is stopping people from doing it.  The company therefore will not return a profit.
  • Continuity and Standardization – When a product is open-sourced, people can modify it to their needs.  Part of a company’s obligation is customer service.  If someone modifies the product, the company cannot guarantee the level of functionality, nor can they accurately assist their customer(s).  Very often, most end-users would have no idea if the source was modified.  By closing the source code, it forces users to have the same experience.
  • Encouraged Negligence – If a company open-sources a product, they are now permitting the community to update and maintain it.  To some, this means the company no longer has to try as hard to maintain the product, and they no longer have to offer dedicated support.  Such a situation begs the question: what are you paying the company for?  Sometimes this works out (for example, CUPS is maintained by a community and companies like HP and Apple) but it isn’t a reliable strategy.
  • Hidden Agendas – This isn’t exactly something I’m advocating for, but, many companies like to keep things secret in order to prevent people from knowing anything suspicious or questionable.

The fact of the matter is, most hardcore advocates would be helpless if it weren’t for closed-source efforts.  For example, GPU drivers.  Without the manufacturer, Linux would be almost unusable as a modern desktop OS.  Even the open-source drivers are almost entirely developed by the manufacturer.  I understand that in many cases, the closed-source drivers are very outdated and aren’t very compliant with other software (such as the Linux kernel).  But, opening the source code wouldn’t likely change that situation.  The spaghetti code would be too difficult for a volunteer to handle.  If you look at any open-source GPU drivers not supported by their parent company, they [relatively] aren’t holding up too well.


Interestingly, there are a couple issues that neither open nor closed source projects can accommodate.  One of which is security.  If source code is available, this allows anybody to check the code for security flaws.  That’s great if you want many eyes to quickly eliminate a problem, but it allows for extra attentive hackers to see problems before anyone else, too.  Meanwhile if the source was closed, the time and effort attempting to find a flaw might not be worth it, and the flaw would be left undetected.  However, in the event a hacker discovers a vulnerability in a closed-source application, there may be far fewer eyes to help resolve the issue.  A good example of this was the “eject” command in Linux.  Most hackers wouldn’t waste their time de-compiling something so inconspicuous, but because it was open-source, someone had managed to find a vulnerability (thankfully, before any hackers did).

The other issue that neither open nor closed source projects can fix is competition.  If something is closed-source, a company can monopolize off of whatever that thing may be and stifle innovation.  Even if the product is free, anyone who depends on it may be held back if the creator is inattentive.  On the other hand, many open-source projects receive a complete lack of corporate support, because of fragmentation.  One of the great things about open-source is having the freedom to tweak something to your liking, but when you and dozens (maybe even hundreds) of publicly redistributed forks/variants, it becomes a serious deterrent to anyone who wants to consider getting involved.  Linux distributions are a solid example of this.  Though there are hundreds of actively maintained distributions, they use varying repositories, have different definitions of stability, and don’t package things the same way.  All this fragmentation makes it nearly impossible for companies to release something and realistically support it.  It even becomes a burden to other open-source developers (for example, if someone wants to support GTK or Qt).


Finally, open-source projects can become a real challenge when priorities and features aren’t going the way that is best suited for the community.  If the project is developed by a parent company, the company dictates what the developers do.  Sure, the devs could address the community’s desires on their own time, but why do that when someone else is paying them for a different objective?  Most of the time, these devs are focusing on what other companies what from them, in order to gain more sales.  If the project is developed by a small group of volunteers (as most are), they’re doing it because they feel like it; you can’t really tell them what to do or what not to do.  Their contribution is still better than nothing, so you don’t want to discourage them either.

There’s a way I like looking at this situation:  Let’s say you own a soup kitchen that gives free soup to the poor.  However, you have a bad tendency to over-salt your soup.  As a result, people stop coming to your kitchen.  This is a completely avoidable problem that is only adding expense to the product.  The soup may be made to your taste, but your taste doesn’t apply to everyone.  You’re not contributing to the soup kitchen for yourself, but for the community.  If you don’t care what the community wants, why create a soup kitchen?  Nothing is stopping you from making the soup for yourself.  You may argue “why couldn’t people just add water to their own bowls?” but there are two problems with that: First, you can’t expect the homeless to be able to supply their own water, and second, it is a waste of resources for everyone to be doing their own thing individually.  Give people their own salt, so they can add to their own taste, and everyone wins.

See other Misc

Your Feedback