Charlie's Thoughts

This is part two in our look at open source software, this edition covers how open-source software comes into being and is developed essentially for free!

Contributing:

Normal companies like Microsoft, Google, etc. pay people to develop software, but yet there is often comparable software (Linux, OpenOffice, etc.) which is free, if not better. So how do these free applications stay free? Well in the case of large projects such as Linux and Firefox, they are supported by foundations which collect donations and solicit support to help fund the core developers and to pay for the overhead of running a website.

Most projects, however, begin with a spark from one individual or a group which does the initial development. For small things, maybe it’s just some guy who made a tool for himself and decided to share it. For medium sized projects, the initial release is often sloppy and bug-ridden as it is developed (and thus tested) by a small number of people.

As the project gains popularity (If it ever does), people will start to complain about the bugs and to request features. The developers will usually prioritize those requests and work on them in their free-time (I.E. Slowly). As a project becomes more stable and useful however, individuals and companies (like myself) will start to use the projects. Those people may have different requirements than what the software does out of the box. For instance, my company wanted to be able to use IFrames in CKEditor. Thus it became my job to develop a plugin which could handle this task. When I was done, (and since I’m a very classy open source guy), I sent my work back to the project.

Now it isn't as though anyone can just waltz in and alter the code. Usually the code is stored in what's called an SVN system (Subversion Control System). This system is the perfect solution for managing projects. Here's why. First, everytime a new file is saved, a copy is created. Thus if I were to commit some bad code, it could just be rolled back to an old version, no problem. Second, it can do "branching" of code. This in effect creates a second copy of the code which people can work on for specific reasons. For instance, when a large new feature was introduced to CKEditor, it was first created in a branch so that any problems stemming from this feature could be isolated from the rest of the code changes.

It all sounds complicated, but it's really easy to use. To keep things sane, only the core developers can approve changes to the source code. So once they approve my plugin, it will eventually be integrated in and redistributed as part of the program. Thus even though my company didn’t pay for the program, we paid for the program indirectly. Because my company pays me, and it became my job to work on the project, the project as a whole benefits.

More generally, because each user wants slightly different things out of a program. They will expand the program in the direction of their needs. If we look at the entire user base, this will have the effect of eventually expanding and bolstering the project in all directions.

From a companies/users perspective, they could pay 1000$ for a commercial solution, or could pay their developers 400$ to take open-source software and alter it to fit their needs. For the company/user, this is often more lucrative because they are permitted to directly change the program and will benefit from future development, which is not always the case with commercial software.

So how does the software perform head-to-head? That’s something we’ll look at next time.