Building a Strategy
Launching an open source project does not guarantee its success. Successful open source software projects require more than accessible code and a willingness to collaborate. The most popular and effective projects have communities that thoroughly understand their partner and contributor ecosystems, set clear goals, and structure their collaboration with these goals squarely in mind.
That is, they have clear and effective strategies. As Karl Fogel in Producing Open Source Software:
The hardest part about launching a free software project is transforming a private vision into a public one. You or your organization may know perfectly well what you want, but expressing that goal comprehensively to the world is a fair amount of work. It is essential, however, that you take the time to do it.
In this chapter, we'll provide resources for doing that work. Along the way, we'll suggest a few guiding questions project leaders and maintainers should discuss in order to sketch strategies for their open source projects. Answering these questions should clarify critical facets of the project and help maintainers determine what to do (and, just as importantly, what not to do) to guide their projects to success.
Moreover, some open source projects eventually become open source products—that is, they play some role in an organization's revenue-generating activities. In this case, the strategies that guide them become even more complex, as their success or failure impacts (and is impacted by) business decisions. So in this chapter we'll also discuss the additional work of developing an open source product strategy, so open source communities in pursuit of marketplace success feel better equipped to achieve it.
What is a strategy?
Your open source strategy is a comprehensive and adaptable procedure for achieving an objective and overcoming obstacles that might prevent you from that achievement. Simply put, your strategy is your plan to architect, nurture, and grow a successful open source project.
Today, people tend to overuse the term "strategy"—so much so that its meaning may have become somewhat diluted and imprecise. Your project's strategy is not merely a list technical capabilities, a series of long-term goals, or the community's vision of success. It is a coordinated plan of action informed by thoughtful analysis of your situation. In his seminal book on strategic thinking, Richard P. outlines three components of an effective strategy:
A diagnosis, which explains the precise nature of the problem a team or project is facing and distills its essence into something coherent and manageable
A guiding policy, which describes (in general terms) an approach to addressing that diagnosis
A set of coherent actions, which a team must execute in coordinated fashion to implement the guiding policy and see it to fruition
Rumelt calls these the "kernel" of good strategy because they are all necessary ingredients in any recipe for success. The work of identifying the kernel of a good strategy for an open source project can be difficult, time-consuming, and full of debate among maintainers, contributions, and other project stakeholders. But that work is absolutely essential for building a project that endures. We'll therefore organize our advice on setting an open source strategy according to Rumelt's three-part architecture.
Building an open source strategy
Building a strategy for your open source project involves the work of what open source consultant Emily Omier calls "." For Omier, positioning an open source project involves "controlling the assumptions that people make about your project and narrowing down the audience of potential users as much as possible" (p. 5). When architecting a strategy for your open source project, you'll need to position your project with, against, and alongside other open source projects in an (increasingly crowded) ecosystem. You'll also need to navigate various audiences and locate the various groups of people who might (or might not) use your project. So to build a strategy, you'll need to take stock—not only of your technology's capabilities but also of its relationships (current or potential) in a larger web of open source projects, products, and communities.
In the following sections, we provide some of those stock-taking resources, including key questions project maintainers can be asking as they make strategic decisions.
Locating the problem(s)
The initial work of developing an open source strategy involves identifying problems. Better yet, we might say that it involves identifying challenges. People who use software (developers and everyday computer users alike) often face challenges they need help overcoming. Ideally, your open source project helps them do that. But your project and its community will also face their own challenges—that is, challenges to getting recognized, adopted and embraced by those users. So when you're thinking about your project's related problems, you'll need to think in two registers:
The problem your project solves. This is the problem you and your community are designing your project to address for users. It is often a technical problem.
The problem of getting adopted. This is the problem of, for example, becoming visible to users, or getting adopted and embraced by those users. It is often a social (and in some cases, an economic) problem.
To build an effective open source stategy, you'll need to clarify both these types of problems. To elucidate the problems your project both solves and faces, you will need to develop what Rumelt calls a "diagnosis." A good diagnosis, Rumelt writes, "names or classifies the situation, linking facts to patterns and suggesting that more attention be paid to some issues and less to others" (p. 79). Or—put another way—it is the answer to a singular question: "What's going on here?"
What are the situational forces giving rise to your project? Why is it necessary in the first place? And what forces or factors could inhibit that project from finding an audience or gaining traction in some part of the open source ecosystem?
Answering these questions is of paramount importance for devising a successful open source strategy. But answering them outright is difficult. We therefore suggest first answering questions more immediate and graspable, like:
What is the project?
Who are the project's users?
What alternatives to your project already exist?
What is the project?
This is a deceptively simple question. Its answers typically aren't so simple.
Too often, open source projects describe themselves in terminology unfamiliar to many potential users, or they focus on how they do what they do, rather than on the problems they can solve. When formulating potential answers to this question, focus them on how the project helps its users. Ask questions like:
What problem does this project solve?
How would you describe your project to a potential user of the project in the most succinct terms possible?
For example, let's imagine we're asking an Istio developer what Istio is. The most basic answer is "it's a service mesh." One might argue, however, that most container application developers don't entirely understand what a "service mesh" is. So the shorthand description—"It's a service mesh!"—doesn't help a novice understand whether or how to use it. A better explanation might involve describing in terms of an application data plane and control plane (if you're talking to someone with a background in networking, for example), or perhaps a concept of traffic cops assigned to components of an application (if I am explaining the project to someone entirely unfamiliar with the concept of a service mesh).
Ask as many follow-up questions as your community needs in order to develop a simple, straightforward understanding of project and what it can do—that is, not just how it functions, but what difference it makes for someone who would choose to adopt and use it.
Who are the project's users?
Many open source projects do not clearly understand who uses their projects and what those users do with the project's tools. Consider using the concept of "personas" to characterize archetypal groups of key users, and be sure to think in terms of "jobs to be done."
For example, you might categorize a project's potential or current users with a number of criteria:
Is the project more useful to an individual or to an organization?
Is your project particularly useful in a specific industry vertical or business domain?
What size organization will find your project most useful? Are you targeting sysadmins in large enterprises, or the small and medium business space?
What are the job titles of the people who will be downloading, installing and using your project? Are they the same people? Or are the users different from the project administrators?
Answers to these questions will influence the priorities your community sets for structuring the project, promoting it, and even the degree of engineering effort you'll invest into certain features. For example, if your project runs in a datacenter or on a cluster of servers, your audience will typically be a business audience—people running IT professionally (or as a volunteer in a university). For a mobile application or a web development framework, the majority of your audience will be running your project on their personal computer, workstation, or mobile phone. Each of these groups has different resource prerequisites, and the problems motivating their use of the project and its tools are different. Mis-targetting the wrong categories of users could raise adoption challenges for your project.
Moreover, anyone interested in developing an open source product strategy should think additionally about the critical relationship between project users and product buyers. So if your strategy involves commercial aims, you might also wish to ask something like:
What is the relationship between the people who download and install open source projects and the people who evaluate and purchase commercial products?
A company's path to adopting open source doesn't usually follow a straight path from using an upstream open source project to converting to an enterprise open source product. Open source adoption tends to be "grassroots," bottom-up; enterprise open source products are often evaluated and purchased top-down. Those adopting an open source project inside a company can be valuable influencers when consulting on purchasing decisions—if they're connected to the purchasing process, or if the person responsible for purchasing is aware that the company is already using the product.
What alternatives to your project already exist?
You can learn a lot about your project by assessing who that project competes with (or who you believe it will compete with, if you haven't yet launched the project). Often, this involves paying attention to the other projects the people you identified in the previous step of your analysis use to accomplish the same (or similar) tasks you identified in the first step. Consider asking:
If your project doesn't have any competition, why is that the case?
Does this project play a role in an area of emerging technology?
Are people using similar projects to do work they could accomplish with your project—just in a different way?
If other projects do the same job, how are they approaching the problem differently than you are?
What are people's motivations for using a competing project?
If your project has open source competitors, is joining them (rather than trying to compete with them) an option? If not, why not?
Analyzing your competition can help you begin diagnosing the situation in which your project operates and plays a role. Answering a number of these key questions early in a project's strategic process will help when your community begins prioritizing features and deciding how to contact potential users (which we'll cover below, when we discuss developing coherent action plans). Perhaps, for example, you can piggyback on existing gatherings between people already interested in a competitor's technology and spread your message there.
If your strategy involves creating an open source product, you might also pose a few questions about market competition and customers, like:
If a competitor is an incumbent in the market, what can you tell about them and their customers?
Who are your competitor's customers? What do they have in common?
Your answers here could directly impact your community architecture or go-to-market activities. If you're an upstart attempting to disrupt an established market, for instance, your goals and messaging may be anchored to your competition: "cheaper than," "an open source alternative to," "simpler and faster than," and so on. If you're in a new market and your project is involved in a "land grab" to quickly gain market share, you'll need to focus on spreading your message quickly—which means a higher marketing budget or more aggressive community plan, and more focus on defining the problems you solve for potential users.
Remember: All software is a solution to a problem someone is experiencing. In diagnosing the situation in which your project takes shape, your first priority is understanding what that software is, which problems it solves (and for whom), how it's related to other projects in the wider open source ecosystem, and why users would choose your solution over others'.
Outlining your approach
Once you've diagnosed the problems you believe your project should solve and the problems you expect to encounter when attempting to popularize it, you'll have a clearer sense of what makes your project unique, who the project will appeal to, and why it is potentially so valuable to that group. You'll also likely recognize some of the hurdles you'll need to overcome as you build and grow your project and community.
So your next challenge is establishing the overall approach to getting it in users' hands and responding to their needs and concerns. Choosing to open source your software unlocks key avenues and opportunities for you and your community—but you'll be much more successful if you collectively choose to traverse one of those avenues rather than all of them.
Developing the proper strategic approach for your open source project is akin to articulating what Rumelt calls a guiding policy. An effective guiding policy, Rumelt writes, "channels action in certain directions without defining exactly what shall be done" (p. 84). In this case, a clear guiding policy focuses your communitiy's activities by helping it decide what kinds of things it should and shouldn't be doing (more on that in the next section on coordinated actions). An effective guiding policy, Rumelt writes, either creates or leverages sources of advantage. "Indeed," he writes, "the heart of the matter in strategy is usually advantage. Just as a lever uses mechanical advantage to multiply force, strategic advantage multiples the effectiveness of resources and/or actions" (p. 85). Choosing to open source your software unlocks many potential sources of strategic advantage for your community (including your users). But you'll need to determine precisely which of those advantages you wish to leverage. The questions we offer in this section should help you make that determination. These include:
What are your goals with this project?
How can you work with adjacent projects?
What are your goals with this project?
The decision to license one's invention with an open source software license shouldn't be a trivial or arbitrary one. It should be one made with strategic intent. What, you must ask, are the reasons I'm choosing to open source my software?
Surprisingly, many projects have difficulty answering this question. They've already decided that they want to open source their software, but they haven't given adequate thought to why. For these projects, "open source" would seem to be an end in itself. But in truth, the decision to open source one's software should always be in service of some other goal—it is a particular means to several potential ends. Any adequate and effective open source project strategy must make these ends clear and explicit.
So before committing to creating and maintaining an open source project, understand why open sourcing the project will help you, your community, or your organization achieve certain objectives. For example:
Are you seeking new perspectives on your work? Open sourcing your project allows others to assess your work, offer feedback on it, and contribute to it in ways that can help you grow as a software developer.
Do you hope to lower the development burden? Open sourcing your project invites others to play key roles in developing and maintaining your project as it becomes more popular.
Are you trying to make your project more secure? Open sourcing your software helps others spot issues and vulnerabilities you may not have noticed.
Answering questions like these might require some introspection. But doing so will help you and any (current or nascent) community determine how it will design, plan, architect, and maintain the project.
The question of why one might open source a project is even more pressing in commercial contexts. When establishing an open source product strategy, your goal is to connect the benefits you'll obtain by open sourcing your software with a concrete business goal. To be sure, "open source" is not a business model. It is a licensing decision meant to unlock certain opportunities—like the chance to develop software more collaboratively with users, or to increase a project's potential reach by lowering acquisition costs. These opportunities are only valuable insofar as they relate to your organization's overall business goals.
To understand any business rationale that makes an open source approach appealing, consider these economic principles:
Reducing the price of a good increases the demand for it. In the case of open source, lowering the cost of acquisition maximizes demand and, therefore, project adoption. Note that the cost of adoption is not only monetary; it also includes the time and effort needed to adopt and migrate from whatever solution you're currently using.
When the price of one good decreases, demand for its substitutes also decreases. Open source projects can undermine established proprietary software companies by being convenient to adopt at a lower cost. This principle explains how open source can be an agent for market disruption. Disruption is an opportunity to capitalize on the adoption of alternatives and grow another market.
All else being equal, when the price of a good decreases, demand for its complements increases. Every successful commercial open source strategy is based on this principle. If your goal is revenue, then you will need to determine the complements to the software that you'll be releasing as open source. Those complements should provide additional value to customers.
So are you trying to:
Grow a market?
Disrupt a competitor?
Promote a standard?
Increase demand for another product in your portfolio?
Choosing to open source your software project could help you accomplish any of these goals. But each of these goals demands different approaches to project and community architecture. Mozilla has the most common such architectures—what it calls "open source archetypes"—to more clearly illustrate how an organization's goals in open sourcing a project influence both the ways that project takes shape and the kinds of activities in which a community must engage to help it succeed.
Understanding the reasons for open sourcing your project will help you, your organization, and your community clarify both the levels and types of investment required to achieve your goal. In other words, they'll be critical to the overall policy that guides your strategic actions.
How can you work with adjacent projects and their communities?
As you've studied your user community, perhaps you've noticed that users frequently consume your project along with another, different project. Or perhaps you've seen that your project could be appealing to users who have already adopted a different approach to addressing their challenges. When either of these is the case, consider it an opportunity for expanding awareness of your project in its early stages and better understanding your users' needs.
The objective here is to study the projects that sit "adjacent" to yours in a specific ecosystem of open source projects. For example, Ceph can manage storage for OpenStack or Kubernetes; for Ceph, then, OpenStack and Kubernetes are adjacent communities.
Catering to adjacent projects to find an audience may affect your technology roadmap, the events you target, the effort you put into specific integration projects, and more. An adjacent project provides you with a potentially friendly audience who have the same problems your technology solves, so you can engage in some joint market research or UX testing, or coordinate joint events to meet and engage with potential users. This is also connected to understanding your competition; the communities important to them will also be important to you. Understanding these communities, their needs, and their dynamics can help you find footholds for your own project as you attempt to create space for it in a larger ecosystem. Your open source strategy should include analysis of these opportunities, and leveraging them should be part of the overall policy that guides your actions.
Determining your actions
By now you've identified the specific problems that your project should address for a particular set of users, and you've outlined your overall approach to success for both your project and everyone investing in it. Now you'll need to decide what you and your community actually need to do (and not do) to bring your overall strategy to fruition. In Rumelt's terms, you'll need to identify a series of "coherent actions" that you can execute to realize success.
Identifying these actions is critical because it will sharpen your community's everyday, tactical work—that is, it will focus everyone on doing what matters most. Open source project maintainers don't often have the luxury of immediate, sustained contact with users who contribute to their projects. Instead, project contributions typically arrive unprompted from strangers who may not be working with the same rich degree of context that founders share. The best a project maintainer can hope to do is establish a scaffolding that helps volunteers acting autonomously to take action in ways that advance the project's overall goals.
In this section, then, we suggest posing the following action-focused questions as you develop your open source strategy:
How do you engage with your users?
Who are your key stakeholders?
How do you engage with your users?
Once people begin turning up to your project, engaging them is key to growing the project's user base and community. You can engage with users in multiple ways, each requiring different degrees of effort and resulting in differing outcomes. But determining where you should focus your efforts can be difficult, especially because the most precious resource project maintainers have is their time. Engaging users personally requires a good deal of it.
So as your strategic approach matures, it's useful to take stock of all of the ways you're currently engaging with project users in order to identify blind spots and opportunities for improvement. Consider characterizing engagement techniques as "low-," "medium-," and "high-touch" (terminology we borrow from sales organizations). Low-touch methods involve relatively little interaction between potential users and community leads, while high-touch methods represent one-to-one or one-to-few efforts. The former tend to require significant time to establish and set in motion, but when configured require less intervention from human actos. The latter require less investment of time and energy "up front," but can tax human actors significantly when executed. Here are some examples of the types of things you can categorize this way:
Low touch: Website, documentation, online training, newsletters, podcasts, blogs
Medium touch: Mailing list, bug tracker, community forum, conference presentation, webinars, user groups
High touch: Phone calls, one-on-one or one-to-few training, conversations at conferences, community meetings
This kind of model may be useful to communities thinking about engagement activities and project goals. For instance:
Low-touch activities are good for raising awareness of your project and getting people to look at it for the first time. Ensuring your web site and other materials clearly communicate what the project does, how it can help users, and how contributors can try it out and get started quickly is paramount. Likewise, working on your website, documentation, and promotional materials allows new users to act autonomously and without much help from a senior community member.
Medium-touch activities are great for creating a "center of gravity" around your project—not only making communication with users possible but also enabling those users to help each other (hopefully generating a network effect). Your bug tracker, mailing list, and forum provide opportunities for community members to engage with your community, ask questions, and provide feedback. This kind of activity provides an opportunity to learn more about how people are using your project.
High-touch activities are great for building relationships with key community users, gathering community case studies, and helping larger groups be productive with and become advocates for your project. High-effort activities like training, conference booth attendance and follow-up, and in-person conversations can be extremely valuable on a one-on-one basis—but those techniques do not scale well.
Ideally, your project will have a healthy mix of each of these. A key consideration for groups crafting potential engagement is how someone unfamiliar with the project might start using it and, over time, gain seniority in the project to the point of becoming a core contributor.
Who are your key stakeholders?
When you've identified the actions that will be most important for helping your project succeed, you'll need to ensure you've got the right people with the proper tools to carry out those actions. Call these people your "stakeholders"; they're the people who care most about your project and are prepared to bring their (undoubtedly considerable) talents to it.
An open source project will include a number of stakeholders, including the maintainers who oversee the project and manage its resources, the developers who contribute code and other materials to a project (documentation, technical articles, social media announcements, etc.), and the users who provide feedback on the project and file issues they discover. Naturally, a successful project requires all of these. On top of that, you'll need to ensure that thees groups include members with the skills necessary for carrying out the actions you've identified will be critical to your project. For instance, if your project exists to advance a new technical standard, and your policy is to focus on delivering libraries for developers in your target market, and this involves writing extensive documentation according to specific technical standards—then you want to be sure experienced documentarians are part of your community (or that you're allocating sufficient time and energy to locate and attract these people to the project if not).
In the case of vendor-backed open source projects with commercial aims, your stakeholders also typically include people from inside your organization—an engineering lead, product management, product marketing, and a representative of the field (field engineer, sales). You may also want to include in this group someone from your content services or support organizations and someone from product security. This is the group of people you will brief to prepare a stakeholder review, and you should gather them once every six to 12 months to check in on the state of the project and ensure alignment on the goals and the required investments to achieve those goals. When working with stakeholders from your organization:
Strike a balance between involving too many people at an early stage and ensuring buy-in from a diverse group of people from the start.
Organize your stakeholders using a model of growing, concentric circles. Identify a core team that shares draft proposals early and often and engages with additional groups to gain awareness of concerns or constraints. Involving these stakeholders early will help you catch and address deal-breaking issues early.
Ensure that all stakeholders share an understanding of the problem your work is addressing and the ways your overall approach will help address that problem in a way that's beneficial to the organization. In short, make sure your stakeholders understand the project strategy and their roles in it.
Recording your strategy
Just as important as developing a strategy for your open source project is writing that strategy down and publishing it somewhere your current and future users, developers, and maintainers can review it. After all, even the most brilliant strategy is useless if no one sees, understands, and follows it. Everyone in your community should be aware of the project's strategy and understand how their work advances it.
Luckily, if you've drafted your strategy according to the framwork we provide in this chapter, you've already begun articulating your strategy in a way that should help others see themselves as part of it. You'll have:
A concise (and precise) description of your project and the problem(s) it solves for users
A description of how your project solves that problem in a way other projects don't
A clear understanding of why an open source approach to this project is beneficial
A sense of the users, developers, and maintainers contributing to the project
A list of activities in which you'll engage to grow awareness of your project and lower barriers to participating in it
Consider releasing these materials as part of your projet's documentation so others can begin to understand your strategy—and start contributing to it. And don't stop there. Articulating a strategy is only the beginning, not an end.
Continually monitor and communicate progress toward project goals. If fostering a diverse group of codevelopers is your community goal, then celebrate contributions from new participants and include growth figures in your monthly newsletter.
Allocate resources in a way that makes success possible. 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, then your chances of success are low.
Ensure that your strategy is a living document. Revisit it regularly with key stakeholders to ensure that your open source strategy stays fresh and relevant.
Additionally, if you're working in a commercial organization to develop and communicate an open source product strategy, we recommend drafting a document that contains the following elements:
An elevator pitch, or a high-level description of the open source project's goal and a short explanation of how the project benefits the sponsoring company. No two projects will have identical goals, so no two projects will share exactly the same product strategy.
A business rationale, or a description of how success for the community project translates into success for the company or product team. For example, "Wide adoption of this project will help people glean more benefit from our other products," or "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 of the standard."
A high-level execution plan, or a list of your planned actions, including key performance indicators (KPIs) that will be important for determining success. Project goals suggest these KPIs. For example, if your goal is de facto standard implementation with wide adoption, then you might measure the number of vendors distributing standard-compliant implementations. If your goal is market education, then the performance of introductory documentation, learning paths, tutorials, and magazine articles will be your indicators of success.
When the entire organization understands the project's goal and its relationship to the organization's commercial ambitions, reaching consensus on budget and resource allocation should be much easier.
Conclusion
This chapter explained the importance of developing a strategy for your open source project. It outlined the elements of an effective open source strategy, and posed several questions you and your community can answer in order to hone a strategy for your own open source projects. After a fruitful strategic planning session, your team or community should share some understanding of the problems your project solves (and for whom). You will be able to communicate the value of your project in language that makes sense in your potential users' frame of reference. You will understand how your project fits into the broader open source ecosystem, and what you want to achieve with it there. And you will have identified the stakeholders who are capable of taking the actions required to bring about success. This chapter also explained how an effective open source product strategy provides clarity on which markets you are targeting, establishes the business advantage of open sourcing your technology, elaborates the role the project plays in your entire business strategy and product portfolio, and ensures you are measuring the right results to gauge your success.
Last updated