The High Cost of Open Source

In the past 3 weeks, I have been approached by three separate companies seeking advice regarding how to implement an open source strategy for their products. In each case, I have asked them a few simple questions:

What problem are you trying to solve for your customers by giving them access to the source code?

How much money are you willing to spend to create a broad community of development around your product?

Mostly I am receiving blank stares as the answer to my questions. For the uninitiated, open source seems to be a good way to make more noise about your product. Unfortunately, in most cases it is just noise, not commerce. In order for commerce to be the key outcome, customers need to be the beneficiary of the change, and the supplier needs to preserve the ability to charge a premium for providing more value. If not managed correctly, the reverse will occur. The ability to charge a premium disappears because customers believe “open source” equates to “free,” and providing the source code creates more problems than it solves.

Let's examine the correct answers to the questions above in order to gain some insight into the real value and cost of an open source product.

What customer problems might be alleviated with access to the source code?

Application Integration – If your customers are having difficulty integrating your application with other key applications because of weak APIs, and this difficulty is costing you lots of unbillable time in customer service, perhaps open source would help the customer (or their contractors) with integration while alleviating some of your customer service expense.

OEM Trepidation – If you are trying to convince solution providers to include your technology as part of their offering, a license that relieves their worry regarding future disputes that might jeopardize product shipments could be a good idea.

Vendor Viability – If your prospective customers are very concerned about the future of your company and your ability to service the technology, an open source license that allows them to become familiar with the technology as they consume it will lower concerns about large scale deployments that are later jeopardized by a failed vendor. Note that code escrow is often not a suitable answer to this problem because of the fear of the unknown (i.e. what awful surprise might I find in the event I need to retrieve the code from escrow).

The primary value of open source for the customer is a reduction in cost and risk. These customer values may or may not result in value for the vendor. Also, there may be some other customer problems that can be solved with open source, but they are not particularly obvious to me.

What are the costs for creating and supporting a good open source project?

Architecture for Collaboration – Software packaging and systems for collaboration become important if third parties are to become interested in participating in your project. The developers on your payroll will tolerate some packaging and system inefficiencies (they may indeed be the source of them), but outsiders will not. Count on an extra administrative overhead of 10 – 15% of your typical developer expenses for better code packaging and systems for collaboration.

Code Documentation – If your code was historically developed and maintained by a small cadre of internal developers, it is unlikely that you have spent many cycles documenting the code so that others may use it (after all, others did not use it). Plan on spending 10 – 15% of your core developers time for a year on documentation and clean-up.

Customer Service – In the near term (think 2 – 3 years), your developers are going to be the only experts on your code. If you do not do a good job responding to questions from the newly interested developers, you will never reach critical mass. Plan for at least 20 – 30% of your core developers time to be spent in customer service regarding developer issues.

In short, the near term additional development overhead for your previously proprietary product will likely be in the range of 40 – 60%. For software companies that historically spend about 20% of revenue on application R&D, count on this number rising to about 30% or higher as expenses climb and revenue potentially declines as a result of customers expecting the software to be a bargain now that it is open source (i.e. “free”). Over a period of 3 – 5 years, these numbers could improve significantly if the project catches on with a developer community and additional customers adopt the product because it has become easier to integrate and all issues of vendor viability disappear.

Open sourcing your software product is a very big commitment with an outcome that is uncertain at best. If the problem you are hoping to solve with open source is one of broader market awareness and consumption, you might be better served with a SaaS or a software appliance approach. The difficulty with most software applications is that they are too difficult to setup and maintain relative to the value they provide. By eliminating the barriers to consumption with SaaS or software appliances, you can offer the world free trials to your software that they will actually consider. With software appliances and virtualization, you don't even need to re-architect the product as you do with SaaS. The good news about this approach versus open source is if customers like the technology after trying it, they cannot get it for free, or worse, from a competitor that supports your product (witness Oracle vs. Red Hat).

Open source is no cure all. Consider carefully all alternatives and ramifications before heaving your code onto the Internet. You might not like the result.