Benefits of providing software in open source form

By Andy Oram

The following talk was given at a meeting of the Boston chapter of the Association of Internet Professionals on 20 October 1999. The talk was accompanied by a set of slides containing related information.

The organizer of this event asked me to talk about the benefits of using open source software. But since my audience is in the software industry, I find it much more interesting to talk about the benefits of producing open source software. If you develop software you’re proud of, for your own use or for distribution, why not try jumping on the open source bandwagon?

What, then are the benefits of producing open source software? First and foremost, you are no longer wage slaves. Yes, the true progenitor of open source was Groucho Marx.1

Obviously, then, open sourcing forces you to choose a service model for your business. Eric Raymond, in The Magic Cauldron, says that all software business is really a service business already. For instance, if you can’t upgrade or provide bug fixes, you dry up.

Revenue models

So we have to consider how to derive revenue in an open source, service model. Nobody knows for sure what works. The whole industry is in an experimental phase, and you’ll have to try different things to see what works for you.

The first common solution is to depend on sales of media: CD-ROMs, books, etc. Walnut Creek has been making money this way for years, it’s an important source of revenue for the Free Software Foundation (FSF), and it was how all the Linux distributors got their start. (I was invited by a friend several years ago to watch him load the first ever commercial Linux distribution—a set of 50 floppy diskettes.)

A second model is probably the most popular right now: offer customer service and personalization. Linus Torvalds touted this model at Internet World recently. It has replaced revenues from media as the main model for Linux distributors. But in its most classic form it is associated with Cygnus Solutions, which supports GNU software and contributes their own enhancements for free. Eric Raymond also suggests selling a brand, an approach that Bob Young credits with making Red Hat successful. In other words, people can get the Red Hat distribution from lots of places, but now that Red Hat has proven itself there are plenty of customers who feel more secure going directly to Red Hat.

The service/personalization model is a relatively proven one, but I see a worrisome conflict between basing your business on it and providing robust and easy-to-use software. We’ll have to maintain a high standard of ethics in this business or it will implode.

Another model is to make your core free and offer proprietary enhancements. This is the model used by Eric Allman for sendmail and John Ousterhout of Scriptics for Tcl/Tk.

Yet another revenue model is to guilt-trip your users. I won’t say who uses that model. But in a very broad sense, what is the motivation behind all the companies currently contributing to Linux and Apache and Samba and so on? They’re afraid that if they don’t provide funds, the software won’t grow and improve. That motivation’s not far from guilt.

With a lot of volume, some have even made advertising work. A site developed by O’Reilly in early 1993, the Global Network Navigator (GNN), was the first Web site to sell advertising space, as well as the first Web site to have professionally edited content. In those days, it was hard to convince advertisers that the Internet was a valid medium, but now ad revenue supports a number of famous sites, including Yahoo! and Slashdot, the latter providing news of interest to the free software community. Some O’Reilly sites of interest to this community, perl.com and xml.com, support themselves through advertising. Some industry analysts claim that ISPs are all going to have to go a free model supported by advertising. If so, we’re going to need a law—I doubt we can get our local representative Markey interested in sponsoring this—where everybody spends an hour a day clicking on ads. Just today, there were news reports about how two major publishers—Cahners and Encyclopedia Britannica—have been losing money from print sales and hope to make it up through advertising on their Web sites. Good luck!

Most audaciously and creatively, you can use your software to offer ongoing, interactive services. That’s the model for some Internet portals. They hope to make money from selling things to regular users. The solution requires an extremely well-focused consciousnes of what’s unique about your site. But it may be timely. You’ve probably heard the predictions that the whole world is moving from an agricultural and manufacturing economy to a service-based economy. I don’t believe that, because we all still need to eat and to wear clothes. But in the field of software I could well believe that we’ll stop offering software as products and use it instead to offer services. That’s great for all of you as Internet professionals. And yes, you will still earn wages.

To repeat my initial point, all models are experimental and you have to be willing to take a risk. If open sourcing is done as a last-minute and last-ditch measure (like Netscape with Mozilla), or if you half-heartedly open part of your product, maybe a part that was free already anyway (like Apple), or if you don’t bring your users into the locus of power and give them some chance to shape the software (like Sun), open sourcing probably won’t get you much in return. A more forthright model is to decide what you need to support your work, develop it (most likely basing it on existing open source software) and then give it back to the open source community.

Reasons to give it away

So why give away what you’ve written? Let’s return to the benefits. Actually, the whole first part of my talk on revenue models was a digression. I’ll pop the stack now and continue talking about the benefits of providing open source software.

The first benefit is mind-share. Commercial companies try to persuade users to try their products by offering something such as free three-month, self-destructing demos, but those aren’t very persuasive. Either the length of time isn’t enough, or users are reluctant to put their work into a product where they might lose it all.

The mind-share benefit obviously worked for Linus Torvalds, as it did earlier for Tim Berners-Lee, and earlier yet for The X Consortium. But like rock musicians, only a lucky few will make it this way. Throwing your software in the open source ring won’t automatically mean you’ll be hired by a hot California start-up.

Another advantage of mind-share, pointed out by Raymond, is that people may do your ports for you, making your software more widely available.

You may also get help from customers in the form of better bug reports, and maybe even fixes.

Open sourcing also engenders trust. Raymond and other open-source advocates claim that their software tends to be more reliable, a particularly good argument in the case of security. For instance, after an embarrassing security lapse, the PrivacyX anonymizer site offered a month ago to open their code. (I haven’t seen whether they’ve actually done it.)

Finally, don’t forget the excitement of working with people around the world. Users and developers may be highly opinionated and demanding, but you know they care about your software.

The development model

If you go the open source route, you must be prepared for a very different pace and work style. Warn your programmers that they’re about to become customer service reps. Try to make sure they have patience and other skills in human relations. Even if they don’t, some customers would prefer a short-tempered curmudgeon who knows the code through and through to a cheery, eager naïf reading off a cheat sheet.

The programmers will be distracted from producing code, a sacrifice of time for which you’ll be only partially compensated by getting a few bug fixes from outside.

The development life cycle is also completely different from what you read about in software engineering textbooks.

I notice, by the way, that Microsoft has chosen to give its next operating system the code name “Millennium.” That’s a smart choice because it leaves plenty of room for schedule slips. I promise this will be my only Microsoft joke in this talk, because I don’t consider them evil and I don’t want to get into a religious war. When many of best free software products run on Microsoft systems—including Apache and even the GNU compiler—you can’t draw a hard and fast line to exclude Microsoft products from consideration.

In your open source life cycle, you can preserve all the usual artifacts. You can still have regression tests, Alpha and Beta releases, a quality assurance department, and even brief code freezes, but the process is much faster, more open, more exciting, and more lightweight.

The cliché for the process is “Release early, release often” (a phrase used by Eric Raymond, maybe by others before him). In this age of Application Service Providers, the process is more appropriate than older release models even for closed source software.

You’ll maintain your versions in a CVS repository on the Internet open to the whole world, and see fixes being checked in from all over the place. To tie everything together, you will probably need to follow Raymond’s beneficient dictator model.

I haven’t discussed the wording of your license in this talk. It would talk more than 10 minutes or even 10 hours, and be pretty boring. We certainly want to avoid a proliferation of many licenses, but you still have to do some careful research and understand the ramifications of each license to choose the one that’s right for you. I can tell you it’s tough, since I am working out the wording right now for the O’Reilly open content license on our Samba book.

So now it’s time to say a little about the O’Reilly experience. As you know, we have a software group that released a very early Web server for Windows systems. It was quite successful at first, but got caught between the rock of Apache and the hard place of Microsoft IIS. We still have some valuable products to offer, such as the WebBoard collaboration tool. Tim O’Reilly is talking about making our products open source, but it’s very, very hard to go from a proprietary model to an open source model.

I ought to mention a new company we initiated called collab.net, which is trying to increase the viability of the open source model through a service called sourceXchange. The itch that sourceXchange is trying to scratch involves organizations that need to get quick solutions and are willing to pay for them, but want to use open source software. sourceXchange matches organizations possessing money with developers possessing skills. The matching is not hard in itself, of course; the real problem is accountability. How can an organization and a developer agree that the developer actually did what he or she was paid to do, in a timely manner? sourceXchange tries to solve this problem through agreed-on milestones and peer reviewers. Another company doing a similar effort is CoSource.

In our better-known book area we’re starting to open up selected content, as is New Riders and some other companies. The big question for all publishers is whether to restrict the right to print the book. We want to let people print copies for their own use, or for use in courses and other limited venues. But will it hurt sales to let other companies slap a cheap binder on our book and sell it cheaper? For how many more years, anyway, can we depend on selling books in paper form, before we go the way music studios and newspapers seem to be going?

I can envision a time—this is fantasy right now, you have to understand—when a publisher contracts with an open source software team to help them create professional-quality documentation. It will look less like the publisher hiring an author, more like a publisher offering professional services to the team. Instead of a harried writer working in secrecy and a few technical reviewers trying in three weeks to ensure that the book is relevant and accurate, we’d have everything out in the open and accept comments at any stage, just as the slashdot Web site recently reported that a journalist had its readers publicly review an article before publication. (That’s a logical absurdity, of course, because if the article is being publicly reviewed it’s obviously published. The journalist did not put it in a print publication until the review was finished, however.)

Like open source software, open content documentation faces lots of dilemmas. You must remember that a writing a good book is a more wholistic creative process than developing software. We also have to constantly consider the writers’ compensation. What if somebody saunters up out of the blue with three chapters on key parts of the software, and the team affirms, “Yes, this is really good, let’s use it and give him royalties”? That could leave the original writers miffed, if they took on their work with the hope of getting a big financial pay-off. I have a tentative solution to this problem: offer a one-time payment to the people who write individual chapters, but leave the bulk of the remuneration to the main author. In good documentation, this is a fair solution because the work the author must do to integrate material and unify the style of the book is greater, in my experience, than the creative effort that went into writing each part.

Using Open Source software

I feel I should say a little about the issue I was originally invited to talk about: the benefits of using open source software. People tend to get obsessed about support, but I consider that overblown. The availability of good programmers and technical support depends on the popularity of a technology, not on whether it’s open- or closed-source.

I was hoping to provide you with URLs for white papers that clearly explain the benefits of open-source software to the pointy-haired. The Open Source Institute has short papers, but they’re more like hints about how to approach the issue than strong arguments backed by statistics or anecdotes. Perhaps the good white papers remain to be written.

Political and Legal Issues

If you’re interested in sharing software and other information, you can’t afford to ignore the laws and court cases that are changing our rights. Many of the benefits brought by technology are being undermined by laws. The scope of intellectual property is constantly growing. For instance, you may have read in the papers that South Africa is fighting drug companies over obtaining drugs to keep AIDS patients alive at affordable prices—that’s an intellectual property issue. To move quickly from the tragic to the absurd, you may have also read in the Boston Globe recently that some Japanese have claimed patents on curry, to the dismay of many people in India. Currently, the patent threatens to turn only cooks in Japan into pirates, but if the World Trade Organization forces all member nations to honor each other’s patents, Indian cooks will be told to pay a fee for the recipes they’ve been using for centuries. And we’ve all heard that companies are patenting our genes, which probably doesn’t mean you’ll need a license to have a baby, but probably does mean the emergence of monopolies over medical treatments of certain genetic ailments.

In the electronic world of information, we may find soon that we can’t distribute a document to students in order to discuss it in class. Or that a researcher won’t be able to cite statistics in a study because some company has provided them in a commercial database. Or that we’ll be sued for figuring out a proprietary protocol or file format in order to create a compatible product or just fix a bug.

So please take a look at some of the sites that discuss these issues, and take a side while there’s still time.


Slides
Author’s home page