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.