You might think that we would always be in favor of open sourcing code from inside your organization. But sometimes releasing code under an open source license can end up causing more harm than good.
Differentiating code
Many times, releasing code as open source is the right solution. As we pointed out in the article Creating differentiated value when using open source, probably 80% - or more! - of the code in your organization is non-differentiating. Frequently the highest value you can get out of that code will result from getting others involved and using your code. But in that article, we identified that 20% of your code is probably differentiating - it creates unique value for your organization. Unless you are careful, differentiating code might not be a good candidate for open source release.
Most people do not understand the underlying economics of open source or how to use them to drive business ROI. As a result, many people, even in "open source businesses," are uncertain about when and why to release code. Therefore, if your business does not have a clear path to improved profitability as a result of open sourcing an internal project, your executive leadership may end up seeing open source as a cost center instead of a way to increase profits and reduce costs. This can lead to a reluctance to use open source licensing even when it is the best strategic move.
Tactics vs strategy
For businesses, the strategy is the action plan that takes you where you want to go. Tactics are the individual steps and actions that will get you there. Usually business strategies are focused on gaining mindshare, marketshare, or revenue. In contrast, the proper way to think about open source is as a tactic, not as a strategy or an end in itself.
The best way to understand this is to think about a product. Companies don't have "release a product" as a strategy. The strategy is to gain revenue by pulling in new users. The release of the product itself is just one step in that process. The particular channel through which the product is released - direct to consumer, wholesale, through partners - is a tactic designed to accomplish the strategy. Also, there are many other steps after release, such as marketing, updates, and support, that will continue past the release.
Releasing an open source project is releasing a product. It is just a product with a price of $0.00 and a pre-determined channel. These two constraints - price and channel - make open sourcing code a powerful but limited tool.
Why companies release code as open source
Usually there are just a few reasons why companies will release internal projects as open source: 1) to develop and retain internal talent, 2) to drive commoditization of some type of technology, and 3) to encourage wide third-party distribution of your code.
If your goal is to develop and retain internal talent, then your business purposes are all internal. The code eligible for release has a value. If the increased morale and developer productivity resulting from the release has more value than the code itself, then the decision is straightforward.
Reasons 2 and 3 - commoditization and distribution - are trickier because the expected return is due to other people's actions. Therefore, before your company will get any return at all on its open source investment, people need to be incentivized to try your code. Even though the price is zero, there are still costs for people to try out your code. Adopting your code has to present an advantage that outweighs the cost and time needed to evaluate and switch to using your project. Usually this is some unique capability that was not available using existing tools. That is your project's unique strength - its differentiator.
Once it is clear why people will want to try out your project, then there needs to be a clear route between people using the project and increasing business revenue. For example, it should be easy to upgrade to a support contract, or it should be easy to buy or rent hardware that is empowered using the code. The fewer steps there are between using the code and paying your company money, the more successful your project will appear to your executive leadership.
It may seem somewhat mercenary to insist that just about every open source release by a business be directly tied to a revenue gain or a cost reduction. However, businesses have different motivations and incentives than individuals. Accordingly, so do business leaders. Unless the business motivations are correctly accounted for, it is going to be hard to succeed in business with open source.