Starting a Business as an Open Source Consultant

Software developers who want to make a living in open source often consider becoming independent consultants. This advice from two successful developers may help you get started.

After a long absence, two programmer friends met at a party. One proudly declared, "I've gone into business for myself as a computer consultant!" The other looked at his business card, with the ink barely dry on "John Smith & Associates." And asked, "When did you get laid off?"

I first heard that joke (it's a joke?) in the 1980s, when I became active in CompuServe's Computer Consultant Forum. It's equally true today. It takes more than a business card and a website to make it as a consultant — a real consultant, not someone scrambling to generate income while looking for a "real job" — and few of those rules have changed. But many of the basics bear repeating (I wish I had a dollar for every time I've answered, "Should I charge clients for travel time?"), especially when the economy forces us to re-evaluate what we want to do with our lives.

That's one reason that last week's Open Source Bridge conference, held in Portland Oregon, had more than one session about the business of open source. Brian Jamison, who founded Open Sourcery in 2004 (now at 24 people), spoke about "How to earn an open source living without taking on investors or selling your soul," and Nate Aune shared "How to build a successful open source software consulting company" based on his experiences with Jazkarta, the Boston-area company he founded in 2004, which now employs three full time staff and ten subcontractors.

They reiterated many of the same points, most of which had less to do with running an open source company than with Computer Consulting 101 rules. That makes perfect sense, since your area of specialization is irrelevant if you can't market or pay your bills on time. So I could write a whole blog post about "the 19 things you ought to know before you hang out your consulting shingle" (and with any provocation, I shall), such as embracing crisis, why not to listen to your friends and family, and finding a way to differentiate your business from others'.

But I want to focus on the points these guys made about making a living in open source. Or you'll get cranky, since that's what I promised in the title.

One unique attribute of operating an open source business, for instance, is that consultants are often asked by potential customers to defend open source choices. "Know the FUD [fear, uncertainty, and doubt]. Love the FUD," advises Jamison, who says these people parrot inaccuracies they hear from other vendors. But don't argue technical merits; that's a useless effort. Instead, he suggests, "Ask them to ask the very same question of the closed question that they're considering." That is, your potential customer might ask, "How can you use an open source content management system [CMS]; don't you worry about security?" probably because one of your competitors waved that as a red flag. Suggest to the customer that she ask the other vendor, "How do you know that the products you're using are secure, when nobody else but the vendor is looking at it?" Jamison says. "Usually open source wins, whaddya know. ... [This method] just puts the issue to bed."

That doesn't mean you should ignore what's happening in proprietary software circles. "It will behoove you to interact with the Kool-Aid drinking Microsofties," says Jamison. First, because "Sometimes their technology kicks ass." And also because you should understand where their pain points and frustrations are. You can use those competitor frustrations in your own marketing; "Drop them in a conversation," Jamison adds.

Traditionally, advice about "how to market" emphasizes networking and word-of-mouth referrals. That is true for open source developers too, of course, because recommendations from happy customers are always the best way to get new ones. However, there are a few marketing resources that are peculiar to the open source community, or at least emphasized in open source circles: the community itself. Because open source communities encourage conversation and collaboration, your presence as an authoritative, helpful, and knowledgeable resource can drive business your way.

Aune recommends that you give talks for free, which can generate interest in what you're doing. For example, he's given several talks on "How to use Plone for nonprofits" which led to plenty of work. But, he points out, the leads don't necessarily come from people at the talk or from those to whom you handed out business cards. "What you spend time on is what will come back to you," he says. That "get business by sharing your knowledge" premise isn't unique to open source — it's how I made the transition from computer consultant to writer — but (my observation here) it's even more meaningful for a start-up open source consultant who has to demonstrate expertise. "If you are an entrepreneur and do not have a blog... do it immediately," says Aune.

It's important to be a well-behaved open source citizen, to be part of the larger ecosystem even when you compete with other open source developers who also work with the same technologies. "We work together but we each have to do our part to keep the community healthy and alive," stresses Aune. So write documentation, serve on the board for your project, organize user groups, contribute code.

Aune also suggests that, as soon as you can afford it, you should sponsor a sprint or other community activity — and get your company logo on the event program. "I've been to about 20 sprints. It's one of the most interesting aspects of being part of an open source community," he says. Other advantages: it's a great way to recruit contractors and find the right people to hire, since you see how people work in an intense coding session, over the course of a few days, and you see how they interact with others. More than 70% of those he has recruited are people who worked at a sprint." Who knows, at the next sprint, he may be looking for you.

But you don't have to go it wholly alone. In Portland, Oregon, for example, there's a organization called Portland Open Source Software Entrepreneurs, to which Jamison belongs. If there's nothing like it in your area, start one. But it doesn't have to be specific to open source. Aune joined the Independent Computer Consultants Association when he first got started, and reports that the lessons he learned from other, more experienced consultants made a huge difference.

It appears to be a mark of distinction for both Jamison and Aune that, in Jamison's words, "We drink our own champagne." That is, both companies built their infrastructure on open source, and they work hard to use only open source software. There are a few exceptions; Aune, for example, runs QuickBooks because that's what his accountant insists upon. Another benefit to using open source business applications, of course, is that they're free—and every start-up is strapped for cash.

Speaking of cash... "Open source people can be uncomfortable about 'profit,'" says Jamison, even when they're running a business. But, he explains, what we mean to say is that greed—not profit—is the antithesis of the open source philosophy. "Profit is good; greed is bad." It's okay to be cheap, he stressed; in fact, it's probably necessary. In Jamison's view, the nicer the office, the less chance a startup has for success. "Folding tables are a good sign," he adds, suggesting that any new consulting business stay in its "abysmal" offices until it's ready to burst out the doors. "That cheapness is now built into our company, and if you have dealt with us you know," says Jamison.

Every new consultant is offered opportunities that should be turned down, Jamison points out. It might be because that early consulting gig would lead to specialization you don't care for; if you write one iPhone app, you'll forever be branded as the iPhone App Guy. You have to learn to Say No, no matter how hard it is to do so, Jamison says. Say No to offers to work for sweat equity, to scope creep from customers, to lowering your price. And in open source terms: "We have to say No to working with Microsoft technology," he adds. "We didn't start this company to work with frickin' Microsoft technology."

These suggestions are in addition to the basics of Consulting 101, of course, and there's much to be learned in that domain alone. But I feel as though Aune's and Jamison's suggestions offer useful advice for any open source developer who's wondering what it'd be like to break out and start her own business. Do you have any additional pointers to share?