At the Forge: Why Linux?

Break out the champagne! This month, Linux Journal is celebrating its 100th issue, and I've decided to take a break from my exploration of open-source web/database technologies to join the party.

There are plenty of good reasons for Linux users (and advocates of open-source software in general) to be happy. Despite the downturn in the high-tech economy, open-source software development continues at an extremely rapid pace. When Linux Journal was first published, few people had ever heard of the free operating system created by a Finnish student. Nowadays, many people have heard of Linux, even if they don't understand what it is or what it can do for them.

Indeed, while many of my clients know that I push for open-source solutions, they are always curious to know why I favor them and, more importantly, why choosing such solutions is in their interest as well. So at the risk of preaching to the converted, this month's column reviews some of the reasons why Linux is such an excellent platform for building server-side applications. I hope some of the ideas I put forth here will help you evangelize free software solutions with your own colleagues and clients in the years to come.

Hackers are interested in technologies and tools that teach new skills and perspectives. But in the real world, people are interested in getting their jobs done as quickly and cheaply as possible. Software is a means to an end, rather than an end in and of itself.

For this reason, I've found that the best way to sell people on open-source software is to say that it does more and costs less. Either one of these factors isn't enough by itself; it's easy to find expensive, high-quality software and useless to install cheap, poor-quality software. As consumers, my clients are always eager to get more for less, and free software appeals to them in this way.

When I pitch solutions to my clients, I begin by explaining that I'm offering them something they might have thought impossible: inexpensive software that does what they want, without crashing. When I explain to Windows users that I have yet to see a Linux system crash in over six years of running dozens of systems, they are shocked and incredulous. When I tell them that this software is freely available on the Internet, they find it even harder to believe.

My clients often wonder who is supporting the software and what happens if things go wrong. They are relieved to hear that not only can I offer them the support they need but that they can look for support elsewhere if they don't approve of my work. This, of course, contrasts sharply with the attitude and restrictions that many consulting firms impose on software installations. The open-source approach is thus friendlier to consumers than the traditional software model, reducing costs and encouraging competition.

Of course, not all free software is of high quality, and not all consultants really know what they're doing. The community development process can produce excellent results, but that doesn't mean everything released on the Internet is guaranteed to be safe and stable. Indeed, it's clear that many programs, including some popular ones, were uploaded without undergoing any testing. Programs like these give the entire Open Source community a bad name and often do more harm than good. Several times per year, clients call me in to fix a program they have downloaded that worked fine at first, but eventually proved itself to be insecure, unstable or full of bugs.

Even if you find that your server depends on a bug-ridden, insecure, open-source application, all is not lost. That's because the nature of free software ensures that you can modify it to suit your needs or fix it when problems arise. In this way, shared-source licenses, which allow users to view the source code but not to modify or fix it, miss the point. Buying a house or a car entitles you to fix it on your own; why should software be any different?

True, the shared-source license does mean that more people will look over the code, so security and stability problems will be identified and fixed more quickly. But being able to read the source code isn't nearly as important as being able to improve it. Moreover, folding these improvements back into the community version means that everyone else will benefit from your adjustments and be able to make further improvements. Thus, contributing to the community process is in the interest of everyone who uses open-source software; it's not simply a nice thing to do.

Because I tend to use mature tools such as Linux, Apache, Perl and Python, it's relatively rare for me to find bugs in the software I download. But several times per year, I will discover a problem or limitation in the software I use. Having access to the source code guarantees that I can get up and running as quickly as possible, and it also means that others will not have to suffer through the bugs that I've fixed.

It's ironic that I can still use this argument today, given that a similar problem with printer drivers was what drove Richard Stallman to found the Free Software Foundation, whose GNU Project has been crucial to the success of Linux and free software. It's also amazing to discover how quickly we get used to having the source available and to being able to inspect or modify every part of our computer systems.

Along the same lines, Linux systems tend to come with “batteries included”, to borrow a phrase from the Python world. I recently began work on a project that will be deployed on Solaris, and I soon remembered how much richer and better-stocked a typical Linux distribution is when compared with a standard Solaris installation. True, I can spend half a day downloading and installing gcc, Perl, Python and the rest. But after years in which gcc was available on every machine I ran, it felt like I had been thrown back into the Dark Ages of UNIX.

Engineers are notoriously bad at keeping secrets, as Scott Adams has occasionally pointed out in his Dilbert comics. Indeed, one of the things that attracts me to open-source software is the fact that there are no secrets. Clients hire me because they want to save themselves time or because they lack expertise in a particular area, not because they are forced to do so. For this reason, I tend to think of myself as analogous to a lawyer or accountant, both of whom offer advice and documents based on freely available information.

This “no secrets” philosophy tends to work well with my clients, including those who aren't at all interested in knowing how the software works. They know they can ask me questions, and I'll give them the best answer I can, without having to hide behind marketing hype, mandatory updates or double-talk. My technical clients, of course, enjoy knowing they can dive into the code or read the documentation; the only thing stopping them from knowing what I know is time and experience.

My nonprofit clients, who are in many ways the perfect audience for open-source software, are often excited by the possibility of using such tools. In particular, I have found that educational institutions like the idea of sharing information and community involvement, in software as in other spheres of life. Telling them they can both save money and participate in a community of like-minded people is a powerful combination. Moreover, nonprofits typically have little incentive to keep changes within the company, meaning that they can more easily participate in the Open Source community.

When I first began to write this column for Linux Journal, most server-side web applications were handwritten CGI programs. A huge number of web sites still use such programs. But as the Web has become more sophisticated, people have demanded toolkits that make it easier to develop high-quality, scalable web applications in a short amount of time. It shouldn't come as any surprise that many proprietary software companies have come to fill this void. It is shocking, however, to find out how much money they want for their software—sold on the condition that their consultants are hired to customize it, followed by a mandatory service contract.

Luckily, the open-source world has responded. A number of open-source toolkits can be used for creating sophisticated server-side applications. Zope, as we have seen in recent months, is a fantastic (if complicated) application server, making it possible to create web applications that connect to databases and other information sources. Next month, we'll begin to look at OpenACS, designed to make on-line community systems easy to build and modify. Furthermore, such environments as mod_perl, Mason and the numerous Java- and XML-related tools sponsored by the Apache Software Foundation increasingly mean that locating the right tool can be as difficult as installing and using it.

But as wonderful as these toolkits are, we must remember that not everyone will be won over. My harshest lesson on this front came last year when a potential client decided against hiring me to create a simple content management system for producing a product catalog for the Web. I was told that my bid came in at $800,000 less than my closest competitor. However, because I was using open-source software and the competition was a well-known name in the world of content management, I lost out. (That client has had a round of layoffs and quarterly losses since then, and their web site still appears to be managed by hand, so at least I won a moral victory of sorts.)

We should also remember that not every player in the open-source sphere can be trusted to follow through on their promises to the community. Many open-source advocates were surprised and disappointed when Lutris pulled the plug on its open-source Enhydra Enterprise Java application server last year, turning it into a proprietary product. Luckily, there are alternatives; not only has the GPL-licensed JBoss application server dramatically grown in popularity over the last year, but Sun recently made it clear that nonprofit, open-source J2EE implementations will be able to receive official certification in the coming months. This should help to reduce further the stigma that some businesses associate with open-source software.

But even if you suffer setbacks, don't be fooled: as IBM, HP and even Sun now acknowledge, Linux and open-source software are powerful, stable and should be taken seriously. “World domination” hasn't yet arrived, but brand-name recognition, financial realities and admiration from academics and commercial entities alike are helping us move ahead.

I'll conclude this column with a salute to the hardworking staff that makes this magazine possible. I read Linux Journal for nearly a year before starting to write this column, and I continue to read it when it comes in the mail every month. The articles consistently reflect the diversity, sophistication and interests of some of the most creative software developers on the planet.

The fact that Linux Journal has now reached 100 issues should prove, beyond a shadow of a doubt, that Linux and open-source software are here to stay. I hope to write a similar article when the 200th anniversary issue comes around.