Crafting an Open Source Product Strategy

“Should we open source this project?” An easy question to ask, and a hard one to answer. The goal of this article is not to answer the question, but maybe to give some tools that you can use to find the answer when the question arises.

The first question to ask is why the project leader is interested in open source in the first place. Typical answers might include “because we want a community” or “because we want to be the Firefox of our field.” But when you dig deeper, there may not be a clear understanding of how an open source project can benefit your company’s goals.

The creation of an open source strategy is about finding that benefit. In short, you want to understand why open sourcing this project will benefit the company.

Open source is not a business model. Fundamentally, it is two things: a way to develop software collaboratively, and a way to increase the distribution and reach of your project by lowering the cost of acquisition. Your goal is to make a connection between one of these two things and a concrete benefit for your product and company.

The Economics of Open Source

To explain the product strategies that make sense for open source, there are three very basic economic principles it is worth understanding.

The first principle is, when you reduce the price of a good, you will see an increase in demand. In the case of open source, by lowering the cost of acquisition, we maximize demand and thus maximize adoption of the project. It is worth noting that the “cost of adoption” is not just money, it also includes time and effort to adopt and migrate from whatever you are using now.

The second principle is, when the price of one good goes down, demand for its substitutes will also go down. Open source projects can undermine established proprietary software companies by being convenient to adopt, and lower cost. This principle explains how open source can be an agent for market disruption. Linux disrupted the Unix market, and MySQL disrupted the relational database market. Incumbents may have a lot of inertia to change when their flagship product is threatened by an upstart, giving you an opportunity to capitalize on this adoption to grow some other market.

The third economic principle explains how to make money off open source. All else being equal, when the price of a good goes down, the demand for its complements goes up. This is why mobile service providers subsidize the cost of cellphones for people who buy 24-month monthly subscription plans, which is where operators make the real money.

Every successful open source business model is based on this principle. If your goal is revenue, you need to find the complements to the software you are releasing as open source which offer a lot of value to your customer, and charging a fair price for them.

Generating a Draft Strategy Proposal

You can combine these three principles of increased adoption, market disruption, and increased demand for complements, to define a product strategy. No two projects will have identical goals, so no two projects will share exactly the same product strategy. The first step is to isolate a specific, high-level goal.

To do this, you will need the right voices around the table. Make sure that when you run a strategy workstream, that you take some time to consider the constituencies who will care about the result. If you want your strategy to stick, it will need the buy-in of people other than your engineering organization. Others who will care will include your business leadership, sales and field organizations, product management, marketing teams, brand, and security teams.

There is a balance between having too many people involved at an early stage, and ensuring buy-in from a diverse group of people. Use the principle of growing concentric circles, where the core team talks to other groups to be aware of any concerns or constraints, and shares draft proposals early and often to head off any major objections. As your draft matures, working meetings will become bigger, and many more people will see the draft, but if you do things right, you will catch all the big deal-breaker issues early enough to be able to address them. That might involve changing plans, or converting critics into advocates.

When coming up with the strategy, it will be important to understand both the landscape in which the project operates, and the relative benefit of investing in one thing over another. I have found Wardley maps a useful tool to help describe the state of play, and creating one is a useful means of exploring a new area visually to ensure that you and others have a shared understanding of a space.

A final strategy proposal will contain a few important ingredients. First, an elevator pitch, with a high level description of what the goal of the open source project is, and how this benefits the sponsoring company. Second, a business rationale, which describes how success for the community project translates into success for the company or product team, and third, a high level plan for execution, identifying the key performance indicators (KPIs) which will be important for the project.

Some examples of the rationale for an open source project might be:

• • Wide adoption of this project will help people get more benefit from our other products

• • An open source reference implementation of a standard will encourage adoption of the standard by multiple companies, enabling a network effect for others building on top

• • This technology area is still new, and an open source project people can download freely will educate the market, and shorten our sales cycles for potential customers who already understand the market segment and benefits of our products

• • We want to create a successful platform for people to build lots of things on, and our plan is to monetize the creation and distribution channel for things built on the platform

In each of these cases, a potential set of KPIs is suggested by the goal. If your goal is a de facto standard implementation with wide adoption, then measuring the number of vendors distributing standard-compliant implementations is a great measure. If your goal is wide adoption of a piece of software, downloads and engagement metrics will be more important. Similarly, areas of focus are obvious. If your goal is market education, then getting started documentation, learning paths, tutorials, and magazine articles will be the top priority, for example.

Also, in each case, the relative benefit of the open source project is obvious to everyone in the company. The sales teams will not see money spent on community promotion as money taken away from selling or marketing products, if you are telling a compelling story about how community growth helps them in the long term, and can point to measures supporting that. Everyone has limited resources, and along the road, trade-offs will need to be made, but if everyone concerned understands the goal, you will find fighting the budgeting and resource allocation battles much easier.

Translating Strategy to Action

The final step of the journey is making the strategy stick. Strategy documents are useful if they affect action, if they allow individuals to make local decisions in the knowledge that they are supporting an overarching goal. Communication of your strategy is crucial for this. I recommend having a mantra, something you can repeat often, put on a t-shirt, make into stickers. If everyone knows the mantra, and understands how their work is affected by it, you have won the battle.

Another key to making it stick is to monitor and communicate progress towards the goal. If your community goal is supported by a diverse group of co-developers, then celebrate contributions from new participants, and include growth figures in your monthly newsletter.

Once you have a strategy to execute against, resourcing for success is crucial. If your goal is to move an entire industry from a proprietary competitor to an open source project, and you have one person working part time to promote the open source project, your chances of success are low.

Finally, as the world changes, you may find that the reasoning behind your rationale changes too. Ensure that your strategy doc is a living document, and revisit regularly with key stakeholders (I suggest annually) to ensure that the strategy stays fresh and relevant.

Conclusion

Crafting a product strategy around open source requires having all of your key constituencies represented in the process so that you will have buy-in for the result, exploring in depth why open sourcing makes sense for the organization’s goals, make sure you’re measuring the right things to gauge the success of your efforts, and finally, be prepared to pivot if circumstances impose it.

When you do it well, you turn everyone involved into an advocate for the open source project, and can have a very powerful force multiplier for the project, for the industry, and for your company.

Good luck!

Image by Max Pixel, under CC0 Public Domain license.