Spot The Pattern: Commoditization

Round Mountain Gold Mine. Pic from https://upload.wikimedia.org/wikipedia/commons/thumb/3/32/Round_Mountain_gold_mine%2C_aerial.jpg/1024px-Round_Mountain_gold_mine%2C_aerial.jpg
Round Mountain Gold Mine

Last week, I spoke with the CEO of a company that makes a proprietary category-leading workflow product. He asked me “what should we open source and when?”

This is one of the most common questions we get. There is no easy, standard answer to this question, but I usually start by looking for features of the ecosystem that either are or could be commoditized.

A commodity is something that is the same no matter who makes it. Gasoline is a commodity. Customers don’t really care where they buy gas. They want it cheap and reliable, but the gas itself should be the same stuff regardless of which oil company refines it and pumps it into your car.

In practice, of course, gas from different companies is not identical. Some places enhance it with detergents, mix it with ethanol, or add stabilizers.  But for the most part, consumers ignore these small differences.  You put it in your car and it works.  People pick gas stations based on price and convenience.

It’s hard to charge a premium for a commoditized good. People are not willing to pay extra for a product if they can get the equivalent for less elsewhere. As a result, gas stations compete on price.  This squeezes margins, and so in the end they make their money on the convenience store, just like movie theaters do with popcorn.

Open source software businesses are often in the same position. There’s a core offering that is, to put it bluntly, boring. Anybody could offer this boring core without innovating. You cannot be in the market without matching the core’s offerings, and customers want standard interfaces these days, so there’s not much opportunity to differentiate on the basic core offering.

Database servers follow this model. From a business perspective, storing rows of data is not interesting. Everybody can do it, and nobody really does it much better than anybody else. There are performance improvements at the margins, and we can build interesting services on top of storing information, but basic data storage and retrieval is just facilities maintenance, not the thing your customers choose you for.

Of course, not all data storage is basic. You can store things faster or in ways that make access easier. You can stack data vertically instead of horizontally. You can keep all the data in memory, duplicate it across multiple servers, or sync with client-side storage. These are features that can set one product apart from another. You might be able to charge a premium for them. None of them, though, is actually the boring, basic task of putting data on a disk and making sure you can find it later.

For a business that manages data but can’t find competitive advantage on storing it, the database is a cost. It’s not worth spending a lot of money to develop or acquire a database that improves on the standard set of features because there’s just not much improvement to be had. Best to source those features as cheaply as possible.

Of course, the same logic applies to everybody else in your industry. We’re all trying to get the boring stuff done as cheaply as possible. This is where open source cooperation comes in. We can’t compete on those features, so there’s no point being competitive about it. We use open source to get together and collaborate with all the other folks who want rock-solid databases. Open source lets us do this even if we’re in competition on a range of other fronts.

We see this pattern a lot in free and open source software. Product categories go open source, then contract, then perhaps expand when somebody figures out the next frontier of differentiation. Most recently, we’ve seen this effect around web rendering engines. Every browser’s goal is to depict HTML in standard ways. Aside from being at Google’s mercy, there’s little reason for most companies to make their own rendering engine when there’s a pretty good one that is open for the taking.

Spotting this pattern early is a crucial step in knowing what to open source and when.  You can lead or let somebody else lead — either might be strategically useful, but spotting the pattern lets you choose which position to take.

Sometimes it makes sense to open source what you have mainly as a signal to others that an area is becoming commoditized and so they should open source their stuff too.  That is, you don’t necessarily have to be aiming for a dominant position in a new open source area — in fact, you often don’t have to decide that in advance.  Instead, you open source because an area is about to become commoditized, and the earlier you shift your investments, the better positioned you will be get the type of influence that serves your needs in the inevitable post-commoditization universe.  (For more about the various forms that influence can take, see Open Source Archetypes.)

Once you start looking for the commoditization pattern, you see it all over the open source world. It is a common tool for understanding the strategic position of all kinds of products. In addition to the basic pattern, there are two more big concepts around commoditization worth considering: the cyclical nature of commoditization and the factors that allow resisting that cycle. We’ll cover those in future posts.

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

Ecosystem Mapping

A photo of the ski trail map at Masik Pass in North Korea. Photo Credit: Uri Tours

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

All the power of open source comes from throwing in with your neighbors, even the neighbors you don’t like very much. For most projects, the main reason to get involved in open source is to create productive relations with as many participants as possible, including rivals. Doing this well requires understanding who is in your ecosystem and how they relate to each other.

Whenever a team comes together to plan their open source strategy, they need a way to gather that understanding. They want to pool their knowledge and get everybody working from the same set of facts. The best tool we’ve found for this is ecosystem mapping.

There are many ways to visualize groups of stakeholders. We generally recommend starting with who and going from there to what. You can capture users, contributors, service and support providers, partners, funders, investors, deployers, integrators, and competing or adjacent efforts. Grab anything important to the questions directly in front of you, and don’t worry about being complete.

Ecosystem maps are lightweight. They should be messy, quick, and replaced often. The best way to make one is to hand-draw it on a large piece of paper or on a whiteboard, ideally as a group exercise. Snap a pic for future reference, but don’t bother taking the time to redraw them neatly. In a fast-moving project, the terrain these maps describe will shift often. And the reasons why you might draw a map will change even faster. It is not unusual to make several different maps of the same ecosystem in an afternoon.

Here is a simplified version of an ecosystem map drawn by the Arches Project. We reproduced it in Dia for this article, but normally we wouldn’t bother.

Ecosystem Map for the Arches Project

Notice how the diagram is primarily designed to highlight geography but also uses color and shape to distinguish between different types of participants.

The day the team drew this map, we wanted to understand where the project was succeeding geographically and how to support participants spreading the project into new communities. We suspected that having a set of committed users and service providers doing custom deploys were both important, so we mapped it to kick off a group discussion. As we talked through planning, we referred to the map, adjusted it at times and later even drew another map with a new focus. The diagram was a guide for conversation and let everybody agree on parameters quickly.

This is a map drawn of the Tor Project by Dlshad Othman:

Project Map of the Tor Project

This map is more centered on interactions with the Tor Project. It doesn’t mention geography at all, and it uses enclosing shapes to group types of participants in a venn-diagram. It shows roles and relationships with a heavy focus on the project itself.

There is no one right way to draw an ecosystem map. There are, however, some signs that your map is not setup to capture relationship complexity:

  • It is shaped like a star, with all your connections coming back to one central entity. 
  • It is more of a cloud than a map. If the map doesn’t depict relationships between entities, it’s not doing its job.
  • It tries to answer too many questions at once.  Maps are usually single-use snapshots designed to highlight one aspect of your ecosystem.  As two-dimensional representations made quickly with a limited palette of colors and symbols, these maps can show complex relationships, but not easily accommodate high-cardinality data views.

That said, do whatever works for your purpose! Experiment with different techniques, and draw maps that highlight different types of information. If you make a map using some of these techniques, let us know in the comments. We’d love to see pictures of maps that might turn into future examples as we continue to help people apply this approach to crafting open source strategy.

Thanks to Microsoft for sponsoring the Open Source At Large blog series, and also to Dlshad Othman and the Arches Project for kindly letting us use their maps as examples.

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!

Be Open From Day One, Not Day N.

Note: This is an updated version of an article I first wrote in 2011. The original site went offline for a while, and although it was later restored, thanks to heroic efforts by Philip Ashlock, I felt the article needed a new home, and wanted a chance to update it anyway. This version also incorporates some suggestions from V. David Zvenyach.

Over the years we’ve watched software projects of all sizes make the transition from closed-source to open source. The lesson we consistently draw from them is this:

If you’re running a software project and you plan to make it open source eventually, then just make it open source from the beginning of development.

Waiting will only create more work.

The longer a project is run in a closed-source mode, the harder it will be to open source later. Continue reading “Be Open From Day One, Not Day N.”

Field Guide To Open Source Project Archetypes

Open Source Archetypes report cover.Open source is a broad term that encompasses many different types of projects. There is a wide range of open source approaches, and sometimes it helps to think through how your open source approach matches your goals, resources, and environment. In many places we look, we see open source used as a catch-all term to refer to every project. We don’t have a common vocabulary to discuss open source in ways that take account of important differences.

OTS prepared a field guide to open source project archetypes with Mozilla that is a first step in addressing that problem. The report catalogs a number of open source archetypes we observe around the community. OTS and Mozilla have found these archetypes to be a useful resource when crafting strategy, weighing tradeoffs, and committing support to open source endeavors. Today, we share the results of this work with the community. Continue reading “Field Guide To Open Source Project Archetypes”

Decentralization: Worth The Wait

Ethan Zuckerman has a piece in Wired that says building decentralization tools is a sucker’s bet. He and his coauthors, Chelsea Barabas and Neha Narula, mention the FreedomBox, which I helped lead, as an example of how difficult this stuff is. They point to a list of things that make decentralized efforts prone to failure and conclude:

Our research—a combination of technical and historical analysis, and dozens of interviews with open web advocates—indicates that there is no straightforward technical solution to the problem of platform monopolies. Moreover, it’s not clear we can solve the nuanced issues of centralization by pushing for “re-decentralization” of publishing online. The reality is that most people do not want to run their own web servers or social network nodes. They want to engage with the web through friendlier platforms, and these platforms will be constrained by the same forces that drive consolidation today.

They point to a “better strategy” of policies aimed at “data portability, interoperability, and alternatives to advertising-based funding models”.

I’m no longer with FreedomBox, and none of what they write is wrong (I was one of the open web advocates they interviewed), but I wanted to chime in because there’s more to decentralization than seeking a “straightforward technical solution” and building a better social networking app. It’s true that we haven’t realized the grand vision of Diaspora and FreedomBox. They’re right that we need enlightened policy. We need the centralized platform monopolies to behave better. Those steps, though, won’t ever give people control over the means of communication. Without that control, we’ll always be at the mercy of Facebook or whatever comes next. Continue reading “Decentralization: Worth The Wait”

Report on GeoNode’s path to open source success

A map of flood zones in Haiti, rendered with GeoNode. Vulnerable areas are highlighted in red, over a base map showing a street map of Port-au-Prince. The mouse is hovering over a menu item which explains that "This map layer modelizes areas of frequent flooding for Port-au-Prince region."
Haiti Flood Zone map. Source: http://haitidata.org/maps/153/view.

Recently, OTS was asked to write a report about the GeoNode project by one of its primary sponsors, the Global Facility for Disaster Reduction and Recovery (GFDRR) a global partnership that is managed by the World Bank.  GeoNode is a facility for sharing and displaying geographical information.  It is “web-based, open source software that enables organizations to easily create catalogs of geospatial data, and that allows users to access, share, and visualize that data,” as we put it in our report. Continue reading “Report on GeoNode’s path to open source success”

Attending the Wontfix Cabal

Pile of stickers that read "wontfix_" in green monotype font on a black background.
Courtesy of Jess Frazelle.

GitHub hosted the “Wontfix Cabal” last week in San Francisco, and I was lucky enough to attend, thanks to a pointer from a friend.  The organizers, led by Jess Frazelle, conceived the gathering as a chance for people maintaining open source projects to discuss their particular difficulties and some strategies for addressing them.  About 100 maintainers took them up on it and convened in San Francisco.  At the beginning of the day, we compiled dozens of sticky notes worth of problems that come up in our various projects.  These ranged from tips for maintainers who had received the classic question “Is this project still maintained?” to “Ethics and Exploitation in Open Source.”  In a common unconference pattern, attendees voted on those topics.  The most popular topics were chosen to become discussion groups, and we split up for a morning session and an afternoon session. Continue reading “Attending the Wontfix Cabal”