Toast Driven

← Back to November 24, 2008

Balancing OSS And Commercial Development

Open source has had a tremendous impact on my personal and professional life. Without open source, I would never have landed where I have, nor would I enjoy what I do nearly as much. So it's important to me to give back to open source whenever I can.

However, it's a very real aspect of most programmer's lives that they need to make money. This usually means writing software that someone else pays for. Which brings us to an interesting/delicate balancing act: how to balance open source contributions with commercial development?

There are a couple ways to look at the situation:

  • Open source at the core of the business
  • Open source contributions as a donation
  • Open source contributions as a personal effort

Core Of The Business

In the first model, you basically have to build the business around a open source core. Money is usually made either by building a commercial product on top of this foundation or by selling support for an entirely open source product.

Pros - This is one of the best ways to contribute, due to both the quantity and quality of the code. Because it's at the core of the business, if the business is doing well, chances are you've got a relatively solid codebase. Additionally, if it's what you work on all day every day, you find bugs faster and have more overall code.

Cons - You basically have to build your product from the ground up like this. Additionally, you have to ensure that what you sell is worth it and/or not easily reproduced by others who can build on your open source contributions. Otherwise, sustainable business will be hard to find.


This involves making periodic contributions as part of an effort to give back though perhaps not a major codebase. Money is made off the product/service and only portions of the code written are contributed.

Pros - This is beneficial because the core business is never at risk. However, you still contribute back code where possible/desired to be a good community member.

Cons - Quantity and quality of code are diminished over the amount resulting from the core business. Additionally, there may be lots of repeated effort when trying to distribute many different things in a piecemeal fashion.

Personal Effort

This is where most open source traditionally came from, and where most of my contributions have been in the past. The business involved gives up none of it's proprietary code, but the employee is free to leverage their own knowledge to implement their own ideas (or reimplement things encountered in the business).

Pros - The business does not actually pay any money for the contributions, maintaining the highest profit margin, and the core business is never in jeopardy.

Cons - Quality/quantity are entirely dependent on available free time and motivation. This places most of the burden on the employee. It also fails to establish the business (which is presumably using at least some open source) as a good community member. It can also lead to tensions in the workplace if the code open sourced follows the company IP too closely.

My personal preference lies in the Donation model, simply because it feels right when doing it without having to worry about what it will do to the business. Your mileage may vary and what kinds of people comprise the company (management vs. engineering vs. whatever) can make all the difference. The important thing is to find the balance that works for you.

Toast Driven