Start as an Experiment

Start your InnerSource initiative as a time limited experiment to make it easier for managers unfamiliar with InnerSource to endorse and support the initiative.

An InnerSource initiative is considered but not started because management is unsure about its outcome and, as a result, is not willing to commit to an investment.

The company is considering to leverage InnerSource to increase the efficiency of collaboration on software projects. However, most managers are not familiar with the Open Source working model and are instead accustomed to hierarchical, top-down control style management. The idea of InnerSource is very popular with software developers in the company, not the least because many developers use or are actively developing Open Source software.

• Managers will want to validate the claims of improved collaboration through InnerSource before making a long term investment. This usually involves measuring the improvements.
• If the InnerSource initiative will likely have a huge uptake among developers and if many projects are likely to rely on it, a decision to shut it down will be very unpopular and therefore hard to make. The perceived resulting loss of control might deter some managers to even start with InnerSource.
• Implementing InnerSource style working models are often a radically departure from previously practiced working models. It is therefore likely, that existing, mandatory processes are no longer applicable and that appropriate governing processes are missing. The result might be that one has to operate in a regulatory, sometimes legal no-mans land. Examples are tax and export control related regulations in large corporations with multiple legal entities in multiple countries.

Declare the InnerSource initiative as a time limited experiment. Define and communicate the criteria for projects to join the InnerSource experiment. The criteria should be chosen such that they maximize the chances of building a healthy InnerSource community around the selected InnerSource projects. They should also help to ensure that the setting of the projects is such that they can later be used to gain externally valid insights into the effects of applying InnerSource. Examples for such criteria are

• Sufficient geographical distribution of developers
• Sufficient departmental mix of developers,
• Openness of communication within community,
• Career path based on merit within community,
• Democratic decision making within community.

Consider designating the end of the experiment a pivot, change or pause point to re-evaluate. Also consider establishing a Review Committee to increase the chances of management buy-in through participation. Depending on company culture, it might be helpful to accompany the experiment with appropriate metrics First Steps With Metrics. If the projects in the experiment don't provide a direct impact on the companies revenue, consider introducing Cross Team Valuation to highlight their value contributions.

Managers are able to kick start InnerSource for the following reasons:

• The experimental setup eases the need of managers to scrutinize the InnerSource program numbers in the same way that they would for typical projects.
• The possibility of failure of the experiment is understood and accepted. The personal risk for the supporting managers is minimized.
• Even in case of a failure, the setup ensures that the company will learn from the experiment.
• In case of success, the data gathered during the experiment will allow managers to make a longer lasting commitment to InnerSource.

Participants in the InnerSource experiment are now conscious of the fact that they have to prove to management that InnerSource yields the promised benefits. It will therefore help to focus work on those activites which provide the most demonstrable value thus increasing the chances of success.

Finally, starting as an experiment makes it much easier to sidestep regulations and forces such as tool and process policies which could decrease the chances of success.

• Trial Run (from the book Fearless Change)

• Robert Bosch GmbH (globally distributed software development)

• Georg Grütter (Robert Bosch GmbH)

Proven Pattern

• Jason Zink (Robert Bosch GmbH)
• Diogo Fregonese (Robert Bosch GmbH)
• Robert Hansel (Robert Bosch GmbH)
• Hans Malte Kern (Robert Bosch GmbH)
• Russ Rutledge (Nike)
• Tim Yao (Nokia)
• Clint Cain (Optum)