How To Become An Open-Source Contractor

By Evan Miller

August 12, 2008

I get emails from people I've never met, asking if they can pay me money to improve some of my favorite open-source software. That's right. I get money. I get to do something I enjoy. I get good software. And I get to share it with anybody I please. It's one of the greatest economic arrangements in the world, up there with being landed gentry, a corrupt government official, or Dave Barry.

This essay is about how you, too, can get paid to write great open-source software. If you're not a software developer, you should probably spend the next few minutes of your leisure time on a web page other than this one. I recommend The Really Big Button That Doesn't Do Anything.

Now, when I talk about being paid to hack on open-source projects, I'm not talking about sucking the big scaly teat of the Mozilla Foundation. That would just be like having any other job, except there's no Sally Shareholder holding Mindy Management's tookus over the teakettle. Nor am I talking about hiding out in the "community" wing of the Heavily Underfunded Projects Division of, say, a Sun Microsystems or an Apple Computer. I mean waking up, going to the computer, and banging out some code before breakfast. I mean turning down projects that don't sound like fun. I mean getting paid in proportion to output. By another name: contract work.

I didn't really set out with the goal of being an open-source contractor. It just sort of happened, like sex with a much-older neighbor. If I wanted to be a good contractor, a full-time contractor, there's probably a lot more I could do. I'll get to that. What follows is a mix of tested and untested advice. I think all of it is pretty good. The road ain't easy and it ain't for everyone.

First, you need to understand some economics. It's hard to make money from open-source software. Some companies have tried giving away some software and then selling "support and services," but that business plan has proven as profitable as giving away VCRs and selling the Owner's Manuals.

If you write proprietary software, you can sell thousands of copies. If you write open-source software, you can sell the first copy, but you're forced to give away all the subsequent copies. So as an open-source contractor, you will not be writing software for Connie Consumer. No Pidgin plugins, no Gnome widgets, no iPod synchronizer or whatever. You will be writing software for Seymour CTO: a single company that stands to save serious money by your efforts.

It's a peculiar set of circumstances that will allow you to write open-source software for a company. The company needs to have a culture of fixing problems themselves. This usually means fixing problems at any hour, day or night. If software bugs can "wait till next week," then a company would probably be better of buying software from a vendor rather than developing software in-house or using an open-source solution. In general, proprietary software can be developed with greater resources.

The need for quick fixes I think explains why open-source software has thrived on web servers. Always-on web companies don't have to rely on another company to fix their problems. Many Internet companies bring in thousands of dollars an hour, and every minute the site is broken means Stanley Stakeholder's net worth inches downward. An Internet company simply can't afford to wait on another company to wake up and diagnose the problem.

A company reliant on open-source software for revenue will be large enough to have developers on hand (at the very least to fix problems), but not so large that they want to develop everything themselves. The company that will hire an open-source contractor has at least one but probably no more than a few dozen software engineers.

But hiring you, the contractor, is a risk. You might not deliver on time, your software might crash, and you might flee the country. In general, a company would much prefer an employee did the work than a contractor, because an employee has more to lose if he does a bad job. So why would a firm with software engineers on the payroll hire another software engineer on a contract basis? Because that's all they can afford.

If you want to be a successful contractor, you have to make yourself a scarce resource. You need to be able to do something better than almost all of the software engineers at a particular firm. You want engineering managers to think, "It'd be great if we could hire this guy, but at the very least let's try to get some of his time."

The trick, of course, is to become an expert on something. Preferably a world-expert. This doesn't mean you have to know something better than anyone in the world; it just means you can demonstrate your expertise as well as anyone else in the same domain. You don't need to prove you're the best; you just want no one else to have proven that they're the best.

I became an expert by accident. Gather round, beardless youth, I shall tell you a tale. Once, long ago (2006), I worked for A Large Internet Retailer. My coworkers often talked about things I didn't understand—"non-blocking sockets" and "duping file descriptors" and other concepts that sounded vaguely like fighting moves. In effort to decode this strange tongue, I did some google searches and found out my colleagues were discussing, not Marquess of Queensbury rules, or Masonic arcana, but the closely related subject of UNIX network programming. I set out to learn more, primarily so I'd fit in. I read a book on UNIX and a book on networking, and tinkered on my machine at home. But I found it hard to write even rudimentary server programs. They would work, mostly, but have bugs when talking with certain web browsers. So I decided I'd let someone else's program deal with the client bugs.

At the time, I happened to be playing with Nginx, a web server with a funny name. I decided I would figure out how to write my toy programs as extensions to Nginx rather than as standalone programs. Unfortunately, I couldn't find any documents on the web about how to write Nginx extensions, so I poked around the code and jotted down observations in a notebook. After a several evenings and couple Saturdays of this, I had a pretty clear idea of how to write an extension. Figuring out the details was much harder than I initially expected; the Nginx source code, being of Russian origin, had very few comments in English, and very many variables having one- or two-character names. Or slightly longer but equally obscure variable names such as "nldcf".

My first Nginx extension, culminating weeks of effort, was around 100 lines of code. Most of the effort went into my notes, of which I had accumulated several pages. Because I didn't have anything better to do one afternoon, I typed up my notes and thought, what the hell, I'll put them online. Mind you at this time I didn't have a home page, so I simply sent to the Nginx mailing list a link to "Emiller's Balls Out Guide to Nginx Module Development (DRAFT)."

My guide was an instant hit in Russia—I was tickled to see the phrase "Emiller's Balls Out Guide" surrounded by Cyrillic text on several Russian tech sites—and in the English-speaking world, I started fielding a trickle of questions about Nginx internals. Apparently no one this side of Petersburg had written an Nginx module before, and all of the sudden I was an expert in this limited domain.

And apparently people needed an expert. I got an email a few days after publishing my Guide asking if I wanted to write an Nginx module for an Internet start-up. They had plenty of developers, the CTO explained; but rather than have one of them spend two weeks learning how to write an Nginx module using my guide, it would be more economical to pay me—you know, an expert—to write it. And they wanted the resulting work to be open-source. At the time I really wanted a MacBook Pro, so I named a price equal to a MacBook Pro plus income tax, and they agreed.

If you're a developer who has never done contract work, and never been paid expert wages, you are in for a ride. I worked harder on that first paid module probably than anything I've worked on in my life. It felt liberating to know the faster I worked, the sooner I got paid; it felt good, yes—but greedy. Liberating isn't quite the right word; it felt motivating, energizing, inebriating; it hit the same spot as a double shot of love and coke. It was like my brain opened up a brand-new Reward Center twice as big as the old one, with triple the parking. It felt good. Good as gold. Good as greed. Good as God. I was Hernan Cortes, and C was my sword.

I delivered the final product in four days instead of four weeks, and had to spend a couple of days in Code Detox (i.e., watching lots of House). When I went to pick up my check, the CTO said the company liked what I did so much they were giving me an extra 500 bucks just to say thanks.

I was getting busier with other projects at the time, and I declined their offer to contract more work. Since that first job, I've taken on gigs here and there—just enough to keep my skills sharp—but as they say, there's nothing like your first hit.

Anyway, enough of this ancient history. I'll try to distill my experience into a finite list of—O wisdom, what shall be thy verbal chains?—original aphorisms, with commentary.

In the chef's kitchen, the knife that can cut anything, cuts nothing.

A good teacher is better than a great student.

Bigger locks keep smaller secrets.

More seek a charlatan at his office than a doctor at his home.

Today a stitch, tomorrow a suit.

In the chef's kitchen, the knife that cuts anything, cuts nothing. To be a contractor, you have to specialize. "Smart and gets things done" ain't enough. You need to do something better than most people at the company that's hiring you. Pick a system, program, or set of libraries to specialize in. Pick something that interests you. But also pick something which small to medium-sized companies rely on. Write patches, features, applications, and plugins until you reckon you're as good at it as anybody out there. Then prove it.

A good teacher is better than a great student. To become known as an "expert," write about what you know about. Explain things in tutorials. Participate in mailing lists. Present at conferences. But remember...

Bigger locks keep smaller secrets. Don't give away all your knowledge. It's OK to keep some voodoo up your sleeve. It's even better to mention offhand that you're leaving out some "details".

More seek a charlatan at his office than a doctor at his home. Make a presence for yourself. Make a website explaining what you do. People aren't going to find you by telepathy.

Today a stitch, tomorrow a suit. Companies hiring you might have a few projects in mind, and they'll start with the smallest one just to test the waters. If it's a small job, take any price you can get. If you impress them, you'll be offered a much more lucrative job next.

And, finally, some non-aphoristic advice:

Look professional. Give out business cards at conferences. Make an invoice template. State your rates with confidence. Deliver ahead of schedule. Write tests and documentation. Code exactly what your client wants, not what you think the world wants. Spell properly.

The world has room for open-source independent contractors. I don't know how much room. And I don't know for how long. But now you know how I did it.

Well, except for one or two details...

Back to Evan Miller's Home Page