Explaining Open Source software

I was recently asked to explain Open Source software. I’ve always been a big fan of Open Source because it has been an invaluable helper on a number of occasions. In fact, the interior of The Ultimate PC Primer was produced entirely with Open Source products — OpenOffice for composing the manuscript and final page layout and Inkscape for all the illustrations. As an explainer, however, I can understand why software newcomers might be a little confused by the concept of Open Source.

In The Ultimate PC Primer, I liken software to a recipe: a set of specific instructions that, if followed, produce something usable or consumable. The recipe is called source code. Find any recipe and you’ve got the source code for that particular food item. Normally, source code is not something a software vendor publishes. After all, the recipes of restaurant chains and popular commercial food products are big secrets. No one would imagine Coca-Cola freely giving away their recipe. Likewise, most commercial software source code — the recipe of the computer program — is also the core of the vendor’s business. So when you first tell someone that with Open Source software the recipe is freely available, you might get some puzzled looks. Why would someone give away the secret of the secret sauce? This doesn’t make sense to those who grew up and worked in the non-software age. In their world, you would never publish blueprints to your products openly, let alone for free.

You see, it’s not so much an explanation of Open Source software that’s needed. The class of software itself isn’t significantly different from any other. It’s the philosophy, attitude, and model behind Open Source software that needs to be explained to those who usually think of software like hardware (or any hard product.) It’s about contribution, collaboration, and helping to make something possible (or better) that might not otherwise be possible without offering a wider community the ability to lend a hand. It’s like more like volunteer work than commercial labor. To return to the food analogy, if traditional software is like paying to have a meal catered, Open Source software is like pot-luck dinner. Got cooking skills? Feel free to bring a dish to pass. No skills? Lucky you. In most cases, you’ll still get to partake of the goods because others are sharing their time, facilities, and expertise for the benefit of all.

I could go on with more analogies and explanations. For instance, it’s completely possible to use both Open Source and traditional software at the same time — for the user to benefit from both.  After all, you could bring come Coca-Cola to your pot-luck dinner rather than making lemonade from scratch. But I’m going to wrap up this post… because I’m suddenly quite hungry.

In closing, if you’ve had to explain Open Source software to others, what examples, correlations or analogies have you leveraged?


One Response to Explaining Open Source software

  1. Danny says:

    As an Open Source developer, it’s probably worth contributing my own reasons. In general, I write software to solve a problem I’m having. This is the case with many Open Source developers; software is usually written to “scratch an itch”. Once the problem is solved (ie, the program is written), it’s done. It doesn’t cost me any more time or effort to allow others to benefit from the work I’ve already done, but it does provide me with a good feeling that I’m helping people.

    Ok, technically it does cost me a little bit of effort. I need to find a way to distribute the software, which means putting the code up on something like sourceforge, freshmeat, or similar. And then there’s a potential support cost, as other people use my software but ask me for help with it. That is where the commercial benefit to Open Source comes in. Software income does not have to come from just selling the code. In fact, if you try to make money from selling the program itself, you need to make sure people can’t just copy it. That means spending more and more money developing copy protection schemes, all of which are ultimately broken by someone. So, it’s really impossible to completely control your software.

    The other way to make money off of software is through support. You, the developer, are the expert on the code. If you can provide effective support, you can easily make more money than you would just selling the programs. In my case, I provide most support for free, because I enjoy doing it. But if someone requests a substantial new feature, they can pay me for the larger investment of time. Sure, someone else could become familiar with my code and also provide support. But that happens with commercial software as well; look at how many people provide Microsoft training but who do not work for Microsoft. 🙂

    Ultimately, my point here is that it’s entirely possible to make money off of Open Source software if that’s someone’s goal. But it’s also very much possible to release code openly just because that’s what the developer feels is the “right” way to be a member of a community. It’s just like any other area in which someone has skills; Like Ben said, it’s the software equivalent of having a cookout. We have resources, and we’re willing to share just because that’s what we feel is the neighborly thing to do.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: