So, why, why do people and companies develop free software?

So, why, why do people and companies develop free software?


More and more people are discovering free software. Many people only do so after weeks, or even months, of using it. I wonder, for example, how many Firefox users actually know how free Firefox really is—many of them realise that you can get it for free, but find it hard to believe that anybody can modify it and even redistribute it legally.

When the discovery is made, the first instinct is to ask: why do they do it? Programming is hard work. Even though most (if not all) programmers are driven by their higher-than-normal IQs and their amazing passion for solving problems, it’s still hard to understand why so many of them would donate so much of their time to creating something that they can’t really show off to anybody but their colleagues or geek friends.

Sure, anybody can buy laptops, and just program. No need to get a full-on lab or spend thousands of dollars in equipment. But... is that the full story?

The first myth is that free software programmers are all starving. Many people don’t realise that a lot of free software programmers are actually paid to do their work. They are definitely lucky: they might be employed by a big company like Red Hat, that has never disappointed in terms of licensing and patch submissions. Or, they might work as contractors on specialised modules, on the basis that their code will be available to others; this happens a lot with the CMS Drupal, which we use for Free Software Magazine. On the other hand, for every (more or less) paid free software programmer there are many more who aren’t. They do it because they either need/want something that doesn’t exist (or, it does exist, but they need/want it done in different way), or because they just love programming and being part of a fantastic, enormous and ever growing community.

Paid or unpaid, company or private programmers, the question remains: why do they do it?

The answer, as amazing as it sounds, is “convenience”. It’s better, and more importantly cheaper, to develop free software.

A good example is Red Hat, which created Red Hat Enterprise Linux (RHEL). RHEL is based on thousands of pieces of free software, as well as extra packages that are developed internally. Unlike many of their less successful competitors, everything—even the custom software they’ve written—is released under the GPL (or another license which is ultimately based around the idea of being able to share the code). By releasing everything under the GPL, they basically get thousands and thousands of beta testers who test their code and send patches back to make sure that things get fixed. (For those who aren’t developers: a “patch” is basically an improvement to an existing piece of code; it’s basically a modification to an existing program, in order to fix problems or extend functionality). If Red Hat didn’t release the code, they would have to spend enormous amounts of money to do what they do—and it wouldn’t be half as good. What about CentOS, the Red Hat Enterprise Linux clone which uses Red Hat’s source packages and doesn’t require you to have a support contract with Red Hat in order to use it? I am sure CentOS “costs” Red Hat decent amounts of money in terms of lost revenue; however, I also know that it actually helps Red Hat’s sales (I, personally, know of two different companies that started out with CentOS and “upgraded” to RHEL), and creates an army of system administrators who are used to CentOS and are going to pick Red Hat Enterprise Linux when their company wants a supported operating system. It’s a bit like paying for advertising, really.

I talked about patches... why would all those people send patches back to Red Hat? Because it’s better to do so.

Take Apache, for example. If your company runs Apache on its servers, you, of course, need it to work right. Now, if it doesn’t and you find a bug, you can report the bug to the Apache developers. However, the bug might be one that will only affect a small minority of users; this might mean that it will have a very low priority for the developers. If it's important enough to you, you might decide to try and fix it yourself or, perhaps, pay somebody else to fix it.

If you send your patch back to the Apache developers, you will know that the bug will be fixed in every new release of Apache, so you won't have to keep fixing it every time you upgrade to a new version. Not only that, but everybody else who uses Apache will benefit too. Your patch will be checked over by amazing developers, improved, discussed and improved some more.

On the other hand, if you decide that you want to be greedy, and you don’t submit the bug, you will have to re-apply it every time a new version of Apache comes out—and hope that the your patch still works each time. You will also have to settle for a patch that hasn’t been peer-reviewed and, therefore, could (err... will), itself, be buggy. This is also true when you apply patches that would give your company a so-called “competitive advantage”: you might decide to improve Apache so that it’s vastly better than the “stock” version in some specific (and critical, to you) ways. However, you have the same problem: you will have to hope that whatever you change will keep on working over time with each version, and you will have to invest real money in developing and testing the patch(es).

I recently developed a karma module for Drupal. We wanted it for Free Software Magazine; therefore, I can say that I “got paid” to write it. Now, the module has been used on many other sites and is reviewed and improved by many other developers. On top of that, I also get recognition for having written a very powerful karma module for Drupal.

It might take the poetry away from free software, when you say that people and companies write it because it “suits them”. But, it may well be the case.

Does anybody mind? I don't, as long as software stays free—as in freedom.

Category: 

Comments

Anonymous visitor's picture

Hello! your article was nice for me because I was familiar with almost 99% term you've used but how can a non IT person be satisfied when he/she didn't ever heard about Apache, CentOS, RHEL, Clone, CMS, Module, Durpal .... Hey Hey it's gonna put a mess before him.... Explaining FOSS isn't much harder before an IT guy but the real need is out side the IT world.. Our university fellows, grandma, my neighbor...bla bla....Hope you got my point..Thanks

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

Totally agree with your premise in the article.
But noticed vague and repetitive spots in your writing. So I didn't send it to friends.
For example:

"It’s better, and more importantly cheaper, to develop free software."

"I talked about patches... why would all those people send patches back to Red Hat? Because it’s better to do so."

What does better mean? More efficient? Seems vague.

Also seems repetitive to use same word (better) twice in same way.

Ryan Cartwright's picture

By my reading of the editorial the use of the word "better" is not that vague because Tony uses the paragraphs that follow to unpack his statement. For example in the first instance he goes on to talk about how RedHat benefit from allowing CentOS to exist (via its use of free licencing). He says:

By releasing everything under the GPL, they basically get thousands and thousands of beta testers who test their code and send patches back to make sure that things get fixed.

That explains quite clearly why it's "better" for RedHat to release under the GPL. Better for RedHat and better for their customers. Better means more efficient, more economical and quicker.

For the second instance he goes on to give Apache as an example, saying:

If you send your patch back to the Apache developers, you will know that the bug will be fixed in every new release of Apache, so you won’t have to keep fixing it every time you upgrade to a new version. Not only that, but everybody else who uses Apache will benefit too. Your patch will be checked over by amazing developers, improved, discussed and improved some more.

That's why it's better to submit patches. Better to be permitted to and better to do it when you have the ability.

And are you really suggesting that to use the same word twice in the same way is bad? I may not be a grammar nazi but it seems that if you want to say something is better, then that is the best word to use. It's a different case if the two uses are in the same sentence or adjacent ones but for goodness sake, these ones are a hundred or so words apart and a whole paragraph apart.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

I like the editorial. I agree with the comments... so why don't the critics submit their own editorials? Call them columns.

puleen's picture
Submitted by puleen on

Though just have one typo to correct. It should read "companies" and not "company". Cheers!

-Puleen

Ryan Cartwright's picture

If you mean this bit..

Paid or unpaid, company or private programmers, the question remains: why do they do it?

Then I think it's not a typo. I think it is referring to company programmers or private programmers, rather than companies or private programmers.

Of course I could be wrong - has been known. ;o)

Ryan

nebuhada's picture
Submitted by nebuhada on

Thank you for the article. I have translated this article into Russian and placed it on my non-profit page http://vitalykorneev.livejournal.com/15786.html
If you have any objections or suggestions please let me know.
Regards.

admin's picture
Submitted by admin on

Hi,

No it's all good -- thank you for translating it!

Bye,

Merc.

carlos84's picture
Submitted by carlos84 on

I believe that they do so for publicity because the more people use their software the more famous they get................. and to be honest, I don't think it is a bad idea. not everybody can pay the price for an original software today and perhaps this is the only way many people can get it.

best regards from apuestas tenis

Author information

Tony Mobily's picture

Biography

Tony is the founder and the Editor In Chief of Free Software Magazine