Participating in open source communities—or in any open organization, for that matter—means collaborating with others who might not operate the same way you do. Their motivations may differ. Their governance models might seem foreign. Their goals might not immediately speak to you. So if you're going to work together, you'll need to develop a clear sense of what makes the project tick—and decide quickly whether working together is best for your team and your business.
Similarly, if you're instigating an open source project, you should ask yourself, "what kind of community do I want to attract?" Then you can plan for and signal that accordingly.
Earlier this year, Mozilla and Open Tech Strategies released the first version of a tool we hope will help with this. Our recent report, "Open Source Archetypes," identifies 10 general types (or "archetypes") of open communities in their strategic contexts. The report offers narratives describing these archetypes, explains what motivate them, and outlines the strategic benefits of working with them. We also cite some examples of each archetype and offer insights into various licensing models, governance models and community standards that comprise them.
We first released the report internally at Mozilla, holding workshops for key individuals in designing our projects with representation from engineering, strategy, and legal teams. Given the positive feedback we received we then decided to publish it more widely—and I'd like to share the story of how it came about.
Open by Design
We started the archetypes work as part of a wider initiative at Mozilla, which we called "Open by Design."
Initiated in 2017, the project began with a comprehensive review of how Mozilla works with open communities. Mozilla is a radically participatory organization, famous for a volunteer community which launched the Firefox browser in 2004, and we wanted to formally and comprehensively review and catalog our own best practices.
Over time, these practices have matured and become widespread. The advantages that the Mozilla project drew from its community in 2004 are not so unique today. Indeed, many organizations, it seems—both commercial and non-commercial—work with communities and take a community-focused approach to their missions.
Open by Design looked at all aspects of collaboration across the organization's boundaries. It looked at a far broader set of open practices—beyond open source software development per se—including more structured approaches to bringing user insights, industry collaboration, innovation challenges, and crowdsourcing into Mozilla.
The program focused on the exchange of value between Mozilla and the different communities it works with. Open source has always been important to Mozilla, which licenses its software as free and open source as a matter of course. This explains the strong community around the project. But our work has implications for the strategic application of open source more generally.
Defaulting to open, a paradox
At organizations in which software is proprietary by default, people attempting to open source any particular asset must typically back that move with a clear business case, including a clear description of the market impacts they intend and an analysis of the project structures will best achieve this objective.
The paradox here is that organizations using open source as their primary or exclusive mode of software distribution tend (over time) to be less strategic about their use of open source compared to organizations with more proprietary models. It's just their "default" mode of operating; their methods are a taken-for-granted part of everyday life and don't require additional justification.
What's more, there's a real cost—in terms of time and effort—in growing community around an open source project. Decision-making processes, enforcement of social norms, and frequent communication are all typically the province of engineers—and all of this is time away from writing code. And different projects' requirements may vary; a project seeking to build a broad community of users should look very different to one seeking a handful of industry stakeholders as partners.
It's easy to fall into the trap of making a substantial investment into a community to whom you don't have a long-term commitment nor benefit directly from. It's important, therefore, to have a strong strategic foundation for any open source community investment you are going to make.
Given that we did not need to answer this question for one project—but instead wanted to be able to help many different Mozilla projects at once—we determined we needed a framework (or a set of approaches) to provide guidance and to stimulate and validate thinking. A shared vocabulary across an organization means that you can communicate a large number of shared assumptions, enabling faster and richer dialog about project strategy and design.
We assumed that some such taxonomy existed in the world. We were surprised to discover that none did.
After talking with experts from the Open Source Initiative and the Linux Foundation, we realized that while there were various categorizations of licenses, governance models, and technology applications, that there was no overall taxonomy of open source project types. Happily, we met Karl Fogel and James Vasile at Open Tech Strategies. While Karl and James frequently get asked for this kind of guidance, we understood that they'd never been engaged on an overall taxonomy before. But their breadth and depth of knowledge made it clear that they would be able to produce a report that advanced this thinking at Mozilla.
After understanding our situation well, Karl and James set out interviewing many different people in product, engineering, or strategic functions about our open source ambitions, and they compiled that analysis along with their existing knowledge of open source projects. From there, the difficult work of identifying commonalities—the archetypes—took place.
After a few months, we had a version 1.0 outlining 10 archetypes, and, crucially, how to go about applying them.
Applying archetypes
In order to make good use of the archetypes we detail in the report, a project needs to understand its strategic choices. That is, it needs to know its environment and its objectives within that environment.
And to understand a project's environment, it's important to understand the context in which software will be deployed, what problems it solves, and for whom. There's a world of difference between (for example) a component an OEM will embed to drive a new widget they're taking taking to market, or a Javascript library for front-end developers, or an office suite.
It's also important to understand what the exchange of value might be for a potential participant in the project—and, in turn, whom participants are competing against (and how your project helps them). OEMs may want to collaborate expressly on components that offer no differentiation, while software developers may be "scratching their own itch"—making the product much better—when they contribute to a development tool.
Defining objectives is challenging without any sense of a project's context. Within the Open by Design framework, we encourage projects to consider Treacy and Wiersemas' value disciplines and how open source can help them. The three value disciplines are:
- Operational Excellence
- Product Excellence
- Customer intimacy
. . . which for the purposes of our framework, we adapt to:
- Lowering Development & Operating Costs
- Developing Better Products & Services and
- Changing Market Dynamics
In other words, we invite project leads to consider how open source might improve their situation according to each of these dimensions. The potential benefits of developing a project as open source are many and varied; this framework helps both to categorize the expected impact of open sourcing a project and to look for additional benefits.
Here's one canonical example that's attractive to people: the idea than an open source project may attract investment from elsewhere, lowering development and operating costs. This could be the case under certain circumstances (such as our OEM example above); however, open sourcing a code base may help in other, more subtle ways, too—such as increasing your hiring pool, improving internal collaboration, or simply improving employee morale. Open source can also help improve your insights into customer problems (especially where customers are technical users who can be engaged directly into the project to contribute to it—such as software developers contributing to a developer tool). Lastly, open source can change the rules of the game, creating informal coalitions and partnerships, driving standardization and, in many cases, better overall market acceptance (the kinds of impacts that Android and LibreOffice have had, for example).
Open source can deliver all these benefits, provided you actively seek them out and are able to make the levels of investment required. And this is a helpful lens through which to approach the archetypes. Strategy must be grounded in reality.
By following this method, we're able to ask ourselves the right questions and determine what our real aspirations for any open source project are. We've started using the archetypes to think about project structures for our products, technology projects, and internal tools. We also know that the framework will improve with input from users, both in Mozilla and beyond, which is why the project is now on GitHub, licensed under the CC Attribution-ShareAlike 3.0 license.
We're convinced this is a helpful tool for any project to define its open source strategy.
Comments are closed.