I've been giving away my software since 1983, full time since 1991. I don't do it for fun, although I enjoy it. I do it because it's a way for a small business to earn money and it's fun. Each of my software interests started as a hobby, and some have turned into a profession. Not every hobby of mine has turned professional, and I hope to explain why some have and some have not.

Three of my hobby projects, which I'll talk about in depth after I introduce myself, have turned profitable. They are Freemacs, Packet Drivers, and qmail.[1] Freemacs is an MS-DOS text editor, styled after Emacs. It's still used today as the official editor of the FreeDOS project. Packet Drivers hide the difference between Ethernet cards in an MS-DOS system. If you've ever eaten at a McDonald's restaurant, your order was communicated through Crynwr Packet Drivers. Qmail is a mail transfer agent (MTA) for sending and receiving Internet mail. Qmail is the engine behind Rediffmail's 30-million-user, multiterabyte, 100-node email cluster, and many smaller sites.

Contents

Introduction

I did hardware hacking long before college. Digital electronics was too expensive for me: $1 per TTL quad nand gate at a time when vinyl records cost only $5. So, I fiddled around with analog electronics. I invented a trigger sweep for my dual-beam oscilloscope, and an analog computer throttle for my model railroad.

My high school was a member of LIRICS: Long Island Regional Instructional Computer System, which had a PDP-10 students could use to learn to program, via teletypes operating over modems. I was at Baldwin Senior High School from 1972 to 1975, but took advantage of the program only in my last year, from '74 to '75. I learned BASIC and wrote a four-banger calculator program. I also wrote a word processor in BASIC, for which I had to do all sorts of horrific string manipulation. It took hours to format a two-page social studies paper. Partway through I got an Instant Message (IM) from an operator who asked me what I was running, and if it was looping.

During this period I learned PDP-10 Assembly language. JRST, HRRLZ, and SKIPNE are all familiar friends to me. Unfortunately, none of my candidate colleges had a PDP-10. MIT almost certainly did, but I was a poor scholar who was more interested in getting an education than in proving that I had one. Of course, everything on the PDP-10 was what we'd now call "open source." Nobody thought of holding back the source code in those days.

Many colleges will teach you how to become a businessman. I didn't have that desire upon entering college, and so I sought a degree in electrical engineering. Only later did I decide to run my own business, but how to learn? I started slowly, learned through experience, and didn't take too many risks.

I learned "on the job," and discovered new ways to profit from open source software. Everyone in the business had to teach themselves. There is no master's degree of open source business administration—not yet anyway.

Hewlett-Packard recognized my "genius" and hired me and my wife to work in its calculator division doing integrated circuit design. I missed programming, so I bought a RadioShack Color Computer (CoCo). This led to my first freelance income associated with programming.

I wrote programs for fun and sold them to CoCo Magazine for distribution. They were just little cute things, but they were in Assembly language, so they were fast, small, and easy to distribute. The standard distribution was on audio cassette through a paid subscription. It was nice to receive money for writing a program for fun. Without a local user community, it was also the only way I could distribute my software.

Freemacs and Open Source

After I returned to graduate school, I started writing a programmable editor for MS-DOS. Instead of writing it de novo, I thought it should be compatible with Emacs. I had used Emacs while working at Hewlett-Packard, where I had done some hacking on an editor. That experience convinced me I wanted an editor without any distinction between editing and typing. I purchased a copy of the MIT AI Lab memo describing Emacs, written by Richard M. Stallman (RMS). I recognized his name because of his GNU Manifesto, a new document then. I sent email to RMS to get permission to sell a copy of the memo along with my editor. The document was in the public domain, but I thought that asking permission was only polite.

I got a call from RMS (this was back when his wrists hurt so badly that he couldn't type). He persuaded me to give away my version of Emacs rather than sell it. He appealed to my sense of fairness. He asked why I should profit from a manual that I had not written. I was impressed that so stellar a personage as RMS would take the time to call me. I decided that it would be best to give it away. I didn't really have any idea whom I might sell it to. All my previous software sales had been for the RadioShack Color Computer, and had been sold to CoCo Magazine. My editor was for MS-DOS, so this was a completely new situation for me. Once I decided to give it away, I gave it the catchy name Freemacs.

In graduate school, I had access to worldwide networks, and it was actually possible to distribute software "for free." Nobody was kidding themselves; the Department of Defense was paying the bills for the ARPANET, universities for BITNET, and companies for CSNet. Nothing was free to the institution, but the users perceived the networks to have no incremental cost. This led to allocation by congestion, but I'm not talking about economics yet. Regardless, a software author could give away software for the mere cost of uploading it to a distribution point.

Freemacs was distributed from SIMTEL-20.ARPA, an FTP site with copies of most useful MS-DOS software. It was run by the Army at the White Sands Missile Base, but nobody cared about where it was physically. The point was that they had good stuff, and they were sharing it. This made me a contributing member of the open source community.

Freemacs and Business

Freemacs was a hobby, and I had no intention to turn it into a business. My computers (even my home computers) were paid for by my employer, so I had no expenses to cover. As the program gained users, they told other MS-DOS users about it. Those users wanted updates, and none were available on any of the worldwide networks of the day. Having no other recourse, they asked me for copies. I knew that they were gaining from these copies, so I asked for a portion of those benefits in the form of a copying fee. Between 1985 and 1991, most of the activity of Crynwr Software consisted of putting software on floppy disks and mailing it to customers.

Staying in Touch

It's crucially important to stay in touch with your users. The biggest advantage an open source developer has is close contact with users. If you're the primary user for the software, of course you know what users want—you just sit and cogitate. Quite a bit of open source software is written to "scratch your own itch."

This is easy and rewarding because very little communication is needed. Programmers are not typically great communicators (most programmers fall into one of the four NT classes on the standard Myers-Briggs personality test). A programmer who can listen and talk is worth her weight in chips (and chips are worth more per ounce than gold).

With Freemacs, I started with a single mailing list, which proved to be a mistake: some people don't need any help and just want to know when new releases come out; other people want to get or give help but don't want to code; and still other people are interested in every miniscule detail of the program. One list cannot serve everyone. I found that I needed three lists.

One list carried only announcements of new releases. You really want to have an announcements list, and you need to remember to use it. You might send only one or two pieces of email a year, but those are crucial. First, you need to remind people that they've given permission for you to send them email. Second, people need to know that you're in business even if they don't currently need your business. Any user might suddenly find himself needing to become a customer. You need to be the proprietor of the relationship between the software and the user, as you'll use that relationship to make money.

A second list was for user-level help. Some programs are exceptionally powerful (I'm not thinking of the Unix "cat" or "tail" here, but something more like sendmail or qmail) and in-depth knowledge to properly exploit all that power. Some users want to acquire that depth. Others do not, but will dip their toes into the depths by asking a question on the user mailing list. If there are sufficient users of the program, you will have other businesses competing with you. One of the ways they will compete is by offering to help other people. No need to worry, though! By virtue of your proprietary interest in the program, you will have a built-in advantage over these other businesses. In any case, customers like competition because they perceive it as ensuring fair prices.

The third list is for developers. I am of two minds here. You could have the developers list open to all comers, regardless of their to contribute to the project. Or you could have the developers list be open only to those who actually have contributed. The main tradeoff is protecting the time and attention of your contributors. You don't want them signing off the developer mailing list because it has too many user-level questions being asked on it. You really need their attention to help you make decisions that will affect them. For example, if you change an API, you need to clear that change with your developers—first, because it keeps them involved in the process, and second, because they may be relying on something you're doing.

Two interesting stories about mailing floppies: one is about a customer in Ireland who had two floppies go bad on him. Guessing that his email was going through some kind of antiterrorist scanner (as the Irish Republican Army was quite active at the time), I sent him a third floppy wrapped in 1mm-thick lead foil. That floppy got through OK. Another is of a customer who, although a part of the defense department, had no Internet access, or even have a modem—and this was after almost everybody had gotten on the Internet, so I was surprised that they were even allowed to telephone out, but I sent them a floppy with software on it and they were happy with that.

FreeDOS has adopted Freemacs as its standard text editor, so it still has a user base. I only rarely do any MS-DOS work, and when I do, I'm happy with the state of Freemacs, so it's now frozen in time. There were never any commercial users, so apart from selling copies on floppies, Freemacs managed only to buy me my own computer for home.

Packet Drivers

Crynwr Software came into its own with packet drivers. A packet driver allowed the sharing of an Ethernet card between two protocol stacks. For about a year, the only possible way to get Novell network clients on the Internet was by using a packet driver. Also, a packet driver would hide the differences among Ethernet cards.

Unlike video boards, which are at least compatible at the VGA level, Ethernet boards have never been compatible.

Back before packet drivers existed, there were network clients and servers—largely Novell NetWare. The manufacturer-written network driver was linked to Novell's code in a single executable. The resultant program had no API for an external program to send or receive an Ethernet packet, which was very bad for any competition to NetWare. Maybe Novell planned it that way, but I doubt the company was that Machiavellian.

Anybody wanting to send packets other than NetWare's had a problem.

The 3Com 3C501 was the market leader, but it was a very insufficient card. It had one buffer shared between transmit and receive, so a packet could be lost if it arrived when the buffer had not been emptied, cleaned, and turned around. However, everybody had drivers for it. Novell, in an attempt to improve the state of the art, took National's 8390 demo board and put it into production as the NE1000 (and later as the NE2000). This board had sufficient memory with separate transmit and receive buffers.

Just about then, other Ethernet controllers were coming on the market. People were using the Intel 82586, the AMD LANCE, and the National 8390 (in non-NE2000-compatible ways). Only NetWare included a device driver development solution. It had a driver development kit (DDK), and a certification house (Novell Labs).

Other protocol stack vendors were doing the same thing—producing drivers linked into their own products. No vendor had a driver that could be shared, however. While Novell and Microsoft pondered, little FTP Software (now owned by NetManage) had the same problem as everyone else: too much hardware and too few drivers. It came up with its own specification for a shared Ethernet driver and, unlike other vendors, published it as an open standard.

I was working for Clarkson University at the time, and we had the same problem as everyone else: how to support multiple pieces of software and hardware at the same time. I was using Phil Karn (KA9Q)'s NOS, and he had packet driver support. So, I wrote packet drivers for the two Ethernet adapters in use at Clarkson (the 3c501 and Racal-Interlan NI5210) and published them as open source software.

A number of fellow Internet users contributed drivers, and before long, we had covered a considerable portion of the industry. This led to more support from TCP/IP vendors, and a group at Brigham Young University wrote a NetWare driver that could use a packet driver. We really got the ball rolling then, because anyone with a NetWare network could put it on the Internet.

There were some holdouts, notably Microsoft and Novell, both of whom started promoting their own standards: NDIS and ODI, respectively. The NDIS document was published from the start, but there were no sample drivers, and no base of code from which to build. ODI documentation was available only with an expensive DDK purchase. A packet driver distinguishes itself by coming with source code, by having a simple, approachable API, and by being small in size. The typical driver was 5K of executable, compared to 20K for ODI, and 40K for NDIS.

By the mid-1991, I realized there was money to be made providing packet driver programming and certification services—the latter for drivers not written by Crynwr. So I left Clarkson and, after a five-month placeholder stint at a local PBX company, I started Crynwr Software. Up until 1998, Crynwr's main source of income was from packet drivers.

Packet Driver Income

Most likely, everybody has heard that the way to profit from open source software is to sell services. That's true, but there are many different types of services. I'll list some of them in the following paragraphs.

The first, and most profitable, is contract programming. Various people need packet drivers written, or features added, or bugs fixed. I contract with them to fix it, either for a fixed price (if I understand the problem), or at an hourly rate (if discovery is needed). Buyers don't like cost uncertainty—they really like to know what something will cost up front—but whenever you bid a fixed price, you are taking on the risk that the project will be much harder than you thought.

I have actually been successful doing what appears, at first sight, to be the worst of both worlds: charging per hour with a minimum and maximum price. If you set the minimum and maximum to reasonably sane values, the risk is reasonably shared between the two parties.

Business Tutorial

Here's a quick tutorial, which I wish I had had when I started, on how people do business. First, customers expect to do business first, and pay you for it later. The customer accomplishes this by issuing a private currency called a purchase order (PO), with a face value and a serial number called the "PO number." Purchase orders owed to you are Accounts Receivable. Purchase orders you have issued and will pay are called Accounts Payable. I call a PO a currency because you can get a loan against good receivables, and you can sell bad receivables (customers who don't pay, or pay very late) at a discount.

Never do work on a promise to pay you. If someone is really going to pay you, they'll be able to cut you a PO. People change jobs and companies go into bankruptcy. If you have a PO number, that's as good as gold, because a company's ability to purchase things depends on its reputation for paying on terms. If it loses that ability, nobody will accept a PO from the company, and then it has to pay cash for everything. Get that PO!

Some companies have intricate purchasing systems, where you have to be a qualified vendor, you have to sign a W-9, and you have to sign a nondisclosure agreement just to work with them. Other companies just whip out the credit card, and you're good to go. For any company larger than 50 people, though, you'll be dealing with a buyer. Most buyers are used to purchasing software as a product.

Although they are starting to understand that software can be a service, you might still might run into a confused buyer, because sometimes they're told to "buy this software" and they don't understand that they're purchasing a CD and a support contract. Take the time to educate them about the difference, and you'll have an easier time working with them.

I've also sold proprietary packet drivers, although this was a special circumstance (and one that was very profitable to me). I had a customer who wanted a new packet driver, but who didn't want to pay the entire price for it. He wanted to pay only half. He persuaded the vendor (SMC Semiconductors, now SMSC) to pay the other half, since the packet driver would be useful for all the vendor's customers. That seemed fair to me. I had his purchase order and SMSC's promise. Unfortunately, he paid up and SMSC didn't, so I had a packet driver that the vendor hadn't paid for. If I made it freely copyable, no vendor would ever bother to pay me, so I decided to license it to SMSC's customers until SMSC paid me. The company never paid, so I sold it with a clear conscience.

I've also dual-licensed packet drivers. A vendor that was going to embed an Ethernet chip into its product and use an embedded processor wanted to freely copy code from the packet driver without taking a chance that its driver would become a derived work under the provisions of the GPL. So the vendor purchased a copy of the code from me, licensed for any use except resale.

I've also sold compatibility certification. Digital Equipment Corporation had written its own proprietary packet drivers. DEC wanted me to certify that the company was compatible with the open source packet drivers. I had written a test program that would exercise the edges of a packet driver to try to break it. If that program ran, it meant DEC had made no stupid mistakes reading the specification. I also ran a stress test for several days; if that didn't run into problems, it meant DEC had made no stupid coding mistakes.

I've also done pure consulting. Contracting is different from consulting. A contractor is someone who sells his work output, and a consultant is someone who sells his ideas. A customer wanted me to describe how my packet driver worked on their hardware, so they sent an engineer to my site for a day to get a debriefing. He took my family out to lunch, and I got paid handsomely for the day—not as much as I would have been paid to write the improvements myself, but you can't make all the money all the time.

Qmail

Qmail[2] is an MTA written by Daniel J. Bernstein, a University of Chicago professor. He needed a fast MTA to run his mailing lists. While I was working on Freemacs and Packet Drivers, I was also running my own mailing lists.

I experienced the same problems he did, so when he published qmail, I was on it right away. First, I ran it on a test machine, because I hate to lose email. Later, I ran it on my email hub after I learned to trust it. Slowly, the qmail community grew.

Working with qmail has been a different experience from Freemacs and Packet Drivers, as I did not write the qmail code. It's just as well, since that gives me something different to write about. It's a truism that you cannot sell something you don't own. A number of the techniques that I used for Packet Drivers do not work for qmail, as I don't own the copyright on it. Nonetheless, I have done quite well with qmail.

Open source software serves to promote the author. By writing quality software (code and documentation), the author shows everyone the quality of his work. The software pushes his reputation out into the world. But what if you haven't written the software? I have found the best technique is to spend time reading user forums and answering questions. You can advance your reputation in this manner.

There are other ways to establish your expertise with a particular program. You can contribute improvements to the code or documentation. You can write your own code that enhances the software, but that otherwise stands alone. You can also write extra documentation or maintain a web site about the software.

I did all these things for qmail. Dr. Bernstein was not interested in registering the qmail.org domain, so I did it for him and maintained the web site, and I wrote a POP3 daemon for qmail and gave it back to him. I answered questions on the qmail mailing list. I wrote add-on packages and patches that people have found useful.

Using all these techniques, I found paying qmail employment. Most often this came from people who needed qmail installed on their machines and had extra requirements that needed custom coding. Sometimes the customer wanted on-site qmail training—which I have provided in Stockholm, Mumbai, London, New York City, Oslo, and Istanbul. All these trips were, of course, paid for by my customers, who also paid me.

Open Source Economics

It was my reputation, or "brand name" if you wish, that got me involved in the Open Source Initiative (OSI). I had been running the Free Software Business (FSB) mailing list since 1993, and had some success and reputation. When I heard about the Open Source name, I immediately adopted it in describing my software. It's so much easier to explain to customers why they should pay for software when it isn't "Free Software." Sometime after that, I heard that Eric Raymond was seeking to create an organization to promote OSI. I had been corresponding with Eric about open source, and we had discussed it on the FSB mailing list, so I volunteered to be on the board of OSI.

I started the FSB mailing list so I could be more aware: I wanted to know what other people were doing to make money from open source. It seems that adding value to things others created is a revolutionary way to make money; even Shakespeare might agree, as he routinely "recycled" plots and storylines written by other people.

Certainly in the software business, an FSB is a new thing. With proprietary software, about the only way to add value is to sell the software for a higher price, or bundle products and sell them together for a lower price in toto.

Running an FSB interested me in economics. When you give up a payroll check and start paying yourself, you also have to pay the business's share of Social Security taxes and start paying estimated income taxes quarterly. The government imposes this dead load on businesses. Why do they do this? Who benefits? Who loses? Economics helps you answer these questions.

Think carefully about how you price your services. There is an economic concept called "price differentiation." It means that you charge different parties different prices for slightly different services. If you charge a single price to everyone, and that price is too high, you miss out on helping some people who cannot afford your services. If you charge a single price that is too low, you create value for some people beyond the amount they paid. It's not exactly fair that they should gain a lot more than you. To maximize your gain, sell things to people based on the value they receive rather than the cost to you. For example, everyone has seen software sold for less in a third-world country or to a school.

Of course, pricing is also related to costs. Think about both transaction costs and so-called "sunk costs." Every transaction consumes a small amount of value in the transaction itself. The buyer needs to evaluate whether the cost spent is worth the value received. The seller needs to take the money and provide the value. This cost is not received as value by either the buyer or the seller; it is simply wasted. One way you can sell support to a customer is on a self-renewing yearly support subscription. One month before the subscription expires, you send the customer an invoice. The subscription portion avoids having to bill the customer for each support request, and the self-renewing portion avoids having to ask the customer to renew the support contract.

A sunk cost is one you cannot recover by selling the thing you bought—for example a railroad or a run of fiber optics cable. You can pull up the rails and sell them, but you won't get back anywhere near the cost of building the railroad. Likewise, spending money to create or improve open source software is a sunk cost. Once you've spent that money, you have no way to sell the software (except by exiting the open source system by using a dual license). Just as a railroad needs to recover its sunk cost by selling transportation services, you need to recover your investment in the software by selling related services.

One of the ways to manage costs is by making use of "public goods." A public good is nonrivalrous (meaning that my use doesn't affect your use) and nonexcludable (I can't stop you from using it). Absent copyright or patent protection, information is a public good. Open source is typically copyrighted software, but is licensed under terms that make it effectively a public good. There is currently great debate over how much excludability is necessary to produce the optimal amount of software.

Previously, economics students were taught that public goods were always underproduced, with lighthouses as the canonical example.

Someone dug up the history of lighthouses, only to find that the early ones were built by voluntary organizations. In a similar manner, the Free Software Foundation (FSF) wrote the GNU tool set as a public good. Economists can no longer assume that public goods are underproduced.

People don't particularly care about products. People only buy things and own things for the services those things render to them. People don't want to own a washing machine; they just want clean clothes. Any desire to own a washing machine is secondary to having the clean clothes. The same thing goes for computers, only computers can provide many different services. The same services that someone can get from a software product can also come from open source software and a support contract.

Economists have discovered many principles helpful to the proprietor of an open source business. Nevermind the joke about 10 economists having 11 opinions. This chapter can but touch on the principles. (See the "For Further Reading" section at the end of this chapter for more information.)

Where Do We Go from Here?

I've brought you up to my present life. Well, not quite. I received an inheritance from my mother, which, when invested in the stock market, generates sufficient income that I no longer need to work for a living. I still take interesting jobs as they come up, and I support long-term customers because they've become friends, not just customers. In everything else, I just write open source and distribute it as I wish. My advice to you is to always pay your retirement fund first: put 10% of every project's check into a brokerage account and invest it in an Exchange Traded Fund.

Happy hacking!

For Further Reading

For a basic (and enjoyable) introduction to price theory, read Hidden Order, by David D. Friedman (Collins, 1997). In fact, read anything written by any member of the Friedman dynasty: Milton, Rose, David, or Patri.

For a basic introduction to economics, read Economics in One Lesson, by Henry Hazlitt (Three Rivers Press, 1998).

For an explanation of the proper function of the law, read The Law, by Frederic Bastiat (Foundation for Economic Education, 1987). It's in the public domain, so you can find it on the Web, in print, and as a free audio book.

Notes

↑ Qmail is an all-lowercase name, and will be capitalized here only at the beginning of a sentence.

↑ Qmail is not open source. It's freely copyable, but you can't redistribute modified executables. Although open source MTAs do exist, qmail is close enough to open source that I have insufficient reason to switch.