(This is the second post in our Open Source At Large series.)
There is a lot of documentation out there on how to do open source well at the project level. Historically, many projects have been started by developers, often on their own initiative, and the first non-technical questions they faced tended to be about project coordination (like “What collaboration tools shall we use?” or “What will our code review practices be?”) and about community management (like “How do we decide who has commit access?” and “How do we integrate newcomers smoothly?”). Because developers hate to solve the same problems over and over, there is a wealth of detailed and varied material addressing those sorts of questions (we’ve even written some ourselves, but it’s just a drop in the bucket of what’s available). Taken together, this literature thoroughly answers the question “How do we execute the best tactics for developing open source software?”
But there isn’t yet a lot of material on open source strategic thinking. Indeed, it’s traditionally so under-discussed that often when we talk about it people think that we’re talking about the nuts-and-bolts of how to run projects, rather than the broader question of how an organization uses open source to further its mission.
This blog series is about open source strategic thinking, so the first thing we want to do is define what that is. It overlaps with tactics, of course. For example, the tactical question “How do we integrate newcomers smoothly?” unfolds to become the strategic question “What are the long-term returns we want from engaging with others, who are those others, and what kinds of investments should we make in order to achieve those returns?”
Let’s run with that example for a moment. It’s deceptively easy, with one’s overworked-developer hat on, to think that the answer is obvious: “Oh, we want to bring in others because then they’ll contribute code and bugfixes and documentation to the project, thus lowering the costs of development for everyone else.” But with one’s strategic-thinker hat on, the question starts to look more complex — its many possible, non-mutually-exclusive answers each affect the shape of the investment.
If one of the ways the open source project serves your goals is by providing a channel for closer technical cooperation with customers and potential customers, then perhaps your investment in engaging participants should emphasize fast response times in discussion and deliberate probes to uncover usage scenarios. On the other hand, if the point is to disrupt a competitor’s proprietary product in the marketplace, then it might make more sense to invest heavily in ease of deployment, including fast processing of the relevant bug fixes and documentation contributions. One thing is certain: you cannot make every investment at once. All human endeavors are resource-constrained, and software projects are certainly no exception. One does not have a choice about prioritizing; one merely has a choice about whether to do it purposefully — strategically — or accidentally.
Please do not place too much weight on that one example, in any case. While investment in new participants is an important component of open source strategy, it is not the only component. If we were to make a high-level list of possible strategic concerns, it might look like this:
- How open source supports your mission or goal.
- How it affects your relationship with competitors and their products.
- How it affects your relationship with customers.
- How it affects the internal structure of your organization.
- How open source allows you to draw in partners; how it affects where those partners come from; how it defines your relationship with those partners and their relationships with each other. (Project governance is a subset of this, but typically is not the most important subset.)
- What types of investments you need to make to shape the above relationships in ways that serve your goals.
- How you sustain your open source efforts over time. (A project’s sustainability model(s) is not the same as any one of its participants’ business models. An open source project that aims to create a diverse ecosystem of lightly-involved support vendors will have a very different sustainability model from a project that supplies a key piece of infrastructure needed by a few large corporations.)
- What you can do as an open source actor that your proprietary competitors cannot.
- What collaborative or market opportunities does being open source enable?
These concepts are not just for executives and managers, by the way. Developers benefit from strategic awareness, and of course can help support a strategy most effectively if they know about it. Our target audience for these posts is developers who want to think strategically, as much as it is managers and organization leaders.
In order to do strategic planning around products and projects, we have found a common set of base information and exercises to be useful: explicit goal-setting; mapping the ecosystem that surrounds the project; identifying business models (before identifying sustainability models); understanding the cyclical way in which open source commoditizes product categories and what that implies for the particular product and category in question; how an open source project relates to the procurement and deployment habits of its intended audience; and making choices in the inevitable trade-off between control and reach.
We will discuss each of these in future posts in this series. The point of this post is simply to say that strategy is a thing, and that it is separate from community management, collaboration tools, and everything else that makes things run at the project level. To use open source to meet your goals, it is necessary to structure your open source engagement in ways that align with those goals — and this is fundamentally a strategic question that won’t be easily answered from within the confines of day-to-day technical development.
Thanks to Microsoft for sponsoring the Open Source At Large blog series, and thanks to Josh Gay for sending us copyedits on this post.
