Bruce Lewis, cgiemail author
It cost MIT money to develop cgiemail. They paid my salary. They paid my benefits. They paid overhead. They pay the people who run this web server. They pay for the network connection through which people download cgiemail. This is not all for philanthropic reasons; MIT has received direct benefit as a result of giving this software away.
Here is a fact about free software that few people understand: By giving it away, you share not only the benefits but also the costs. It would have cost MIT at least twice as much to get cgiemail to the level of quality it has today if it were not free software.
The principles that made free software pay off for MIT will also work for any company that uses software but makes money from something other than software licenses. If you work for such a company, you are probably familiar with the "buy vs build" dilemma. Do you buy off-the-shelf software to solve the problem at hand, or do you build your own solution from scratch? There are significant drawbacks to both options.
Companies pursue the buy option because it will be easier and faster than building custom software. Nevertheless, buying the right software is a project in itself.
When buying software, it is often difficult to determine which packages you want to look at seriously. Marketing literature is often vague and unhelpful. If you're lucky, you can download an evaluation copy either by paying a nominal sum, or by providing personal information so that their marketing people can contact you. If you're unlucky, you'll have to negotiate with them to obtain an evaluation copy.
Free software avoids this drawback. If its home page doesn't describe it clearly, you can download the software itself, try it out, and even look at the source code to see if it does what you want. This is how I evaluated options before creating cgiemail.
Once you've settled on a particular product and installed it, the particulars of the licensing agreement begin to bite you. If you use a license server, will you be unable to use the software when that server is down? The last thing a serious operation needs is another point of failure. If you're licensing server-side software, do you need another license for a hot spare? What if you want to do testing on a separate server? What happens if the license is tied to some kind of hardware ID and a disaster forces you to restore from backup onto different hardware? A site license might be helpful, but what if you have users who may want to run licensed client software from home through their own ISP? Does the site license cover that case?
Using free software like cgiemail means you really have to go out of your way to violate the license. Day-to-day duties that naturally involve copying software are not encumbered by license issues. This kind of freedom is the real meaning of "free" in "free software".
At best, buying off-the-shelf software gives you most of the functionality you want at relatively low cost, but there's always some functionality you wanted that isn't there. Often there are simple changes that could make the software much more suitable for your task. Measured over the lifetime of the software, such changes might save the users a lot of time (a.k.a. money), but you have no way of making those changes.
Using free software means you don't have to write it from scratch, yet you're free to make whatever changes you feel are appropriate. You are not obligated to share these changes with anyone, but may choose to send them back to the maintainer of the software to ease your adoption of future releases.
Ever been stuck with a piece of software you can't legally run anymore? Ever sink money into "the standard" only to have its support discontinued a few months later? People who buy software because they think it will protect them from obsolescence often get a rude surprise.
This happens because bought software, if it stops generating enough revenue to support marketing, legal and other departments necessary to run a software company, dies completely. It's unlikely that another company will pick it up. In contrast, for free software to survive, there only has to be one programmer out there interested in maintaining it.
In the unlikely even that free software does become obsolete, at least you have the option of supporting it yourself or hiring a third party to support it.
Even the best-laid business plans can be waylaid by software bugs. What happens then? No amount of money can force a large software company to put your bug at the top of their list, no matter how urgent it is for you.
Free software gives you better escalation options. Most bugs get fixed simply by being drawn to the attention of the free software maintainer. But even when that fails, your hands are not tied. The programmer whose progress is stopped by the bug can go ahead and fix that bug. Or a third party can be hired to fix it.
The biggest nightmare of software built in-house or by a contractor is that the author will leave, and nobody else will know how the code works, how to recompile it, or sometimes even where the code is. This situation means job security for the author, but insecurity for the organization.
MIT has no such nightmare. Because cgiemail is widely-used free software, people other than the author are constantly recompiling and using it. Everybody knows where the code is; you can download it off the web page. To achieve the same end, MIT could have paid someone to do SQA (Software Quality Assurance) every time a change was made to cgiemail, but instead it got this assurance for free.
There's a training cost associated with software you build yourself. New employees need to be brought up to speed on your system, even if they've used software elsewhere that performs similar functions. This is one of the most common reasons why people choose to buy software even if it doesn't completely fit their needs.
A great moment for cgiemail was during a training session for web publishers at MIT. "Oh, I already know how to use that," said one. "My ISP has it." It was the best of both worlds, in that cgiemail was written to fit MIT's needs, and yet someone could come to MIT already knowing how to use it. The same benefit can be gained by adopting widely-used free software that someone else wrote.
You usually choose to build your own software when nothing else is available to fit your needs. But what happens if off-the-shelf or free software later becomes available that would fit those needs and do even more? You find yourself supporting an obsolete product.
It is unlikely that off-the-shelf software will make cgiemail obsolete; it's hard to get people to pay for a product when a good alternative is already available gratis. And as for other free software making cgiemail obsolete, there's a good reason why that didn't happen.
People who wanted the functionality of cgiemail plus something else started with cgiemail, added their functionality, and sent MIT the changes. This is where the formatted-printing functionality in cgiemail comes from. It was in the outsiders' interest to have their changes integrated into MIT's distribution so that they could take new releases without having to re-integrate their changes. They also gained the standardization benefit described in the previous section.
Other WWW-to-mail gateways have been written since cgiemail, but only when someone wanted to do things in a different way, filling a different niche; cgiemail is still widely used.
Build-it-yourself software does have an advantage over bought software in that you can fix urgent bugs yourself. The down side is that you have to drop all the other important things you're doing to fix the bug, and usually only one person knows the code well enough to fix it.
As a direct result of giving away cgiemail, MIT never had to deal with this situation. This is not to say cgiemail never had bugs; it did. But outsiders ran into these bugs first, and I was able to fix them in a leisurely fashion.
Having a wide base of users means software will be tested in ways a single SQA person would never think of. The result is robustness, so that when your organization wants to use it in a new and different way, the software is ready.
Here are some other steps I took to keep supporting cgiemail from becoming burdensome:
Other users did in fact answer questions, but I always kept an eye on what questions were being asked. Even "dumb questions" can help show where documentation can be clarified.
What's to keep a software company from taking your free software, adding some bells and whistles, and selling it? What if they integrate it into a product that you later buy, then when it doesn't interoperate with your own version, you can't even look at their source code to figure out why?
This never happened with cgiemail, largely because it fills a small niche, doesn't really need more bells and whistles, and is automatically integrated with a web server by CGI. However, things like this have happened with other software in the past.
You may want to choose licensing terms for your software that specifically disallow such exploitation. The most popular license of this type is GNU's GPL. See GNU's Pragmatic Idealism essay for examples of the GPL being used to successfully protect free software.
If you don't want to get into the business of legally defending the software yourself, you can sign it over to the FSF, a non-profit organization that can be trusted to vigorously defend free software.
If you would like to discuss any of the issues raised here, please post to the Usenet group gnu.misc.discuss and include buybuild (all one word) as part of a subject line that describes the issue. For example:
Subject: buybuild: what real-world companies write/maintain free software?
The buybuild keyword will help me find postings in response to this page, and the rest of the subject line will help other readers of the newsgroup decide if it's a thread they want to get involved in. Please also include the URL of this page in the body of your message so that other readers of gnu.misc.discuss will know what you're referring to.
If you don't have access to Usenet, try deja.com.
Open-Source Tools Gain Credibility covers the expanding use of free software in Information Systems departments.
Open Source: Programming as if Quality Mattered describes quality benefits derived from source code being widely available.
Linus Torvalds Interview - "Making Linux GPL'd was definitely the best thing I ever did."
Just Try Suing Microsoft answers a common misconception about accountability and free software.
Lecture at KTH is a lengthy piece that describes the chain of events that shaped Richard Stallman, head of the FSF, into the radical defender of free software that he is today.