To open source or not? or to do both? Open source as market segmentation tool.

Several years ago, I found myself confronted with the decision of whether to open source or not the software of a company I co-founded. While I could find considerable literature on the strategic benefits of open-source freeware as an enabler modern version of the razor and blade strategy (giveaway the client or development tool or razor, sell the server or the runtime or the blades), our software was not lending itself very well to such a separation.

My question was rather: if we have to choose between open sourcing blades and razors or nothing, what model would maximize our revenues, given our target market?

By elaborating on the simple notion of “why giveaway something you can charge for”, I developed the chart below to help me discuss the decision with my colleagues. The idea is to not view open source as an all or nothing strategy, but rather as a marketing technique to segment your market and maximize revenue, except that in the open source case, the revenue is mostly intangible.

Diagram of different segment of customers depending on their budget size and perceived value of the software

According to traditional marketing segmentation strategies, customers with large budgets and who have a high perceived value of our software should be charged for it fully and get all the features and rights; and customers with small budgets and who have a lower perceived value of our software should be charged less for a slimmed-down version of the software.

What’s new here is the category of users who don’t have large budgets themselves (the boss of their boss may have as it is the case of developers) but who see a lot of value in the software. These guys may not be able to sign a check, but they are able to bring more eyeballs to fix bugs, post feature requirements that are common to all users whether they have a checkbook or not, or simply spread the word about your software at the fraction of the cost and in a much better way than any PR firm. That’s not direct revenue, but certainly contribute to higher margins by reducing the costs of goods sold.

In most cases, the distribution of target customers (as it was the case for us) is such that a single model (commercial or open source) will dominate:

Diagrams representing 3 common cases of the distribution of customers according to their budget size and perceived value of the software offered

But if the distribution of customer types is such that a single model does not dominate, this model can actually be implemented using dual licensing, where one category of customers is segmented from another and charged differently, by offering both a commercial license and an open-source, usually GPL-like license. What’s even better is that customers are let to choose which category they belong to (actually their lawyers tell them).

Designing a successful Web API

Designing the most widely adopted Web API for a particular functional domain does not merely take to offer the best and most specialized functionality at the best price, as reading Adam Smith would suggest.

It takes two additional things:

  1. reducing the cognitive load on the developer using the Web API, and
  2. reducing his risks of using the Web API.

Reducing the cognitive load includes:

  • Making it easy to find on search engines
  • Not requiring registration for an API key to get access to a version of the API that is not production grade (for instance,  a version that is much slower than the production version)
  • Providing multiple representations (XML, XHTML, JSON, plain text, binary, etc.) for messages and multiple language bindings for the most popular languages in the target developer community
  • Good documentation, including a step-by-step tutorial
  • Examples with source code
  • On-line test tools that allow developers to test the functionality prior to coding
  • Building upon what target developers already know. Depending on the target developer community, this may mean starting with a REST/WOA API or a SOAP/SOA API.
  • Building upon what API users have already learnt so far about the API: learning one functionality should make the next one easier to learn. This includes using precise semantics and re-using them consistently, defining and sticking to naming and message structure conventions.
  • A variety of one-to-many medias (wiki, archived mailing lists, chat channels, etc.) for user-generated support and documentation.

Reducing the risks involves:

  • Being very clear upfront about what the API does and does not and how it compares with others (to reduce the perceived risk that the developer will spend time on something only to discover down the road that it does not address his requirements).
  • Ensuring the highest quality, up-time, availability and performance for the production version, and providing evidence of your commitment to these goals by using long betas (1-2 years) for new versions.
  • Ensuring backward-compatibility: code written for the 1.0 should still work when the 3.0 version of the API is out. This means that your application should support 1.0 to 3.0 concurrently until no one uses 1.0 any more, and that versions should be explicit in URLs (ex. http://mycompany.com/webapi/1.0/…).
  • Providing evidence that the Web API will be around for some time, because it is backed by a sound business model that can sustain its growth, maintenance and developments.