Alas, open source by itself is not a business model. Very few people get rich just by coding for free all day.
But I've spent a lot of time in the open source trenches over the years, and I'd like to share a few thoughts on solid, dollars-and-cents ways that open source does pay off. For the people doing the coding, that is. I'm sure you already know how it pays off for the legions of developers who have never contributed a line of code back to, let's say, WordPress.
1. Open sourcing your code improves quality control.
Those people who only send you bug reports may seem a bit selfish (and they often word their emails in a less than considerate way). But they are performing a valuable function for free. Code rots: left untested, that feature you haven't used in a while will probably break over time. If you don't have enough clients out there using it, or they are not technically skilled enough to complain effectively, you'll never know. Bug reports are one of the most valuable benefits of open sourcing projects like Apostrophe
: we get more feedback than our clients alone can provide.
Open source also improves quality control through simple embarrassment: who wants other programmers pawing over bad code?
2. Open source makes it practical to build what you need in-house but can't quite afford to support on your own.
In other words, your open source projects should support the business model you already have. If we didn't have Apostrophe, we'd still build websites for clients. They just wouldn't be as awesome. And that is directly reflected in the quality and quantity of work we are given the opportunity to do.
Other developers out there in the world benefit too, because they too can build better websites. That does make them stronger competitors. But heading up an open source project that others also use and contribute to ensures that we are among the first-tier choices for any project and, quite naturally, the first to know about the latest features.
3. Open source answers your client's concerns about vendor lock-in.
If you don't want to build yet another Drupal or WordPress site, you had better be prepared to answer your client's legitimate worries about your proprietary software that no one else can support or understand. The best way to do that is to make your software non-proprietary. Create a community around your work. Point with pride to the competitors you helped create as examples of your software's broad base of support.
4. Open source is a crystal ball.
You've met the needs of your current clients. What about your future clients? You won't know until you talk to them. You can try to extrapolate but your knowledge is limited. One great way to learn what your future clients will want is to listen to what your open source community wants.
But there's a catch:
maintain your point of view and remember your own business model. Make sure you sort out the purely technical "gee whiz" feature requests from those that are driven by a real project and a real need. The latter are often hints of what your next customer will need. At the same time, you have a right to limit the scope of the project and avoid bloating it with things you don't want— although this may also limit the number of people who are prepared to contribute.
5. Over the long term, others will contribute significant code.
This part can take a long time to happen. When I wrote the gd library, I began by borrowing code for encoding and decoding GIF images, but there were no other big contributions from third parties over the first year or two. Then, as the library gained a wider community of users, I received major contributions of code I would likely never have written on my own. Code to render truetype fonts on the fly, for instance.
6. Help people help you.
Maybe people won't donate, or sponsor, or purchase support contracts. Then again, maybe they will... if you help them get to the finish line. In my pre-P'unk days I sold quite a few CGIC
commercial licenses, because I let people know that was an option, and they let their employers know it was appropriate. Selling support is more difficult because open source users are savvy contributors to community mailing lists and sites like Stack Overflow. But you may have some success with those whose employers insist on purchasing a support contract.
7. Reputation is everything.
Asking for monetary contributions to an open source project rarely sustains a business on its own. "Bounties" to implement specific features are a helpful strategy but generally still not sufficient. Being able to say that you created the system in which others claim to have expertise is priceless.
The first time someone insists on buying you a beer because you wrote the XYZ library, it may not seem important. But the first time that leads to a paying gig, you'll see the light.