In recent years, an increasing number of organizations, often non-technology companies, have kept a keen eye on open source. Although they may be unable to use open source to the fullest extent in their products and services, they are interested in bringing the principles of open source within the walls of their organization. This “innersource” concept can provide a number of organizational benefits.

As a consultant who helps build both internal and external communities in companies, I find the major challenge facing organizations is how to put an innersource program in place, deploy resources effectively, and build growth in the program.

To help you get started, I present a high-level model that shows how you can build a consistent, predictable, and sustainable innersource program. Take this model, adjust to taste, and build a thriving community in your organization.

Understand

Fundamentally, innersource is a cultural change for a company. Although many people think of this as a traditionally software engineering workflow challenge, you need to focus instead on building an asynchronous, permissive, meritocratic, and collaborative environment. Of course, this encompasses development workflow, but is not limited to it.

The challenge with cultural change is that culture is an amorphous mass of ideas, opinions, habits, fears, dreams, values, and more. Before you can integrate innersource into a company, you must understand the drivers in the existing culture, and then ensure you consider these as you roll out the innersource program.

1. Understand process and collaboration

At the core of how people work together are collaborative infrastructure and processes. These include code hosting, peer review, continuous integration, automated testing, documentation creation, knowledgebases, incentive programs, and more. You should understand all of these details, how they fit together, and where the shortfalls lay in both the wider execution of these pieces and the experiences of staff using them.

I recommend breaking the organization up by teams and then put together a map of:

• What each team consumes
• What each team produces
• How each team works
• How they interface with other teams
• The benefits and disadvantages of current systems

2. Understand the people and drivers

Outside of the collaborative nuts and bolts of how things get done, understanding the people involved is equally critical. A company brings together a multitude of people, personalities, and perspectives. You need to understand them, their goals, their fears, and their agendas. Cultural change must be mindful of the realities of the environment in which it operates. You can’t build an innersource program by dictating it to people—you need to build something that people want to use and that encourages the behaviors you want to see.

I recommend building your own organizational chart that shows:

• the breakdown of influence (key stakeholders and decision makers),
• where people deliver work (teams and key employees), and
• individual agendas and goals with each person (stop energy, people gunning for certain outcomes, intrinsic and extrinsic reward motivations, etc.).

Plan

With a firm understanding of the current environment, you then can build a roadmap of your route to a smooth, efficient, inclusive, and enjoyable innersource environment.

3. Create a strategic plan

Your first step is to build an overall strategy, a complex undertaking as you can imagine. Integrating open source principles in a company involves a huge array of different considerations, such as developer workflow, infrastructure, communication, policy (such as openness and transparency), incentivization models, segmented engagement, wider messaging, governance, and more.

Not only do you have much to do, but as your work priorities will vary (some projects are more urgently required than others), you will have limited resources, and some colleagues in the company will have limited buy-in or even seek to block the project.

To get people onboard and involved, you need to:

• build a strategy;
• define priorities;
• get a sense of resourcing; and
• factor in messaging, engagement, and roll-out for each of these pieces.

I recommend building out an overall wider strategic plan that maps to the next one or two years, covering the key areas of focus. Next, break that plan into shorter execution cycles in which you pull out key goals from the broader plan and map them to practical deliverables with metrics. This will form your backlog.

4. Build a backlog

Fundamentally, strategy is a map that tells you where you want to go. Strategy needs to be converted into practical projects and deliverables that you can apply resources to, such as development time, funds, and so on. The challenge is that each strategic objective will invariably involve a multitude of these sub-projects and goals. The best way to manage this situation is with a backlog.

Put simply, a backlog is a big, shared to-do list. When you have built out your strategy, you map all the individual projects to the backlog. This provides a place where you can discuss, refine, and improve individual deliverables. When some of these deliverables are ready for implementation, they can be pulled off the backlog into an active work plan and have resources assigned. This means that you can evolve the implementation of your strategy in the backlog, even when not actively applying resources.

5. Develop a maturity model

One of the challenges I regularly see when I work with clients who want to build innersource into their organizations is that they don’t know what success looks like. Now, that sentence right there sounds like business book nonsense, but this issue is real. For example, if you want to improve developer efficiency when it comes to code review, how do you determine that this goal was achieved? How do you measure the work and determine which measurements mean you’ve nailed it? For many of these issues, you are building qualitative cultural change. How do we measure that?

This challenge is exacerbated by your different audiences. Although those involved in the implementation of this work will want to get to the nitty gritty of what success looks like, senior management and stakeholders won’t want the details, but instead only want information on important trends. A useful approach to this is a “maturity model.”

A maturity model breaks the different evolutionary phases of a solution into a set of expectations of what success looks like. I tend to think of these different chronological stages, in order:

1. Unaware: The company is unaware of the solution.
2. Explored: The solution is being explored.
3. Defined: The solution is defined and executed.
4. Adopted: The solution is adopted in the company.
5. Optimized: The solution is being optimized and improved.

For each of these you would say what to expect. For example, if you build code review into the company, the entry for “Explored” could be “A small proportion of teams are actively experimenting with code review in non-critical codebases.”

Execute

With a strategy, backlog, and maturity model in place, you know what you need to do. Now you need to make these projects happen.

6. Deliver priority projects

With your backlog in place, your first step is to decide which projects to name as priorities in your work plan. Deciding this is dependent on which work must be performed most urgently and what resources are currently available. Although the urgency of the work is important, resources are the really defining criteria here—we can’t build things with nothing.

I recommend you do this on a cadence (every two weeks, monthly, quarterly, etc.). Bring together key leaders for the program, review the backlog, define resourcing, and then finalize the work plan.

7. Communicate to different groups

With your work plan in place you can start delivery. You should be defining milestones, metrics, and regularly reviewing deliverables. Given the cultural implications for this work, communication—and in some cases, over-communication—is key. We want to ensure the wider company, key stakeholders, leadership, and others have a good sense of:

• what the strategy is,
• what the work plan is,
• how that work is being delivered, and
• what the results of the work are.

Bear in mind that these various audiences will have different communication needs. Senior leadership will need the overview and results, key leaders will require more depth, and team leads will want the details.

You will need to create a way of pulling out these overall details, design the communication for the right audiences, and update your audiences regularly (with weekly reports, for example). Also, be sure to message the entire company regularly where appropriate.

Review and improve

Bringing innersource into a company is an imperfect art and science. Companies vary, people vary, and approaches vary. You have to roll a program that meets the specific needs that you sought to understand at the beginning of this process.

As such, regularly evaluating your work and assessing how well it is going is critical, because you will need to make suitable changes. Doing this evaluation isn’t easy; it can tap into people’s fear of failure, but conquering such fear is important. Some things you do will not go well, and others will deliver sub-optimal results. Identifying the flaws that negatively affect your work and rectifying them is the point of your analysis.

8. Gather quantitative data

A first step is to gather data—in other words, numbers. For each project you work on, define a set of metrics you want to track and how you will read those metrics to determine success. Examples of these metrics are usage, contributions, code, messages, participation, and other examples. You should never bring a project into the work plan unless you have a key way to measure it.

9. Survey your users

Analyzing numbers is convenient, because we usually have computers do all the work, but we also need to track human elements, such as happiness, empowerment, inclusivity, and other areas. Non-empirical analysis is difficult to do as these things don’t usually map to numbers well.

A useful way to get data is to run an anonymous survey regularly that asks people how they feel about these human elements of the innersource experience. The staff must feel comfortable if they are to be critical. You need to give them express permission to criticize without consequences.

As important as the execution of the survey is, the wording of the questions and options is key, too. Wording and selections can often inadvertently influence responses, so I recommend you have a few people feed into the structure of the survey.

10. Update the strategy

Once you have this data, ask yourself and the team hard questions about what trends and patterns these illustrate and how you can refine the overall strategy, re-organize the backlog, and adjust how projects are prioritized, built, and managed with others. Of course, helping to bring innersource into a company is a complicated endeavor with countless different details, but I hope this article provided an overall framework in which you can fill in the gaps with the pieces that relate to your specific organization. Feel free to reach out to me if you get stuck—I am always happy to help!