Hartley Brody

The Free and Open Source Software movement (FOSS) is almost as old as the market for software itself.

Back in the 1980s, Richard Stallman started the Free Software Foundation as a reaction to the growing commercialization of software. He framed the issue not as a commercial one, but as a moral one:

Thus, “free software” is a matter of liberty, not price. To understand the concept, you should think of “free” as in “free speech,” not as in “free beer”.
--- Free Software Definition

To this day, many people still think of FOSS as a matter of liberty. Quoting again for the GNU project’s answer to “What is Free Software“:

When users don't control the program, the program controls the users. The developer controls the program, and through it controls the users. This nonfree or “proprietary” program is therefore an instrument of unjust power.

Clearly the FOSS movement is grounded in morals and philosophy.

But for me, I don’t tend to moralize about software too much. Instead, I work with open-source projects and technologies for more practical reasons. I’ve found they tend to be more well-documented, efficient, secure and easily extendable than their close-sourced counterparts.

If you’re starting a project or learning a new language – or just choosing software as an end-user – those are all great reasons why you should consider an open-source option.

The basic tenet of open-source is that anyone can see the underlying source code that makes a program run. This means that anyone can not only read and study it, but also (usually) modify it and redistribute it as they wish.

Thus, open-source software is exposed to everyone’s eyes. And – like a rock eroded by millions of grains of sand over time – this exposure helps polish it off and smooth over many bumps.

Everything is Accessible

With proprietary software, you’re relying solely on the original authors of the application to give you a full and accurate description of what it is and how it works. But even at a well-meaning organization, documentation often gets out of date or is incomplete – or sometimes flat out wrong (real-world example discussed later).

If you encounter strange or inconsistent behavior in a platform like that, your only option is to file a bug or see if anyone else has posted the same issue in a forum somewhere and gotten an answer.

With open-source software however, you can roll up your sleeves and dive in yourself. This empowers you to not only study the software and fix bugs, it also allows you to change existing functionality if it doesn’t suit your needs out-of-the-box.

Documentation is Reliable

As a corollary to the last point, open-source projects usually have excellent documentation. If someone discovers an issue or a feature that isn’t well described in the project’s documentation, they can usually go into the docs and update them to be more accurate.

This is a great example of how increased scrutiny, combined with the ability for anyone to edit the project, makes open-source software much nicer to work with than closed-source projects.

Features are Mature

With open source projects, you rarely have to worry about small bugs and edge cases that the original application developers might not have tested for. Since the source code has been exposed to the public, buggy or insecure behavior is quickly rooted out and corrected.

Even for larger projects that might have several dozen core contributors, those contributors aren’t always specialists in the minutiae of the project. By releasing the source code publicly, people with more experience and specialization have the ability to review the code and even correct issues the original developers might not have noticed.

Anyone can essentially audit the project, which ends up making the code more efficient and secure.

Addons and Plugins are Plentiful

Open-source projects are easily extended by third parties to add on functionality that the original authors didn’t include.

WordPress is a great example of this – they have over 1,600 themes and 21,000 plugins available for their system, while closed-source blogging systems like Posterous and Tumblr have only a few hundred themes and a very limited plugin selection.

It’s worth pointing out that the movement towards Service Oriented Architectures and exposing public APIs is allowing third parties to extend even closed-source systems. However, in these situations, third parties are relying on the closed-source provider to maintain those APIs consistently over time. And as we’ve seen, this isn’t always a realistic expectation.

No Sales People or Commitments

Obviously, one of the best best benefits of using open-source software is that it’s almost always free (“free” as in “free beer”). This means there are no contracts to sign, no commitments to enter, and no sales people to wrestle with.

Just find the project’s website, download the software or clone the source code, and you’re on your way. You can get up and running quickly.

Support is There, But Not Required

For larger, more complex open-source projects, you can usually pay if you need help or support, but it’s not required to use the software.

This means it’s still possible for a profitable business to form around fundamentally free software. Red Hat is the most obvious example of a company doing this right. They offer premium support for Linux, and a bunch of other open-source technologies, and have revenue of over $1Bn.

A Counter Example

I work with open-source so often that I often take all of these wonderful benefits for granted. I usually build projects using Python, Django and MySQL – all open-source – and so I’m used to great documentation (or tutorials where the docs are lacking) and libraries and apps I can use to extend core functionality when I need them.

Recently however, I've had to work on two projects using Google's closed-source App Engine.

App Engine is Google’s cloud-computing platform for hosting web applications. However, in order to run your application on their platform, you need to build it specifically around their APIs.

Now, you might think that a company like Google, with some of the best engineers in the world, would be able to develop a fantastic set of APIs and offer world class tools to help you monitor, manage and debug your application.

But even with all that tech talent working on the project, I’ve found developing for App Engine to be slow and much more frustrating than any of the open-source technologies I use more regularly.

Their documentation is poorly organized and vaguely written. I’ve even seen code samples in the documentation with incorrect syntax – they wouldn’t even run if you tried using them! I’m sure they were typos by the engineers who wrote them, but those sorts of issues get fixed very quickly in an open-source environment.

Using common Python libraries like simplejson is unsupported. Finding proper tutorials is tricky. Querying for objects can lead to surprising results (although that might just be my nascent familiarity with NoSQL). Getting support from Google is all but impossible.

Plus, there’s the vendor lock in. If I ever wanted to take my application and host it somewhere else, I’d have to rewrite huge parts of it in order to make it work with more standard databases.

Working with closed-source App Engine has helped me realize all of the wonderful benefits that I was accustomed to when working with open-source alternatives.

What it comes down to is this: no developer is perfect. No matter how many bright engineers you have under one roof, they’re never going to be able to test every use case, add every features and support and explain the software exhaustively.

Just as the rough rock gets polished into something smooth and beautiful by exposure over time, scrutiny from a huge community of dedicated developers and part-time hobbyists can turn a project into something really elegant and smooth to work with.

That exposure helps to make open-source projects easier to learn and generally more efficient, secure, easily extendable than their close-sourced counterparts. To me, that makes open-source technologies the most obvious choice.