Marketing Expert's Corner

This article written in 2005

 

Many a software CEO is proposing moving to an open source model because this can totally change the competitive dynamics of a company.  But it's not a slam dunk:  commercial successes are rare.  CEOs and VCs alike usually underestimate the work involved.

The top line here is that no two commercial open source projects are the same -- they don't  start under the same conditions or have the same objectives.  I hate to sound like a consultant, but after having worked on 10 open sourcing products for Sun Microsystems and startups in Germany, the US, and India, it's pretty clear to me that "the right thing to do" depends on where you start... and where you need to go.

Monetizing Open Source

Since there are over 150,000 open source projects, there is a wide range of approaches to running them.  But for commercial projects -- lead by ISVs, SIs, or hardware OEMs trying to make money through open source -- there is a fairly narrow group of successful* approaches:

  1. Leveraging an existing open source project by embedding the technology in your product or service offering.  The goal here is to achieve the lowest costs and highest quality for a platform technology such as Apache.  This "in-bound" open source work can bring new customers if you can lower your price or leverage the enthusiasm of the open source community (e.g., apache.org) as one of its favorite new add-on products.

  2. Taking your existing product technology and creating an open source project around it.   The strategy is to transition customers to the open source version and to base your product strategy on something that you will no longer strictly control.  The goals here are to increase the popularity of your base product, increase its legitimacy, develop an ecosystem of partners, and create a basis for value-added products or services.  In this case, it's more the size of your customer base than the amount of code that determines your success.  As you'll see below, the impact on your business will be  on the a revenue-side -- don't expect it to lower your costs.

  3. Joining an existing open source project and contributing a major chunk of your Intellectual Property (IP).  The strategy is to preempt others (usually, stronger competitors) and to get new partners investing in the technology base, creating a new commercial ecosystem.  The goals here are similar to strategy #2, but you're hoping to leverage the open source user base.  In this case, it's the value of the IP (e.g., the relevance, quality, and amount of code) and your effectiveness at co-opting the community that determine success.  As before, the business impact is mainly focused on revenue.

  4. Beginning with an existing open source project that you're spearheading, building a commercial open source company on top of it.  This is closest to #3, but the business model can vary quite a bit.  The strategy is to use open source community dynamics to build credibility and technology depth that would otherwise be far out of reach.  This approach often starts with projects outside the US, and uses VC funding to build a US-based marketing organization.

As approach #1 is fairly well understood, I'm going to focus here on the more complex approaches that are intended to enhance revenue.  Here's my three-part model that covers the key aspects of monetizing open source.

1.  Make the Strategy Explicit

Most CEOs take this for granted, having implicitly strategized before even proposing open sourcing a product.  While the strategy is clear in their minds, the rest of the organization requires some explicit details about the strategy and rationales, as these will drive dozens of lower-level decisions and tradeoffs along the way.

Almost always, the goal of open sourcing is to cause a strategic challenge for your competitors, such as:

  • Killing a competitor's revenue stream

  • Increasing the size of your developer and partner base

  • Improving the quality and feature set for a product with near-zero-revenues

  • Increasing trust and goodwill with your customers

  • Creating a popular baseline on which to build a value-added business.

The CEO must make clear priorities among these objectives.  There can be only one primary objective, and all others must be traded off.  Inconsistency will confuse your team and the customer base.  Your open source project must be coherent -- any contradiction or insincerity will be immediately detected by the community and mercilessly criticized by the zealous people you're trying to leverage. 

Many management teams have bi-polar behaviors around their intellectual property (IP). They want to have an open source project that is wildly popular, and they want to maintain patents to ensure that competitors don't use their IP against them.  While these things can be done, the gravitational pull of a successful open source project means you're going to lose control over some of your IP.

How to execute:  here are the steps for formalizing an open source strategy--

  • Make sure your project is going to be the category owner; competing open source projects are a real problem.

  • Define your business model:  how will you make money.  Note that open source is a game of very large numbers, and conversion rates well below 1%.

  • Have a two-year time horizon, and dedicate resources.

  • Write out your priorities, objectives and agenda, with specific milestones and metrics of success (e.g., number of downloads, number of users, number of contributions, revenue, etc.).

  • Outline a budget -- both one-time costs and ongoing.

  • Describe organizational responsibilities and specify the rules of engagement across your organization before you start any externally-visible parts of the initiative.  

  • Publish your written plan to the team, but don't let it get outside your company.

2.  Do Marketing as a Process, not an Event

Most ISVs and OEMs doing open source expect to spend quite a bit of effort on marketing, because the whole point of the strategy is to change market dynamics.  But, it is a common mistake to assume that the marketing is complete when you do the press release and launch the open source site.

In fact, that's just the beginning.  The whole point of an open source project is to generate ongoing and growing awareness, enthusiasm, and adoption.  But there's a nuance:  software developers are almost allergic to conventional marketing.  You have to be subtle when "marketing" to geeks.  The best marketing is done by engineers who play the role of architect for the project and by savvy techies in your organization who act as shepherds for the community.

If you haven't seen them before, check out previous marketing pieces (3 separate links there) on community building.

How to execute:   The marketing strategy and logistics must be completed long before you go public with the open source project.  Make sure to cover early on--

  • Analyst strategy -- Which ones, if any, do you need on your side; when do you need to brief them; what do you need them to say to the media/industry?

  • Press strategy and messaging -- Which reporters do you want writing about your project, and what message do you want the trade journals to echo?

  • Trademarks -- Are you inventing a new mark for the project, or are you using your old product trademark in some way?  What do the lawyers say about protecting your mark, and what will the open source zealots say about a project named after a commercial product?

  • Licensing model -- GNU?  Mozilla?  What kind of patent protection are you hoping for?  What about indemnification? How will partner IP be handled?  There are probably 30 different open source nuances, so use a lawyer specializing in open source.

  • IP -- Is all the IP you're contributing to the open source project actually yours?  Did you license-in technology and embed it in the code?

  • Web site design -- Do you want two sites, one for users and another for contributors?  Do you want these sites hosted externally?  Can you get the right ".org" domain to match with your project naming?  How and where will the community interact?

  • Partners -- What's your offer to product and service providers?  What business models will you support?  Is it OK for "competitors" to be partners?  Who will recruit them?  What will the revenue flows be, and how will they make money?

  • Community rules of the road -- What are the ground rules, by-laws, and social contract between your company and the community members?  Why will they stick around and positively contribute?

Post-launch, marketers must find ways to get monthly PR for the community and the project, and they must manage the evolution of the project and community membership on an ongoing basis.  This is a full-time job.  Most marketing costs will stay the same or increase slightly.  The only marketing cost that goes down with open sourcing is lead generation -- because that will happen virally.  The bigger the community, the larger the required scale of ongoing marketing effort.

3.  Prepare Operations for the New Model

CEOs contemplating an open source strategy almost always underestimate the impact on their Operations team -- Engineering, QA, Sales, and Support.  All four of these groups will have incrementally more to do in preparing the customer base for converting your product into an open source project.  Further, engineering and QA will have more to do on an ongoing basis.  This can be a big surprise at budget time.

Almost invariably, you will want to build a business around the new open source base, which means you will depend on the evolution of the code.  But, you must give up a significant degree of control in order to get a vibrant developer community.  So, some new infrastructure and behaviors are needed. 

How to execute -- Engineering / QA:

  • Make sure that the IP is clean of "contamination," and scope the work involved with replacing or working around other companies' IP.

  • Strengthen the architecture by increasing modularity, so you can design out proprietary libraries (e.g., MFCs), cleanly demarcate any technology that needs to be replaced, increase portability,  and establish "private interfaces" for your value-added code.

  • Work the community political issues, such as feature roadmaps, release planning when you don't control the code, or dealing with partners who start behaving like control freaks.

  • Get the logistics right, particularly in how you expose the source tree to the community, which tools you use (CVS, ANT, JUnit, Clover, and Cactus are the de facto standards), and how you automate the community interaction (code "forge").

  • Expect to test more frequently and more thoroughly than you have in the past.  Expect to invest more in build, integration, and test automation, as community based projects put more of a load on these functions.

How to execute -- Sales / Support: 

  • Develop a really solid "party line" regarding customer-facing issues (e.g., "I just paid for this product, and now you're making it free?").

  • Create new support offerings for your existing customers, and price them in a way that's realistic and fits with your value-added products or services.

  • Train and compensate your sales and channel team so they won't disparage the open source version.  Give them the tools so they can upsell your revenue-bearing products without falling into pot-holes.

  • Train sales and support on how to work with partners -- you are sure to get new product and service partners in the community, so you mustn't treat them like competitors. 

 

_____________________
*For obvious reasons, I haven't bothered to talk about unsuccessful commercial approaches to open source.  But I must mention idea that comes up frequently:  EOLing a product by throwing it into open source.  This one by definition can't make you any money, but it can be very embarrassing if done sloppily.  Which it usually is.  If you're about to go this route, take the time to create some customer goodwill around it.   The idea is open source, not "open sores."

Phone Us +1 650 326 2626