The Taber Report: Monetizing Open Source


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, in fact commercial successes are rare. CEOs and VCs alike usually underestimate the work involved.


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, in fact commercial successes are rare. CEOs and VCs alike usually underestimate the work involved.

The top line here: 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 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’re going.

Monetizing open source


Starting or leveraging an open source project has been done 100,000 times, literally. But successfully monetizing an open source project is rare.

Successfully commercializing open source requires carefully thinking through your specific situation. I’ve seen almost no examples where copying someone else’s open source strategy works.

I’ve developed a three part model for successfully commercializing open source. You must:

  • Make the Strategy Explicit and measurable across your organization, even as you keep it secret outside.
  • Do your marketing as a process, not an event. Expect to invest staff on an ongoing basis if you want a clear success.
  • Tool up Operations for the Sales, Support, and ongoing Engineering tasks that are required.


  • Don’t assume any of your costs will go down. The only part of marketing that can get less expensive is lead generation.
  • Don’t rush it. Do your homework before you make public noises.
  • Don’t be crass with your community. Typically, they will be extremely sensitive and will see through any contradiction or corporate spin. The newsgroups will be on fire if you’re clumsy.

Best Practices

Have an internal kickoff meeting as soon as you have fully developed your strategic intent. Make sure to establish a timeline, organization structure, milestones dependencies and budgets before making any promises regarding dates.

Dedicate a marketing and engineering "shepherd" for the community. The individuals involved need to have finesse and subtle communication skills.

Training and attitude adjustment all across your organization are important.

Design your product strategy to be very flexible about packaging and price points. Each market space will have unique preferences that can only be guessed in advance.

Since there are about 100,000 open source projects, there is a wide range of approaches to running them. But for commercial projects — lead by ISVs, SIs, and hardware OEMs trying to make money through open source — there is a more select group of successful* approaches:

  • 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., as one of its favorite new add- on products.
  • Taking your existing product technology and putting it into a new open source project. 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.
  • 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.

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.

Three-part model

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:

  • 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 Taber Reports (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? 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 willhave incrementally more to do in preparing the customer base for converting your product into an open source project. Further, engineering 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.
  • Get the logistics right, particularly in how you expose the source tree to the community, which tools you use (CVS, ANT, JUNIT, and CACTUS are the de facto standards), and how you automate the test cycle to ensure ongoing compatibility.
  • Expect to test more frequently and more thoroughly than you have in the past.
  • 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.

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 one 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 it is 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."

Contents copyright 2005 by DOTnet Consulting, Inc, all rights reserved.

Scroll to Top