This article explains how to walk through, measure, and define strategies collaboratively in an open source community.

“If you don’t know where you are going, you’ll end up someplace else.” Yogi Berra

Open source projects are generally started as a way to scratch one’s itch and frankly that’s one of its greatest attributes. Getting code down provides a tangible method to express an idea, showcase a need, and solve a problem. It avoids over thinking and getting a project stuck in analysis-paralysis, letting the project pragmatically solve the problem at hand.

Next, a project starts to scale up and gets many varied users and contributions, with plenty of opinions along the way. That leads to the next big challenge how does a project start to build a strategic vision? In this article, I’ll describe how to walk through, measure, and define strategies collaboratively, in a community.

Strategy may seem like a buzzword of the corporate world rather something that an open source community would embrace, so I suggest stripping away the negative actions that are sometimes associated with this word (e.g., staff reductions, discontinuations, office closures). Strategy done right isn’t a tool to justify unfortunate actions but to help show focus and where each community member can contribute.

A good application of strategy achieves the following:

  • Why the project exists?
  • What the project looks to achieve?
  • What is the ideal end state for a project is.

The key to success is answering these questions as simply as possible, with consensus from your community. Let’s look at some ways to do this.

Setting a mission and vision

Efforts and courage are not enough without purpose and direction.” John F. Kennedy

All strategic planning starts off with setting a course for where the project wants to go. The two tools used here are Mission and Vision. They are complementary terms, describing both the reason a project exists (mission) and the ideal end state for a project (vision).

A great way to start this exercise with the intent of driving consensus is by asking each key community member the following questions:

  • What drove you to join and/or contribute the project?
  • How do you define success for your participation?

In a company, you’d ask your customers these questions usually. But in open source projects, the customers are the project participants and their time investment is what makes the project a success.

Driving consensus means capturing the answers to these questions and looking for themes across them. At R Consortium, for example, I created a shared doc for the board to review each member’s answers to the above questions, and followed up with a meeting to review for specific themes that came from those insights.

Building a mission flows really well from this exercise. The key thing is to keep the wording of your mission short and concise. Open Mainframe Project has done this really well. Here’s their mission:

Build community and adoption of Open Source on the mainframe by:

  • Eliminating barriers to Open Source adoption on the mainframe
  • Demonstrating value of the mainframe on technical and business levels
  • Strengthening collaboration points and resources for the community to thrive

At 40 words, it passes the key eye tests of a good mission statement; it’s clear, concise, and demonstrates the useful value the project aims for.

The next stage is to reflect on the mission statement and ask yourself this question: What is the ideal outcome if the project accomplishes its mission? That can be a tough one to tackle. Open Mainframe Project put together its vision really well:

Linux on the Mainframe as the standard for enterprise class systems and applications.

You could read that as a BHAG, but it’s really more of a vision, because it describes a future state that is what would be created by the mission being fully accomplished. It also hits the key pieces to an effective vision it’s only 13 words, inspirational, clear, memorable, and concise.

Mission and vision add clarity on the who, what, why, and how for your project. But, how do you set a course for getting there?

Goals, Objectives, Actions, and Results

“I don’t focus on what I’m up against. I focus on my goals and I try to ignore the rest.” Venus Williams

Looking at a mission and vision can get overwhelming, so breaking them down into smaller chunks can help the project determine how to get started. This also helps prioritize actions, either by importance or by opportunity. Most importantly, this step gives you guidance on what things to focus on for a period of time, and which to put off.

There are lots of methods of time bound planning, but the method I think works the best for projects is what I’ve dubbed the GOAR method. It’s an acronym that stands for:

  • Goals define what the project is striving for and likely would align and support the mission. Examples might be “Grow a diverse contributor base” or “Become the leading project for X.” Goals are aspirational and set direction.
  • Objectives show how you measure a goal’s completion, and should be clear and measurable. You might also have multiple objectives to measure the completion of a goal. For example, the goal “Grow a diverse contributor base” might have objectives such as “Have X total contributors monthly” and “Have contributors representing Y different organizations.”
  • Actions are what the project plans to do to complete an objective. This is where you get tactical on exactly what needs done. For example, the objective “Have contributors representing Y different organizations” would like have actions of reaching out to interested organizations using the project, having existing contributors mentor new mentors, and providing incentives for first time contributors.
  • Results come along the way, showing progress both positive and negative from the actions.

You can put these into a table like this:

Goals Objectives Actions Results
Grow a diverse contributor base     Have X total contributors monthly
  • Existing contributors mentor new mentors
  • Providing incentives for first time contributors
Have contributors representing Y different organizations
  • Reach out to interested organizations using the project

In large organizations, monthly or quarterly goals and objectives often make sense; however, on open source projects, these time frames are unrealistic. Six- even 12-month tracking allows the project leadership to focus on driving efforts at a high level by nurturing the community along.

The end result is a rubric that provides clear vision on where the project is going. It also lets community members more easily find ways to contribute. For example, your project may include someone who knows a few organizations using the project this person could help introduce those developers to the codebase and guide them through their first commit.

What happens if the project doesn’t hit the goals?

“I have not failed. I’ve just found 10,000 ways that won’t work.” — Thomas A. Edison

Figuring out what is within the capability of an organization — whether Fortune 500 or a small open source project — is hard. And, sometimes the expectations or market conditions change along the way. Does that make the strategy planning process a failure? Absolutely not!

Instead, you can use this experience as a way to better understand your project’s velocity, its impact, and its community, and perhaps as a way to prioritize what is important and what’s not.

skydivers in the air

Don’t do fly-by contributions. Choose the right project, assign developers to consistently contribute upstream, and start to realize real influence and value from your open source investment.

When The Linux Foundation started OpenDaylight, our first networking project, nobody that I was working with had ever done open source before. Four years later there has been a significant shift in the entire networking industry. And we’re watching this transformation happen from one industry to the next.

In those four years, I’ve also witnessed many large organizations with significant engineering investments blunder their way into open source. For example, they might just fly in and drop 20,000 awesome lines of code into a project and then get upset that nobody actually picked it up.

The reality is that no matter how big and important your organization is, code doesn’t get picked up if you have no reputation in the open source community. The community must believe that the organization will actually be around to help support that and continue to evolve the code.

So if you want to be part of the industry transformation occurring now with open source — and your company’s future does depend on it — here are some basic steps for organizations new to open source to gain influence within an open source community.

Getting Value out of Open Source

First, let’s talk a little about why you want to gain influence in open source projects in the first place. There are three different tiers of value that individuals and organizations get from open source code.

  1. Take it and use it. (Great value.) It’s free, right? And there’s great value in that because you didn’t have to write the code. A lot of this software has been around for a long period of time, so you know it’s stable and it’s reliable, so it’s just a great resource.
  2. Customize it for your specific needs and contribute those changes back to the project. (Higher value.) You can continue to evolve with that project, pulling in changes that others have made that give great benefit to you as well. (See our guide to Participating in Open Source Communities for more.)
  3. Recognize this transformation occurring in your industry and rely on the platform that everybody in the industry is working on together. (Highest value.) When you start to lead feature sets and activities in those projects, you have a tremendous influence on what’s happening next.

The way we write these applications and the way we choose to implement them ultimately becomes the foundational aspects of our systems that we’ll be using for the next five, 10, 15, 20 years. To get the most value from open source within your organization, you want to help influence the direction of these foundational technologies.

Steps for Gaining Influence in Open Source

So the first step in building influence is: Pick the right project. Start by asking yourself, do I need to modify this code and what license is this code under? If it’s under a license that you can’t use in your particular situation, that code is not going to be applicable to you.

Next, if you need to modify the code (and often you don’t) and want the codebase to evolve with your changes, it’s very helpful to actually work with a community that would take your changes. You’ll need to look at who controls the project, what’s the governance, and who owns the copyright. Look at the project’s charter documents, join their IRC channel and their mailing list. Propose to do something and see what kind of a response comes back. Do the triage to figure out if it’s a project that’s going to work for you or not.

There are some communities that, even though it’s under an open source license, you have to assign your copyright over to some commercial entity, and only individuals from that organization are actually allowed to be committers. There are a variety of ways that projects can be structured that significantly inhibit your ability to make contributions. Understand if those hurdles exist and avoid projects that operate that way.

Everything within The Linux Foundation is structured in a way that allows for diverse contributions. We do that because we’re trying to get an industry to work together collaboratively to address an industry-wide challenge or opportunity.

But today, there is a certain amount of “open-source washing.” Some organizations will say “Hey, we’re going to put this into open source,” but it’s a significantly debilitated version of what they’re really trying to sell you in a commercial environment.

Now, at the same time, there are projects that are started by individual organizations where they really are trying to build a community and a collaborative environment. So just because the individual organization is sponsoring that activity doesn’t mean you shouldn’t engage, but you need to investigate.

Once you have chosen the right project, you will need to assign talented developers to work upstream. Very often when companies get into open source for the first time, they’ll create an entire group, 10, 15, 20 folks that are taking the code and doing stuff with it to augment it for their internal project and they’re not contributing anything back to the project. That invariably will get you into trouble six to 24 months down the road as the upstream open source project continues to evolve. The delta that you have created with your internal version becomes significantly disparate from the mainline code. Every time a new version comes out from the upstream, your team will spend more and more time actually back-porting their modifications into the upstream as opposed to doing new and meaningful development.

Put developers on the core of the project. So many organizations want to add new features that are going to be important to them, and that’s great. But if the core isn’t stable, reliable, and scalable then your features don’t really matter. Also, consider putting developers in support and infrastructure roles such as testing and release management or release engineering.  

Gaining Influence Through Credibility

All of this will help your organization gain credibility in the project community so that when your organization wants to do something down the road that might be a little off the wall, you end up having more influence and the ability to do that. It’s more likely that when you submit that 20,000 awesome lines of code the community will look at all this great work that your organization has done for this project and say, “Let’s support them in what they’re trying to do as best we can.”

Don’t be that organization that does fly-by contributions. Choose the right project, assign developers to consistently contribute upstream, and start to realize real influence and value from your open source investment.