Open Source Goal Setting

A soccer goal with a gorgeous snow-capped mountain backdrop.

(This is the third post in our Open Source At Large series.)

Open source is a strategic tool, not an end in itself. It is the stone in your stone soup. You don’t eat it — it’s just the invitation.

You reach for open source to create effects that will support your broader strategy. We’ve talked to dozens of clients about why they invest in open source, and the reasons tend to be fundamental and long-term: to achieve a cultural change in their technical organization, to influence a market’s direction, to recast relationships with partners, etc. Direct revenue is rarely the main goal of open source investment, even for for-profit businesses. Rather, open source is used to create an environment in which revenue-generating activities can thrive.

Below is a checklist, or rather a provocation list. It’s meant to help you answer the question “What effects do we most want from our open source investment?”

Treat this list as a menu, not a buffet. Pick three items and make them your high priority targets. Focus on effects that connect best to your strategy, and, ultimately, to your organization’s mission. You need to know where you want to go before you can chart a course to get there. We’ve broken the goals into three categories, but you can mix and match across or within categories as you please.

Development and Collaboration

  • Expand or amplify developer base
  • Gain market insight
  • Gain or maintain insight in a particular technical domain
  • Influence a technical domain
  • Create a framework for partner collaboration
  • Lead a standardization effort
  • Disrupt an incumbent, hold off insurgents

External Positioning

  • Ease customer fears of vendor lock-in
  • Deepen engagement with users, create more paths for engagement
  • Transparency for customers and partners
  • Establish a basis for product reputation
  • Organizational branding and credibility
  • Product branding and credibility

Internal or Structural Change

  • Improve internal collaboration (cross-individual or cross-departmental)
  • Create opportunities for internal mobility
  • Expand or reshape hiring pool, expedite recruiting
  • Improve morale and retention
  • Create flow-paths for bottom-up innovation
  • Improve and maintain open source capabilities (technical and social)

Again, we emphasize the importance of picking just a few. Winnowing down to just the most important goals is usually illuminating, because it forces your organization to articulate what it’s really after. Every item on the menu might look inviting, and any of them can be pursued opportunistically, but a strategy that tries to chase all these goals at once will go nowhere.

If you have goals for open source investment that don’t appear on this list, we’d love to hear them. The list was built up over years of experience, and we generally find that we can map from it to the specifics of a particular client’s or project’s needs — most open source dreams appear somewhere on this list. But that doesn’t mean we can’t be surprised, and we’re always happy when we are.

Thanks to Microsoft for sponsoring the Open Source At Large blog series.

What Is Open Source Strategy?

Misty mountains, photo by Pixabay user himalayadestination: https://pixabay.com/photos/mountains-climb-mountaineer-3970320/

(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.

Announcing a New Series:
Open Source At Large

Photo credit: CHAND ALi https://upload.wikimedia.org/wikipedia/commons/thumb/c/c2/Glorious-blue-mountain-range.jpg/1024px-Glorious-blue-mountain-range.jpg

Open Tech Strategies has a dual mission. Day to day, we help our clients understand how open source approaches fit into their strategic goals, and we help them implement those approaches. But over the long term, we also try to act at the ecosystem level when possible. The more organizations invest thoughtfully in open source, the better off open source as a whole is — and the more organizations will want to try it, in a virtuous circle.

For years we’ve been digging into the details of our clients’ operations, customer bases, and markets in order to help them recognize and act on specific open source opportunities. While this work is tailored to each client, we are always looking for ways to publish what we learn so it can benefit a wider audience. Our work with Mozilla on Open Source Archetypes and with the World Bank on their investment strategy for the GeoNode project are two examples. We’ve heard from open source practitioners across the field that these materials have been helpful to them (and we’ve received useful criticism and feedback — the sincerest form of flattery). Perhaps most gratifyingly, we’ve heard from internal open source champions at organizations that are still finding their way toward deeper open source engagement, telling us that having strategy-level materials to refer to helps them make their case.

Now we have a chance to do that kind of public analysis in a more regular and focused way. Starting this week, OTS will publish a series of blog posts focused on strategic concerns in open source. The series is kindly sponsored by Microsoft, whose request to us was essentially “help organizations get better at open source” (not a direct quote, but a decent summary). They were clear about the series being independent: they did not want editorial control, and specifically did not want to be involved in any pre-approval before a post is published. It goes without saying — but we’ll say it anyway, just to be explicit — that the views we express in the series may or may not be shared by Microsoft: please blame us, not them.

We’ll focus on the kinds of analysis we do when we advise clients: how to identify opportunities, how to make decisions about prioritizing and shaping open source investments, how to integrate open source methods into one’s business models and goals, monitoring and improving open source project health, and more. Our clients will recognize some of this material — our advice tends to be consistent over time — but much of it will be ideas we have not discussed widely before. We look forward both to offering strategic analysis to newcomers to open source and to engaging our colleagues in the open source field in a wide-ranging discussion.

Our first substantive post discussing “What Is Open Source Strategic Thinking?” is up.  Watch this space for more!