Title

Common Requirements

Patlet

Common code in a shared repository isn't meeting the needs of all the project-teams that want to use it; this is solved through requirements alignment and refactoring.

Problem

The common code in the shared repository isn't meeting the needs of all the projects that want to use it.

Context

• Many projects are trying to use common code. There is a shared repository that all the projects access.

• Someone (or some project) wrote the code in the first place and contributed it to the repository.

• The common code is a small percentage of the overall deliverable from any of the projects.

• Each project has its own delivery schedule, set of deliverables and customers.

• This pattern applies in any of these situations:

  • there is a Strong Code Owner i.e. all changes to the shared repository have to be approved by the repo owner

  • there is weak code ownership i.e. no one really owns the code

  • there is no Benevolent Sponsor i.e. no organization or executive is providing resources to organize the common code in an InnerSource fashion

Forces

The project that made the code available has one set of needs. Its needs are similar to what some of the receiving organization wants, but not quite the same. Requirements on code should be derivable from real customer needs.

The needs of different customers are generally quite similar; however they might be expressed differently or weighted differently between customers. An example might be how some customers want some result presented in one way while others want it presented in the reverse order. It is simple to do the translation between them, but requires additional coding for one of the cases and as a result the module that computes the result can't be reused by both customers.

Many customers want the supplier to help them know what they need. The company has many “Systems Engineers” writing requirements for the products. These requirements are supposed to be a distillation of customer needs to guide development of the product. Reusing code is an important goal to save the company time and money.

Solution

There are two aspects to solving this problem which should be done in parallel:

1. Align the requirements of the projects so that the code that meets the requirements for one project also meets the needs for the other projects.

2. Refactor the code into smaller pieces for which the many using projects can agree upon requirements.

Additionally, take advantage of customers expecting the supplier to help elucidate requirements. Bring about the alignment of requirements during the customer negotiations and influence the customers requirements rather than changing the component.

In the example presented above, the supplier helps both customers realize that they want the same thing, and it will save everyone effort (and money) if they agree to accept the result in the same format.

Resulting Context

This might require negotiating requirements changes with the customer. The changes might also require involvement by the sales teams and product managers to get alignment on the requirements. The customer might need incentives, such as discounts, to agree to the changes.

A related challenge (and possible new pattern) is a circular story-writing exercise reported at one company employing InnerSource. In short:

• The developers write a story to solve a problem in one way.

• The program managers rewrite the story to better express their needs - keeping the essence the same. By the time it returns to developers though they don't recognize it as what they wanted to do in the first place and so balk at implementing it.

• The solution to this pattern is to have more seats around the planning table so that story modifications are understood across the project, not just in the developer or program manager camps.

Known Instances

• Large telecommunications provider

Status

• Structured

Author

Robert Hanmer

Acknowledgments

• Manrique Lopez

• Daniel Izquierdo

• Tim Yao

• Sebastian Spier

Title

Cross-Team Project Valuation

Patlet

It's hard to sell the value of cross-team InnerSource projects that don't provide a direct impact on company revenue. Here's a data-driven way to represent your project that both articulates its value and amplifies it.

Context

• You are responsible for a cross-team that serves as a platform for others in the company.

• The cross-team project does not deliver any direct value for company revenue.

Problem

Cross-team projects can potentially have a very large impact on the company yet are difficult to represent in a data-driven fashion. As a result, it is easy and common to either pursue projects that do not provide real value or to underfund what would otherwise produce great value.

Forces

• Projects need to show value (objective or subjective) to company leadership in order to be funded.

• Cross-team project value is dispersed across multiple end business units.

• Due to this dispersal, cross-team project value is difficult to measure directly.

Solution

Set in place a pattern and model of how to value cross-team projects. Such models give us the tool that we need to focus and amplify high-value collaboration for the company.

The core of all cross-team project value is the idea that we can get more done together than apart. Ascribing value to a cross-team effort is an exercise in quantifying how much more is getting done together. The exact delta in productivity will vary by domain and project. There is a common process, by which you can create a model to calculate it.

Explanation

Assemble a small team of subject matter experts in your domain. Using that team of experts, estimate 4 things about each consumer of your project output:

• How long does it take them to consume your project output?

• How long would it otherwise take them to home-roll the value of your project output for themselves?

• What percentage of your project output is actually useful for them?

• How much time on an ongoing basis (ideally per-use) would they otherwise spend maintaining their home-rolled solution?

When making these estimations, it's impossible to know with high accuracy exactly how long any activities take. That's not your goal. Rather than exactness, you should strive to set a worst-case bound on these estimates. The idea is for the group of experts to be able to say to each other, "We don't know exactly how long it would take, but we can all agree it's at least this much." Specifically, you should estimate a maximum reasonable time to consume your project output and minimum reasonable times for consumers to otherwise home-roll, use and maintain their own solutions.

One note about cost of "rolling your own solution" (home-roll). The cost to home-roll a solution is NOT necessarily (very unlikely, in fact) the same as the cost of making a shared solution. Oftentimes for the same functionality the modularity and quality involved in building a cross-team, shared solution makes it a noticeably higher investment than a quick, hard-coded implementation used just once.

Formula

Once you have your worst-case bounds you can value your cross-team project output during a given time frame via the simple formula:

[Time Saved] - [Time Invested]

([Count of New On-boardings] * [Cost to Home-Roll] * [Percent Useful Functionality] + [Count of Usages] * [Maintenance Cost Per Use]) - ([Count of New On-boardings] * [Cost to On-board])

[Count of New On-boardings] * ([Cost to Home-Roll] * [Percent Useful Functionality] - [Cost to On-board]) + [Count of Usages] * [Maintenance Cost Per Use]

Commentary

Despite the trappings of rigor, this process does not yield an exact way to measure cross-team project output. In-practice, however, it does give a framework by which you can make a sound decision at how to fund this work. After having good, reasonable data according to the above explanation, you should fund dedicated development hours toward running the project up to at least of the lesser of the following three levels:

1. The raw hours saved by the formula above. Since we're all sure that the formula will produce a number that is below the true number of hours saved, you can have confidence that funding the project up to that point is a sure win for you.

2. The amount of time that it takes to support inner sourced contributions to cross-team projects. Since the contributor would likely have done the work anyway in a one-off fashion, it is worth it to fund the time it takes to facilitate their work going into a shared location.

3. Whatever feels good to you. One intentional side effect of having a valuation formula is that it naturally forces measurement of the key points of usage that provide value to consumers.

Those measurements can be understood and consumed in their raw form to provide you with a gut-feel idea of how valuable is the project.

Some may be concerned about the lack of accuracy in this valuation approach. It's okay for this process to not give an exact measurement. It just needs to be accurate enough to accomplish 2 purposes:

1. Give a means to represent the value of what is happening to those that are organizing and funding cross-team efforts.

2. Help those involved to know what areas of cross-team effort are higher priority to pursue based on their value.

In-practice, as long as these valuations are within an order-of-magnitude of reality and one-another, they are sufficiently accurate to fill these purposes. They will provide a head-and-shoulders improvement in on-the-ground results over the ad hoc valuations (and resultant effects) described in the Problem section at the beginning of this document.

Resulting Context

• Data-driven means to discuss the value and funding of the cross-team project with leadership.

• Key metrics around the cross-team project instrumented in raw form.

• Defining how the cross-team project provides value tends to lead to it actually producing greater value for the company.

• Generally-successful project and "buzz" around it.

Known Instances

• Nike

Status

• Structured

• Proven in multiple domains.

Authors

• Russ Rutledge

Acknowledgments

• Jeremiah Wright for teaching me to think about cross-team projects as an internal business dealing in the currency of developer time.

Title

30 Day Warranty

Patlet

When accepting contributions from outside of your own team, there is a natural aversion to taking responsibility for code not written by the team itself. Through the 30 Day Warranty the contributing team consents to provide bug fixes to the receiving team, which will increase the level of trust between both teams and makes it more likely that contributions get accepted.

Problem

A team develops a component which is used throughout an organization. This team resists accepting or outright rejects contributions (feature requests). This behavior blocks progress and leads to frequent disruption from escalations.

Context

• Teams depend on another team accepting their contributions so that a component produced by the receiving team can be used by the contributing team.

• The receiving team does not have the resources, knowledge, permission, and/or inclination to write the contributed component/feature themselves.

Forces

• There is distrust of contributions due to a past history of cheating: teams submitted half finished contributions and subsequently filed requests for fixes that make it ready for use in production.

• If code is contributed from outside the team, the team has the natural suspicion that the other team does not know how to write code that would meet the receiving team's expectations.

• Each team looks first to help its own leaders achieve their own goals. This direction of loyalty can complicate resolution of this problem.

• There is a natural aversion to taking responsibility for code not written by oneself.

• Contributed code needs to be heavily rewritten before being accepted into the codebase.

• There is the fear of the contributors not being available for support with fixing bugs after the time on contribution.

• Teams fear contributed code will lead to high(er) maintenance costs but do not know how to control for that.

• Receiving teams may fear that teaching others how to contribute code will expose technical debt in their system and that visibility may be damaging.

• Receiving teams may not believe that they will get acceptable code no matter how much mentoring they provide.

• Either team may not feel confident in measuring risks or certifying that they are mitigated in a contribution; the system itself is somewhat brittle (may not be ways to fully test and catch all problems).

Solution

Address the fears of both the receiving and the contributing teams by establishing a 30 day warranty period starting with the time the contributed code goes into production. During this warranty period the contributing team consents to provide bug fixes to the receiving team.

Note that the warranty period could be 45, 60, or 100 days too. The duration may vary based upon the constraints of the project, the software life cycle of the project, commitments to customers, and other factors.

In addition it helps to provide clear contribution guidelines, spelling out the expectations of the receiving team and the contributing team.

Resulting Context

• The receiving team is willing to accept contributions and able to share the workload of initial adaptations/fixes.

• Increased transparency and fairness.

• Keeps escalations from becoming too heavyweight.

Known Instances

• PayPal Tried this and it was proven successful.

• GitHub internally uses this pattern with a modified warranty timeline of 6 weeks.

• Microsoft recommends this pattern as a principle - teams set their own specific time target matching their needs and confidence.

• SAP leverages this pattern in their InnerSource-based Everest project to transform collaboration, ensuring contributions are not just accepted but also supported, enhancing trust and driving forward the culture of shared responsibility and innovation. See: InnerSource: First Contribution Explored

Authors

• Cedric Williams

Acknowledgments

• Dirk-Willem van Gulik

• Padma Sudarsan

• Klaas-Jan Stol

• Georg Grütter

Status

• Structured

• Drafted at the 2017 Spring InnerSource Summit; reviewed 18 July 2017.

Variants

• Ensure cooperation of dependent teams by making them a community by having more than one, meritocratically appointed "Trusted Committers" (TCs) take responsibility.

• Introduction

• Table of Contents

• Explore Patterns

• Contribute to this book

Patterns

• 30 Day Warranty - When accepting contributions from outside of your own team, there is a natural aversion to taking responsibility for code not written by the team itself. Through the 30 Day Warranty the contributing team consents to provide bug fixes to the receiving team, which will increase the level of trust between both teams and makes it more likely that contributions get accepted.

• Common Requirements - Common code in a shared repository isn't meeting the needs of all the project-teams that want to use it; this is solved through requirements alignment and refactoring.

• Communication Tooling - The users of an InnerSource project have trouble getting help and getting in touch with the host team. By consistently using asynchronous communication tooling, the project makes discussions visible, archived and searchable, leading to an improved level of support for users.

• Contracted Contributor - Associates wanting to contribute to InnerSource are discouraged from doing so by their line management. Relief is provided by formal contracts and agreements.

• Core Team - Even when an InnerSource project is widely needed, contributions and usage may be hindered because the project is difficult to work with. Establish a core team that is dedicated to take care of the project's fundamental items. Their work enables contributors to add and use the features that provide value to their scenarios.

• Cross-Team Project Valuation - It's hard to sell the value of cross-team InnerSource projects that don't provide a direct impact on company revenue. Here's a data-driven way to represent your project that both articulates its value and amplifies it.

• Dedicated Community Leader - Select people with both communications and technical skills to lead the communities to ensure success in starting an InnerSource initiative.

• Document your Guiding Principles - The usual InnerSource explanation of "applying open source best practices inside an organization" does not work well with people lacking an open source background. As a remedy the most important principles of InnerSource get documented and published widely.

• Explicit Governance Levels - Different teams within an organization use InnerSource practices in varying ways, leading to confusion and inefficiencies due to inconsistent expectations of collaboration and contribution rights. Establish centrally documented governance levels that define the extent of influence contributing teams can have on a project, improving clarity for contributors and host teams alike.

• Extensions for Sustainable Growth - An InnerSource project is receiving too many contributions, making maintenance difficult. By offering an extension mechanism outside of the core project, the maintainers enable scaling of project capabilities with minimal cost and maintenance overhead.

• Gig Marketplace - Establish a marketplace by creating an intranet website that lists specific InnerSource project needs as "Gigs" with explicit time and skill requirements. This will enable managers to better understand their employee’s time commitment and professional benefits thereby increasing the likelihood of garnering approval to make InnerSource contributions.

• Group Support - What happens if a team or individual no longer supports an InnerSource project? Keep the project alive by forming a group of interested individuals.

• InnerSource License - Two legal entities that belong to the same organization want to share software source code with each other but they are concerned about the implications in terms of legal liabilities or cross-company accounting. An InnerSource License provides a reusable legal framework for the sharing of source code within the organization. This opens up new collaboration options, and makes the rights and obligations of the involved legal entities explicit.

• InnerSource Portal - Potential contributors cannot easily discover InnerSource projects that they are interested in. By creating an intranet website that indexes all available InnerSource project information you enable contributors to learn about projects that might interest them and InnerSource project owners to attract an outside audience.

• Issue Tracker Use Cases - The InnerSource host team fails to make not only plans and progress but also context for changes transparent. This is solved by increasing the use cases for the project issue tracker to also serve brainstorming, implementation discussion, and feature design.

• Maturity Model - Teams have started adopting InnerSource. The practice is spreading to multiple departments. However, the understanding of what constitutes an InnerSource project varies. The solution is to provide a maturity model to allow for teams to go through a self check and discover patterns and practices that they are not yet aware of.

• Praise Participants - When you receive an InnerSource contribution, it's important to thank the contributor for their time and effort. Extending your gratiutude not only effectively acknowledges the contribution but also engenders further engagement from the contributor and others. Praising contributors' positive contributions to your InnerSource project motivates those contributors (and their managers) to continue investing in the effort.

• Repository Activity Score - Potential contributors want to find active InnerSource projects in need of their help. By calculating a repository activity score for each project, a ranked list of projects can be created (e.g. on the InnerSource Portal), so that potential contributors can more easily determine which project they want to contribute to.

• Review Committee - The InnerSource working model is a radical departure from more traditional approaches, for developers and managers alike. By establishing a review committee as an interface between the InnerSource initiative and all senior managers of business units participating in it, the latter are more likely to familiarize themselves with the initiative and support it, as it affords them a certain level of oversight and control without fostering micromanagement.

• Service vs. Library - Teams in a DevOps environment may be reluctant to work across team boundaries on common code bases due to ambiguity over who will be responsible for responding to service downtime. The solution is to realize that often it's possible to either deploy the same service in independent environments with separate escalation chains in the event of service downtime or factor a lot of shared code out into one library and collaborate on that.

• Standard Base Documentation - New contributors to an InnerSource project have a hard time figuring out who maintains the project, what to work on, and how to contribute. Providing documentation in standard files like README.md/CONTRIBUTING.md/COMMUNICATION.md enables a self service process for new contributors, so that they can find the answers to the most common questions on their own.

• Standard Release Process - Teams may hesitate to adopt an InnerSource project if they are unsure of its maturity. To address this, consistent release notes and published artifacts are crucial. These practices showcase a strong dedication to the project, instilling confidence and assuring users of ongoing commitment to sustainable and well-managed software.

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

• Transparent Cross-Team Decision Making using RFCs - InnerSource projects that want to achieve high participation rates and make the best possible decisions for everybody involved need to find ways to create participatory systems throughout the full software lifecycle. Publishing internal Requests for Comments (RFCs) documents allows for discussions early on in the design process, and increases the chances to build solutions with a high degree of commitment from all involved parties.

• Trusted Committer - Many InnerSource projects will find themselves in a situation where they consistently receive feedback, features, and bug-fixes from contributors. In these situations, project maintainers seek ways to recognize and reward the work of the contributor above and beyond single contributions.

Appendix

• Pattern Template

• Glossary

• Extras

  • README Template

  • CONTRIBUTING Template

  • COMMUNICATION Template

  • RFC Template

Resources

• This book on GitHub

• InnerSource Commons

Title

Communication Tooling

Patlet

The users of an InnerSource project have trouble getting help and getting in touch with the host team. By consistently using asynchronous communication tooling, the project makes discussions visible, archived and searchable, leading to an improved level of support for users.

Problem

A team is open to receiving contributions from downstream users of their component. Coordination and communication happens in an ad hoc fashion though leading to incoherent information being shared, delays in answers received, contributors pinging multiple host team members before receiving a definitive answer.

Context

• A team depends on another team's component.

• It would like to make contributions to that component.

• Even when it happens in writing, communication happens in a 1-on-1 fashion.

Forces

• The host team is interested in receiving contributions and willing to mentor contributors.

• Teams have a strong verbal communication culture and are inexperienced with setting up project specific asynchronous communication channels.

• Communication channels may be aligned with specific groups that should be reached but not by communication purpose.

Solution

The host team should provide company-public, archived, searchable, linkable communication channels that anyone in the company can subscribe to, as there are measurable benefits to supporting open, written communications channels.

The goal when streamlining communication channels for InnerSource projects should be to align communication around topics, not around certain sets of people.

A project should set up the following communication tooling:

2. public discussion channel(s) that come with less rigid a structure. Typically, this will be mailing lists, online forums, Q&A systems or even archived chat channels. Usually it is enough to start with just one channel for the project. If traffic increases too much it is helpful to split discussions about project usage from discussions about project development.

While communication can happen outside of those written channels, as much information as possible should be brought back to the asynchronous channels.

The host team members need to make an effort to direct questions that they receive personally (e.g. via email or private chat messages) back to official communication channels.

Resulting Context

With communication happening in the open others can easily follow project progress and get active contributing. Others lurking and reading lowers the barrier to get involved raising the likelihood of receiving contributions.

With questions being answered in public more people can add their perspective leading to a complete picture - this includes not only host team members, but also users of the project.

Keeping communication in asynchronous channels allows for participants on different schedules - either due to different time zones or due to different routines, meeting schedules, team routines - to meaningfully contribute to the project.

Answering questions in those channels means that not only other team members can listen in and provide additional information, it also means that other users with the same question see (or later find) the previous answer leading to a lower need to repeat explanations.

Known Instances

• Europace AG

• Paypal Inc.

• Mercado Libre

• Siemens makes extensive use of communication channels accessible to all employees for all user questions and discussions around code.siemens.com, InnerSource and Open Source.

Authors

Isabel Drost-Fromm

Acknowledgment

Sebastian Spier (for the visual)

Status

• Structured

• Drafted in December 2019.

Credits

Welcome to the InnerSource Patterns Book.

This book contains InnerSource best practices codified in a specific format to make it easy to understand, evaluate, and apply them in your context. We call this format a pattern.

What is InnerSource?

We define InnerSource as:

The use of open source principles and practices for software development within the confines of an organization.

InnerSource takes the lessons learned from developing open source software and applies them to the way companies develop software internally. As developers have become accustomed to working on world-class open source software, there is a strong desire to bring those practices back inside the firewall and apply them to software that companies may be reluctant to release.

For companies building mostly closed source software, InnerSource can be a great tool to help break down silos, encourage and scale internal collaboration, accelerate new engineer on-boarding, and identify opportunities to contribute software back to the open source world.

What are InnerSource Patterns?

Patterns are a way of describing a repeatable, proven solution to a problem within a context. Patterns follow a simple form that assists you during the implementation of a solution to understand the constraints of the problem, understand the forces you need to balance, and the resulting context - the situation created by applying the solution.

Patterns can provide a way for the InnerSource Commons participants to concisely share information, improving the practice of InnerSource. Patterns are divided into Title, Problem Statement, Context, Forces, and Solutions as their main sections.

How can you use InnerSource Patterns?

Patterns must be used thoughtfully. They cannot be indiscriminately applied. In most cases, you will need to adapt the given solution to your situation; but the information given in the pattern, defining the context (immovable constraints) and forces (constraints that can be changed and balanced against each other), should help you do this. Note that you will also need to determine if there are additional constraints (company context and company forces) that apply to your particular company/organization that must be added to the pattern (as a kind of filter). These additional constraints may require additional solution steps to be applied.

The pattern form is useful for describing proven solutions but it can also be used for brainstorming new solutions where patterns are not yet established. This is because the anatomy of a pattern provides a framework for thinking about a problem in a structured manner. You could also create a donut pattern (filling in the problem, context, forces, and resulting context fields but leaving the solution blank) as a way of asking the InnerSource Commons community for help (to find a proven solution or to brainstorm things to try).

How to Contribute?

Credits

We want to specifically mention the InnerSource Patterns Working Group. They have nurtured the quality of the InnerSource Patterns and helped others to contribute. Lastly, they also compiled a selection of available patterns into this book.

Thank you to all contributors! And happy InnerSource Day :)

Licensing

Title

Contracted Contributor

Patlet

Associates wanting to contribute to InnerSource are discouraged from doing so by their line management. Relief is provided by formal contracts and agreements.

Problem

Context

A large corporation has started an InnerSource initiative. Major goals for the initiative are to increase the efficiency of distributed software development and to foster innovation by allowing every associate to voluntarily contribute to InnerSource projects, regardless of topic and business unit.

However, top-level management has not yet empowered or incentivized mid-level managers to allow or even motivate their employees to participate in cross-divisional InnerSource activities. In addition to that, the capacity of every associate is usually allocated to non InnerSource projects for 100 % of their working time. Cross organizational collaboration is not yet the norm and line managers usually do not have targets outside of their own organization. Contributions to InnerSource projects are expected to be made during working hours, not during free time.

Forces

• Managers are held responsible for the results of their business units. Letting their staff participate in InnerSource activities which might spend time making contributions outside of their business unit effectively reduces the capacity of his or her unit. This will likely make it harder for the managers to reach or exceed their goals.

• Line managers and HR will, by default, judge the performance of their subordinates against their business units goals, which might not be aligned with the goals of the InnerSource community.

• The less executive air cover a line manager perceives he has, the less likely is he or she to have his or her staff participate in InnerSource activities which contribute to another business unit.

• The less transparency and control a line manager has of work done by one of her subordinates, the less likely is she to allow her to contribute.

• The less formally work in InnerSource is managed and organized, the less likely a line manager who is accustomed to formal processes is to sign off on one of her employees contributing to InnerSource.

• The more time an associate spends on contributions to an InnerSource project which does not benefit his day-to-day work, the more will the workload for his teammates in his business unit increase.

• Individual contributors will likely consider participating in InnerSource as an opportunity to enhance their professional network within the company and to gain knowledge and experience in the technical area of her contributions.

Solution

Set up a formal contracting between the contributor, their line manager and a centrally funded and steered InnerSource governance office (ISGO). Have the ISGO reimburse business units who contracted contributors for the contracted time.

• The contracting specifies a maximum percentage of the associates work time in InnerSource.

• The contracting clearly states that work in the contributor's business unit takes precedence over work in InnerSource.

• The contracting states that it is not required to work in InnerSource for the maximum percentage specified in the contract.

• The governance office offers to mediate between the contributor and her line manager in case of conflict regarding the time for contributions.

Resulting Context

A formal contracting and centrally funded reimbursements convincingly communicating the organizations support for the InnerSource initiative, thus empowering middle management to sign off on it:

• Allocation of corporate funds to business units for reimbursement of development capacity signals to line managers that InnerSource is deemed valuable by the organization, that it has executive air cover and that they are expected to support it, too.

• A formal contracting signals that work in InnerSource is managed professionally and inspires trust.

• A formal contracting increases transparency and provides a better overview about the associate's available capacity for his business unit and InnerSource projects, thus reducing the risk of "over-booked/planned capacity".

A formal contracting is also beneficial for contributors and communities:

• A formal contracting provides a basis for resolving conflict related to participation in InnerSource activities. Note that mediation will likely be successful only for a few companies with a culture conducive to that.

Known Instances

• BIOS at Robert Bosch GmbH

Status

• Structured

Author

• Georg Grütter (Robert Bosch GmbH)

Acknowledgments

• Diogo Fregonese (Robert Bosch GmbH)

• Robert Hansel (Robert Bosch GmbH)

• Jim Jagielski

• Tim Yao

• Cedric Williams

• Klaas-Jan Stol

• Padma Sudarsan

• Nick Stahl

• Ofer Hermoni

• Robert C. Hanmer

Changelog

• 2016-10-25 - first review

• 2017-05-09 - rework

• 2017-09-08 - second review, final rework and merged

• 2021-02-27 - fixing issues with display of the pattern in the book

Title

Core Team

Patlet

Even when an InnerSource project is widely needed, contributions and usage may be hindered because the project is difficult to work with. Establish a core team that is dedicated to take care of the project's fundamental items. Their work enables contributors to add and use the features that provide value to their scenarios.

Problem

• It is difficult to contribute to the project. This could be due to things like:

  • Can't run the project locally.

  • Poor documentation.

  • Convoluted code.

  • Inadequate testing.

• It is difficult to use the project. Some possible causes:

  • Poor documentation (again).

  • Frequent bugs.

  • Nonintuitive setup.

Story

There's a central project that everyone depends on. What a great candidate for InnerSource! Unfortunately, the project has grown organically, with various contributions and additions slapped on haphazardly. Now it's an icky, thick morass of code that no one understands and everyone is afraid to touch. It's clearly due for an overhaul (e.g. refactoring, testing, documentation, etc.), but even though everyone needs and wants that work to happen, no one takes the time to do it.

Context

• Many teams need the project.

• The project has significant tech debt.

• Slow adoption and iteration on the project.

• There is not a owner or maintainer who takes responsibility for the project and contribution ecosystem as a whole.

Forces

• Every contributing team is busy, and therefore prioritizes work that results in an immediate payoff for themselves.

• As the project grows the natural trend is for it to become more difficult to use and to modify.

Solution

Form a core team whose job it is to maintain this project in a state so that others can easily onboard and contribute to it. This core team does the work that is necessary for a healthy usage and contribution ecosystem. This critical work tends to not be prioritized as a contribution. Categories of this type of work include communication, local environment, and DevOps infrastructure.

Here are some specific examples:

• Production bugs

• Documentation

• On-boarding tutorials and examples

• Automated testing

• CI/CD

• Local environment

• Modularization

• Versioning

• Monitoring

• Trailblazing new classes/categories of features

Each of these items is very important to a healthy product ecosystem, yet is unlikely to be prioritized as a contribution.

The core team may be composed of a small number of people on a full-time or a part-time basis. The choice depends on the amount of work needed, the availability of resources, and the culture of the organization. The most important consideration is to form the team in a way that allows the organization to empower and hold them accountable in the same way as any other team.

A good way to continually remind the core team of this goal is to have them report regularly on:

• number of active teams using the project

• number of off-team contributions to the project.

Continual focus on these metrics will naturally drive the core team to prioritize generally the right work to create a thriving InnerSource ecosystem around the project.

Resulting Context

• It is easy to use and contribute to the project.

• Many teams use and contribute to the project.

• Core team has their success defined in terms of others' interaction with and response to their project.

Rationale

Separating out a core team and tasking them in this way helps to fill the gaps that a successful project needs yet are left behind by contributors that are pursuing their own agenda only. The core team fills those gaps and greases the wheels so that the contribution ecosystem remains healthy.

Known Instances

• Nike implemented this pattern to manage the InnerSource effort around its reusable CI/CD pipelines.

Status

Structured

Author

Title

Dedicated Community Leader

Patlet

Select people with both communications and technical skills to lead the communities to ensure success in starting an InnerSource initiative.

Problem

Selecting the wrong persons and/or not providing enough capacity for them risks wasted effort and ultimately the failure of a new InnerSource initiative.

Story

Consider the following story. A company wants to start an InnerSource initiative in order to foster collaboration across organizational boundaries. They have decided to start with an experimental phase with limited scope. Management has selected a suitable pilot topic for the first InnerSource community and expects contributions from many business units across the organization. The company has nominated a new hire to head the community for 50 % of his work time, because he was not yet 100 % planned for. After 6 months, the community has received only a few contributions, most of which are from a single business unit. The company replaces the community leader with someone who has a longer history in the company, this time for only 30 % of his time. After another 6 months, the number of contributions has picked up only marginally. The company is no longer convinced that InnerSource helps to achieve their goal of increased, cross divisional collaboration and abandons InnerSource.

Context

• The company is a large and old company. It has no prior experience in Open Source or other, community based working models. The company culture is best characterized as a classical top-down management style - it is generally at odds with community culture.

• While there are supporters and a sponsor in top level management, middle management in the company is not yet sold on InnerSource.

• Management was not convinced to provide more than a limited budget to fund a part time community leader, only.

• The initially selected community leader has little or no prior experience with the Open Source working model.

• The initially selected developer community leader does not have an extensive network within the company.

Forces

If a company does not significantly invest in the initial InnerSource community in terms of budget and capacity for InnerSource, the credibility of its commitment to InnerSource might be perceived as questionable. A common impulse of a company with a traditional management culture to a project or initiative not performing as expected will be to replace its leader. Doing that without involving the community and following meritocratic principles will further undermine the company's commitment to InnerSource by highlighting the friction between the current company culture and the target culture - a community culture.

The value contribution of InnerSource projects will not be obvious for many managers which are steeped in traditional project management methods. Those managers are less likely to assign one of their top people, who are usually in high demand by non InnerSource-projects, to an InnerSource project for a significant percentage of their work time.

Communication takes up a significant percentage of a community leader's daily work. At the same time, he or she will likely also have to spearhead the initial development, too. In the face of limited capacity, inexperienced leaders will tend to focus on development and neglect communication. The barrier for potential contributors to make their first contribution and to commit to the community will be much higher if the community leader is hard to reach or is slow to respond to feedback and questions for lack of time. Furthermore, technically inexperienced leaders will most likely have a harder time to attract and retain highly experienced contributors than a top performer with a high degree of visibility within a company would have.

If a community can not grow fast enough and pick up enough speed, chances are they won't be able to convincingly demonstrate the potential of InnerSource.

If the company selects an experienced project or line manager steeped in traditional management methods to be the community leader, he or she is likely to focus on traditional management topics such as resource allocation, providing structure and reporting channels rather than leading by example through meritocratic principles. This will undermine the credibility of the InnerSource initiative in the eyes of developers.

Solution

Select a community leader who:

• is experienced in the Open Source working model or similar community based working models,

• has the required soft-skills to act as a natural leader,

• leads by example and thus justifies his position in the community meritocracy,

• is an excellent networker,

• inspires community members,

• can communicate effectively to both executive management and developers and

• is able to handle the managerial aspects of community work.

Empower the community leader to dedicate 100 % of his time to community work including communication and development. Inform management of the need to be sensitive to the views of the community when engendering a change in community management. Ideally, empower the community to nominate a community leader themselves.

Resulting Context

A community leader with the properties described above will lend a face and embody the company's commitment to InnerSource. It will make it more likely that other associates in his network will follow his lead and contribute to InnerSource. Over time, he or she will be able to build up a stable core team of developers and hence increase the chances of success for the InnerSource project. By convincing a large enough audience within his company of the potential of InnerSource, he or she will make an important contribution to changing the company culture towards a community culture.

Having excellent and dedicated community leaders is a precondition for the success of InnerSource. It is, however, not a silver bullet. There are many challenges of InnerSource which are above and beyond what a community leader can tackle, such as budgetary, legal, fiscal or other organizational challenges.

Known Instances

• BIOS at Robert Bosch GmbH. Note that InnerSource at Bosch was, for the majority, aimed at increasing innovation and to a large degree dealt with internal facing products. This pattern is currently not used at Bosch for lack of funding.

• Airbus. A data scientist wanted to improve the collaboration with peers in the group and found: i) many developers (beyond data science) wanted that too and were happy someone was taking care of the issue, and ii) support from line manager and middle management to eventually act as the de facto community leader, on top of his regular line of duty.

Alias

Dedicated Community Manager

Status

• Structured

Authors

• Georg Grütter (Robert Bosch GmbH)

• Diogo Fregonese (Robert Bosch GmbH)

Acknowledgments

• Tim Yao

• Padma Sudarsan

• Nigel Green

• Nick Yeates

• Erin Bank

• Daniel Izquierdo

Changelog

• 2016-11-06 - 1st review

• 2017-04-06 - 2nd review

More and more patterns are contributed to this book by the InnerSource Commons community. That is awesome!

Now how to make it easy for readers to discover the patterns that can help them in their particular situation?

For this purpose we provide this mind map. It categorizes patterns based on the different phases of an InnerSource Program, and the challenges that might appear in the respective phases.

Improve this Mind Map

References

You want to make this book better? That is awesome!

No matter if you want to help us fix grammar/spelling, improve the design, or contribute entirely new patterns based on the InnerSource experiences that you have made at your workplace. We love all of that! :)

If you have never made a contribution to an open source project before, know that the InnerSource Patterns community is group of friendly people and with that a safe place to try it out.

Before you get started

Different ways to contribute

Here a few ways in which you can contribute:

1. fix spelling, formatting, or other glitches that you notice in this book

2. improve the content of an existing pattern (e.g. by adding a short description of how you are using a pattern as a Known Instance)

3. contribute a new pattern, describing how you have overcome InnerSource-related challenges in your organization

For (1) and (2) above you can simply hit the Edit on GitHub link that you see at the top of each page in this book. This will take you straight to the respective file in our GitHub repository, where you can suggest your changes.

License of Contributions

Title

InnerSource License

Patlet

Two legal entities that belong to the same organization want to share software source code with each other but they are concerned about the implications in terms of legal liabilities or cross-company accounting. An InnerSource License provides a reusable legal framework for the sharing of source code within the organization. This opens up new collaboration options, and makes the rights and obligations of the involved legal entities explicit.

Problem

When two or more legal entities within an organization want to share code with each other, they need an agreement about the terms and often a legal contract. Creating such agreements on a per project basis takes effort and creates a barrier for sharing. i.e. a team within a legal entity might decide not to share their source code with another legal entity in the organization because it seems complicated.

Barriers for sharing can lead to silos and duplication of effort in rebuilding similar solutions in multiple parts of the organization.

At the time of sharing the source code, it can not be reliably predicted what the value of sharing will be. If the activity of sharing requires significant effort (i.e. negotiating terms for the usage), the legal entities are less likely to do it, as they are concerned about the return on investment.

Context

• A large organization with many legal entities (subsidiaries) that want to share code. When the organization gets larger, the value of this pattern increases.

• As per definition, the legal entities have their own legal rights and obligations.

• Multiple of these legal entities are developing software, and are using services of the other legal entities. They have a motivation to contribute to each other’s source code.

• A sufficient complexity of the organization and its organizational structure

Forces

• Level of effort required to write formal agreements, especially if they need to take into account technical, legal, and business perspectives.

• A large organization (consisting of many legal entities) has many internal regulations. Any new agreements that are made have to comply with these regulations, e.g. security, privacy, procurement processes, etc. The volume of regulations can make it difficult to assess whether sharing software between two legal entities is compliant with these regulations, especially when there is no standard procedure.

• If any of the legal entities in the organization has a business model that depends on proprietary code and accounting of licensing fees within the organization

• Company culture that isn’t used to InnerSource collaboration and sharing code. This results in uncertainty about the rights and obligations when using shared code.

• Freedom over using the software leads to competition, and spread of ownership

• There are legal contracts in place which cover the sharing of source code. These contracts are not standardized, so they create additional effort in negotiating and understanding for every project. The existing contracts may also not allow sharing source code in an open enough sense to support a true InnerSource approach.

• Alternatively, there are no legal contracts in place but source code is shared informally. That might create uncertainty in cases where clarity about ownership and rights and obligations is needed.

• Choosing a restrictive and/or copyleft license can constitute a barrier for InnerSource adoption. Specifically, limiting publication to the organization might require a costly relicensing procedure prior to transitioning to Open Source.

Solutions

Creating an InnerSource License customized to the needs of the organization in question (and their legal entities). This license needs to be generic enough to be applied to the most important inter-company relationships.

It is important to write the InnerSource License such that it truly allows for open source style collaboration across the boundaries of the involved legal entities. Therefore the 4 freedoms of free software should be integrated into the license.

The License is written as a formal legal document, and can be used as part of contracts between the legal entities to govern the code sharing agreements.

Resulting Context

With the InnerSource License, we have a tool to share code between legal entities within our organization.

The license simplifies the conversations within our organization about sharing source code, and is motivating the first legal entities to do so.

Note: The experiment described in Known Instances is in an early phase. Therefore a firm Resulting Context has not formed yet. In a couple of months the effects of the InnerSource License on this problem space will be more clear, and this section can be updated.

Known Instances

• DB Systel

• Robert Bosch GmbH

• Airbus

• GovTech (Singapore Government)

• Siemens has developed their own InnerSource license alongside other necessary legal agreements between subsidiaries.

DB Systel

DB Systel created their own InnerSource License, see DB Inner Source License. They used the EUPL, as that offered an open source like starting point, and then worked out the constraints and additional rules required in their specific organizational context.

The first legal entities (companies) within the DB AG are using their InnerSource License.

One positive effect that is already showing is that it simplifies the conversation, especially if some of the involved parties don’t know the InnerSource concept that well yet. Licenses are a well-known concept, therefore having an InnerSource License is a great discussion starter.

The experiments are also uncovering that there are further collaboration challenges that need to be solved in order to lead to a true InnerSource contribution and collaboration model.

The mentioned collaboration challenges include:

• making InnerSource licensed projects discoverable

• building communities for collaboration on projects, just like in Open Source

It is worth mentioning that so far the software shared under this InnerSource license is mostly tooling, infrastructure, and tools lower in the stack.

Airbus

Airbus created ad hoc InnerSource licenses to enable InnerSource way of working within a large part of the group.

GovTech (Singapore Government)

GovTech is responsible for the delivery of the Singapore government's digital services to the public. They created the GovTech Public Sector License (GPSL) as a permissive license to ensure that code can be shared between legal entities across government. The GPSL covers both usage of code by licensees (agencies and their vendors) as well as contributions back to GovTech. Following open source practices, the GPSL LICENSE file is included in each repository that is made available as InnerSource.

For more details see the InnerSource Commons Community call from 09/2023 Improving Engineering Collaboration across the Singapore Government through InnerSource (around 20:50) by Hunter Nield.

Status

• Structured

• The experiment listed under Known Instances is running since 02/2020. The initial experience shows first positive effects but more experience is needed to fully evaluate the pattern.

Author(s)

• Cornelius Schumacher (DB Systel GmbH)

• Schlomo Schapiro (DB Systel GmbH)

• Sebastian Spier

References

• FOSSBack 2020 Presentation: Cornelius Schumacher - Blending Open Source and Corporate Values - watch 27:30 and onwards for details about the InnerSource License

• DB Inner Source License

Glossary

• organization - An umbrella for multiple legal entities. (synonyms: group, enterprise) (e.g. Lufthansa)

• legal entity - An entity that has its own legal rights and obligations (synonyms: company, subsidiary) (e.g. Lufthansa Systems GmbH, Lufthansa Industry Solutions TS GmbH, ...)

Title

Gig Marketplace

Patlet

Establish a marketplace by creating an intranet website that lists specific InnerSource project needs as "Gigs" with explicit time and skill requirements. This will enable managers to better understand their employee’s time commitment and professional benefits thereby increasing the likelihood of garnering approval to make InnerSource contributions.

Problem

Neither managers nor employees understand how they might benefit from getting involved in an InnerSource project.

It is difficult for employees to communicate to their management what commitment of time they will need to make to an InnerSource project.

Managers have no uniform way of keeping track of or rewarding their employee’s involvement in InnerSource projects.

Story

You’ve successfully created an InnerSource program at your company and have buy-in from senior management, middle-management and developers. However, after nearly a year there have been few actual contributions made to any InnerSource projects outside of the teams that originally created them. After interviewing all the parties involved the main sticking point seems to be that it is difficult to know the time commitment developers will be asked to make if they choose to get involved in an InnerSource project and how they will personally benefit. There is also no uniform way of advertising what opportunities for contributors exist, what they’ll be asked to do and approximately how long it might take. Managers are supportive and want their employees to participate but so far have lacked a way of accounting for or rewarding their employees’ activities within InnerSource projects. What can be done to improve this situation for all the parties involved (InnerSource project owners, potential contributors and development managers)?

Context

Employees wish they could gain exposure to activities going on within other areas of the company without having to leave their current positions. InnerSource projects exist and could provide these experiences but there are two main factors preventing employees from participating. First, is the inability to easily discover what opportunities for contribution exist within ongoing InnerSource projects and to communicate these to their managers. Second, is the inability of managers to plan and account for their employees' time commitments to these InnerSource project tasks. As a result InnerSource project owners are finding it difficult to build communities of sufficient size to fulfill their stated goals.

Forces

• Employees have no easy way to discover what InnerSource opportunities exist

• Employees don't understand how contributing might benefit them professionally

• Managers don't understand the time/effort requirements associated with InnerSource project related tasks

Prerequisites

• Employees have been provided time by their managers to involve themselves in InnerSource projects

• Managers require a way for InnerSource contributions to be quantified, tracked and recorded so they can be accounted for and rewarded

Solutions

Create a “Gig” based intranet site where individuals can advertise their skills and areas of interest and InnerSource project owners can advertise opportunities for collaboration.

Employees should be able to create a profile within the application in which they can list their skills and areas of interest. The system should leverage this information by proactively informing individuals (via email or some other means) when a Gig is posted that matches one or more of those criteria.

Each Gig posted by an InnerSource project owner should include the estimated skill and time requirements so those can be easily matched to an available employee and clearly communicated to their direct management. The description should also include a rationale as to how it will benefit the person taking on the task in order to make it as attractive as possible.

A points based system could be created to reward and track an employee’s involvement in a Gig. For instance, 10 points awarded to the Gig owner for posting a Gig once it is completed and 100 points for a developer who completes a Gig. Points accrued by completing Gigs could then be used as a gamification mechanism and as performance management criteria to garner insight in to the areas of expertise that exist within an organization.

Those wishing to accept a Gig should first be vetted by the Gig owner to determine that the employee has the prerequisite skills and allotted time from their manager to complete the Gig.

The transparency of contributions made via Gigs can help a contributor build (or detract from) her reputation thereby creating a greater likelihood that the quality of the contribution will be high. Completion of Gigs can also act as proof of expertise in a particular area.

The nature of Gigs posted to the marketplace can include both hard and soft skills such as organizing a group event, writing a report or requests for mentorship etc.

The creation of the Gig Marketplace should ideally be taken on by a team within an organization with the responsibilities to provide company-wide infrastructure and capabilities.

Resulting Context

The InnerSource Gig Marketplace has vastly increased the number of InnerSource projects as well as the number of employees involved in them. The self-directed nature of the Gig Marketplace has enhanced job satisfaction amongst employees by allowing them a level of choice in the work they perform and with whom they can partner across the company. Employees understand exactly what they are signing up for and what they can expect from the experience. Managers are better able to estimate and track their employee’s time commitments with respect to InnerSource projects, recognize their individual efforts and use the completion of Gigs as a way of validating their specific skillsets. Managers are also able to leverage any existing downtime their employees may be experiencing by allowing them to pivot to work available in the Gig Marketplace. The data generated by the interactions within the Gig Marketplace is also helping to drive hiring and training decisions across all departments.

When used in combination with the InnerSource Portal pattern, the Gig Marketplace provides a finer level of context and detail in addition to the links to the code repositories and documentation for the project to which the Gig relates.

Known Instances

• A large financial services organization has used the creation of an InnerSource Gig Marketplace website to foster their InnerSource program.

• SAP implemented the Gig Marketplace pattern - a new InnerSource program was added to the internal job platform where positions and similar offerings can be posted.

• The Gig Marketplace pattern has been proven to work extremely well with the associated InnerSource Portal pattern in this context. The InnerSource Portal increases awareness of specific projects currently underway while the Gig Marketplace advertises tasks of a certain type available to be worked on within those projects.

Status

• Structured

Author(s)

• Stephen McCall

• Shreyans Dugar

Title

Group Support

Patlet

What happens if a team or individual no longer supports an InnerSource project? Keep the project alive by forming a group of interested individuals.

Problem

• A popular InnerSource project is orphaned.

• There isn't an obvious home for it to land.

Story

A library of UI widgets is used by over 50 projects throughout the company. The funding for the team that owns the library runs out and the team disbands. At first, no one notices, but after a while whenever someone asks "who owns it" there isn't an answer. What will happen next? Will new teams shy away from using it? Will the project stagnate and linger until its users eventually are forced to move on to something else? What a shame if that were to happen to a perfectly good and useful project!

Context

• Popular InnerSource project.

• Consumed as a build-time dependency (e.g. code module).

• No one is actively supporting it.

• The company cannot assign a team to support.

Forces

• No one is assigned by their day job to work on it.

• Everyone is busy.

• High cost to migrate off the project.

Solutions

Call for interested volunteers from anywhere in the company to form a group of Trusted Committers to support the project. You may need to reach out to specific individuals based on commit or usage history. It is important that there are enough so that the burden on each can be reasonably small.

When forming, this group should identify or create Standard Base Documentation and Communication Tooling.

The group should do its best to manage these aspects of the project:

• Maintenance. If the project is flat-out broken for the standard use case, then fix it. Keep the project up-to-date as the dependencies and frameworks it uses continue to evolve.

• Onboarding. If someone has a question about how to use the project, make sure they get a reasonable answer.

• Updates. If someone wants to add new feature to the project, give them the design and technical support necessary for them to build it so that it both works for them and is a good addition to the project. Review incoming pull requests in a timely manner.

Since this group is comprised of volunteers, it is important to communicate that support is "best effort" only. Accordingly, this model of support is not well-suited for run-time critical, production projects like live APIs. It is better suited for projects that are consumed at build-time like libraries/packages/modules. The group is not expected to implement any new functionality for others.

Resulting Context

• There is some fragile support for the InnerSource project.

• In the long-term the group support is likely to dissolve again at some point. If the project continues in the long run, then use this period of stable group support to find a long-lived way to support it (e.g. Core Team).

Rationale

People generally want to help. If there is personal outreach for someone to join as a Trusted Committer, there are generally a number of people that will say "yes". Feeling part of a group and being given some structure and responsibility generally motivates people to try their best, which many times ends up being enough.

Known Instances

• WellSky

Status

Structured

Author

Russell R. Rutledge

Title

InnerSource Portal

Patlet

Potential contributors cannot easily discover InnerSource projects that they are interested in. By creating an intranet website that indexes all available InnerSource project information you enable contributors to learn about projects that might interest them and InnerSource project owners to attract an outside audience.

Problem

InnerSource project teams are finding it difficult to attract outside contributions.

InnerSource projects at your organization are increasing but potential contributors have no easy way of discovering them.

Story

You are attempting to establish an InnerSource practice within your organization. You are aware of some projects being run using an InnerSource model but their existence is only being communicated via word of mouth, email or sidebar conversations with other employees. As a result InnerSource project owners are finding it difficult to attract contributors.

There is no single, shared resource for employees across the organization to access which will allow them to easily discover all ongoing InnerSource projects. This is severely limiting the growth potential of every InnerSource project.

What can be done to help all InnerSource projects raise their visibility to as large an audience as possible and attract contributors organization-wide?

Context

• Your organization is interested in adopting an InnerSource work style.

• InnerSource project owners are seeking a way to attract audiences to their projects. However, they are limited by the communication channels available to them through which they could advertise to potential contributors.

• InnerSource projects at your organization are increasing.

• Compounding this problem is the fact that the shared source control management application in use has such limited search capabilities that even developers in search of InnerSource projects find it frustrating to locate them.

Prerequisites

• Managers have given tacit acceptance that their employees should take part in InnerSource projects

• A shared source control management system is in use which provides programmatic access to the contents of the repositories it hosts

• There is a department within your organization with the responsibility of promoting InnerSource collaboration

Forces

• The full potential for separate engineering teams to partner on shared challenges is not being realized

• It is difficult for individuals to discover what InnerSource projects exist

• It is difficult for InnerSource project owners to attract an audience of external contributors

Solutions

Create an InnerSource Portal intranet website where InnerSource project owners can easily advertise the availability of their projects.

Key properties of the portal are:

• Visitors to the InnerSource Portal should be able to see all available projects as well as search for specific projects based on various criteria such as project name, technologies in use, contributor names, sponsoring business unit etc.

• The information displayed via the InnerSource Portal should be under the full control of the InnerSource project owners at all times. Preferably, by sourcing this information directly from a specific data file or meta-data stored in the project repository itself.

• Project owners should include all relevant information concerning their projects within those data files including the project name, trusted contributors' names, a brief description and links to the code repository or any supporting documentation.

• (optional) While most organizations will choose to make their portal only available on their intranet, some organizations have opted to make their portal available on the public internet. The latter can be interesting for organizations that want to show additional information about their InnerSource approach in their portal e.g. for branding and recruitment purposes.

When launching the portal, a communications campaign promoting the addition of InnerSource data files or meta-data to code repositories should be considered, to bolster the number of projects displayed within the portal.

Implementations

SAP Project Portal

A reference implementation of an InnerSource portal is available on GitHub and open for contributions. It lists all InnerSource projects of an organization in an interactive and easy to use way. Projects can self-register using a dedicated GitHub topic and provide additional metadata.

Wiki

As a simple way to start, you can set aside a page on an internal wiki for listing out available projects. An easy way to display this information is in a table with columns giving just a little bit of extra information about the projects. Try to have just enough columns so that viewers can determine if they want to learn more about the project, but no more. Too much information will make the page overwhelming and difficult to use. Individuals and teams can self-add their projects to the page.

Here is a sample set of columns:

• Name. Name of the project (optionally linked to its homepage).

• Brief Description. Explaining the purpose of the project (which problem does it solve?)

• Technology Pre-requisites. You must use these technologies in order to on-board to the project.

• Getting Started. Link to instructions on how to start using the project.

• Chat. Link to a chat channel to ask questions about the project.

• Host Team. Seeing if a team is behind the project can help others to have the confidence to use it.

• Production Since. How long as the project been used in a production environment? Seeing this information is a rough proxy for its maturity.

• Contribution. Link to instructions on how to contribute to the project.

This solution doesn't allow for a fancy display - it is just a wiki table. If it's important for you to have a snazzy-looking UI, then this idea won't work for you. Additionally, if you end up with a lot of projects (e.g. nearing 100), this solution won't scale to allow the search and filtering or auto-updating of project entries that you'll probably need. It is a good solution for a portal with a few dozen projects, though.

Resulting Context

• The InnerSource Portal has enabled InnerSource project owners to advertise their projects to an organization-wide audience. Due to this increased visibility they are attracting much larger communities of contributors than ever before.

• For those looking to get involved in InnerSource projects, the InnerSource Portal has allowed them to discover exactly the kind of opportunities they are interested in by searching across all available InnerSource projects simultaneously based on their specific criteria.

• Satisfying the needs of both of these audiences has helped establish InnerSource as a viable and attractive option for all areas of the organization to leverage to accomplish things together they could not have separately.

Known Instances

• A large financial services organization has used the creation of an InnerSource Portal to provide a mechanism of advertising and discovering InnerSource projects in existence across different business units

• SAP promotes InnerSource projects in the InnerSource Portal - projects can self-register using GitHub topics. The Repository Activity Score defines the default order of the InnerSource projects in the portal. Also see Michael Graf & Harish B (SAP) at ISC.S11 - The Unexpected Path of Applying InnerSource Patterns. Its codebase is published as a reference implementation and open for contributions.

• Elbit Systems has used this pattern and added gamification on top.

  • Gamification As Means of Cultural Change and InnerSource Engagement Booster | Shelly Nizri | OSCON 2018 - Portland, Oregon

  • Of Islands, Monsters & InnerSource (slides), (video) | InnerSource Spring Summit 2019 (Galway, Ireland)

  • The code realizing this platform has been open sourced.

• American Airlines promotes InnerSource projects via an internal InnerSource Marketplace. Similarly to SAP, projects self-register by adding innersource as a GitHub topic. Projects are searchable and filterable by language, topics, number of open issues, etc.

• Banco Santander has created a public portal called "Santander ONE Europe InnerSource Community" to support and increase InnerSource adoption. In addition to the catalog of projects the portal includes relevant content such as documentation, way of working, news, and events.

• Airbus used the SAP Portal as a Proof of Concept. It is now using the Bazaar plugin of Backstage as the latter became the official developer experience tool internally. It provides a convenient self-registering capability for all the divisions.

• Mercado Libre use an instance of the SAP portal to discover existing InnerSource projects within the organization.

• Mercedes-Benz is using the SAP reference implementation mentioned above for their InnerSource Portal.

• WellSky has a simple Confluence Wiki page were InnerSource and reusable projects are listed.

• Siemens has set up an internal portal that provides documentation for InnerSource maintainers, contributors, users and their managers. It also serves as an entry point to explore available projects and gives hints to improve project visibility.

References

• The InnerSource Portal pattern has been proven to work extremely well with the associated InnerSource Gig Marketplace pattern in this context

Status

• Structured

Author(s)

• Stephen McCall

Acknowledgments

• Shelly Nizri

• Melinda Malmgren

• Michael Graf

• Jesús Alonso Gutierrez

Title

Extensions for Sustainable Growth

Patlet

An InnerSource project is receiving too many contributions, making maintenance difficult. By offering an extension mechanism outside of the core project, the maintainers enable scaling of project capabilities with minimal cost and maintenance overhead.

Problem

As the number of contributions to a mature InnerSource repository rapidly increases, it adds more burden on code reviews and maintenance. This results in a large code review backlog or premature rejection of new feature contributions.

How can the host team allow for faster release of new features, encouraging innovation and experimentation; while also keeping the repository well maintained?

Story

There is a strategic project that aims to collect the best innovations within a domain space to one common stack, allowing reuse of a common infrastructure and providing a standard user experience. Through InnerSource, various teams in the organization that work within the domain space get an opportunity to collaborate and contribute their innovations to the common codebase.

However, a large number of contributions in parallel from several developers is making maintenance of the codebase difficult. This is adding a huge burden on the project maintainers who assume ownership over the code quality standards and enable the community through various forms of communication.

Project maintainers are at risk of burnout due to:

• Everlasting backlog of pull requests from contributors that need to be reviewed.

• Job dissatisfaction: Majority of maintainers' time spent in community support leaves no room for innovation.

• Perceived lack of accomplishment: Not all contributed features have adequate user demand and result in consequent adoption.

• Time consuming releases: More features in the codebase results in long running tests.

• Increase in maintenance activities: More bugs raised as new capabilities are added.

A lot of time is spent on maturing every new feature contribution, before potential users even get an opportunity to explore the feature for their use cases. If it turns out that new feature isn't fulfilling the use case, then all that time spent on achieving the desired code quality standards are waste.

Context

• A strategic InnerSource codebase is scaling rapidly with new feature contributions from several employees.

• The ratio of reviewers to contributions results in a growing backlog of pull requests. This is slowing down release of new features to the community.

• Quality of the codebase is degrading and user experience is adversely impacted.

• Maintainers of the codebase are burdened and cannot keep up with the influx of contributions and increased community support.

• Some of the contributed features are not gaining adoption by users, and might even turn fully dormant. However even though they are unused, these features are still adding to the maintenance overhead.

• Organization is investing heavily in hardening of new feature contributions to retain quality standards before the ideas are explored by the community.

• The pattern applies in either scenario:

  • Maintainers find themselves rejecting new feature ideas to narrow down the scope of the project. This is hampering innovation in the community and restricting further expansion.

  • To reduce backlog, new features are getting released without thorough documentation, hardening, or testing, creating a poor user experience. This is also bloating the size of the codebase, adding a huge dependency graph and making it difficult to maintain.

Forces

• Maintainers and product owners want to allow for expansion, encourage innovation and experimentation without being overly restrictive on contributions, while also keeping good code and quality standards for user experience.

• A large amount of time goes into hardening and thorough testing of features to meet product standards, but product owners may want to allow for faster release of new innovations for adopting products to explore before investing time in maturing the capabilities.

• Maintainers want to encourage the community to share innovations that combine product capabilities with other use-cases without adding more dependencies to the primary repository.

Solutions

Allowing extensions/plugins to high-scale InnerSource codebases can relieve the maintenance burden on repository maintainers and allow faster release of new features for adopting products to explore. This shifts maintenance of capabilities to extension owners and allows the primary repository to support capabilities that have been adopted more widely and are more strategic.

Extensions provide a filter for new capabilities that may eventually move into the core of the project. Extensions also act as an incubation and community hardening environment, allowing for much of that hardening to happen organically rather than in a costly review process.

In order for the extensions model to be successful, there are few architectural considerations to keep in mind:

1. Easy to create: To obtain community participation, extensions need to be easy to create.

   • Create a repository template that extensions should use as a starting point. This allows the extensions to add their new features in new repositories, separate from the core project. The template should provide the same modular structure as the primary repository, and include the framework to package and release extensions.

     • Ensure that as the primary repository changes, the template(s) are well-maintained. The primary repository maintainers are responsible for updating the template(s) to ensure it is compatible with the main project. Following good versioning conventions, e.g., semver, makes this easier to follow.

     • It is further recommended that the primary repository maintainers provide guidance on how to update extensions based on older versions of the template as newer versions are released.

   • Add example extension(s) developed from the template, which project developers can reference to understand how to write a well-patterned extension.

   • Loosen the requirements for contributors to create extensions by bypassing reviews to allow for faster release or experimentation.

2. Loose coupling: Having modular components that contain functionality can allow loose coupling, where changes to extensions do not impact the quality of the main codebase or other extensions.

3. Dependency management: Each extension should be careful to pin the version range of the primary repository that it is built against (the same way it would any other dependency) and should be careful in its use of other dependencies that shadow dependencies of the primary repository such that the versions it chooses for those dependencies are compatible with the primary repository versions selected. Any conflicts with primary repository will be caught in the test framework for the extension.

4. Testing strategy: How to test extensions both individually and in combination?

   • Testing extension individually: Extensions template will provide a test framework to be used by the extension developers to test the capability added. This can include a framework for unit tests, runtime performance and quality tests.

   • Testing extension in combination with primary repository: Extension developers have a well-patterned method for testing their extension against specific versions of the primary repository without involvement from the primary repository's maintainers.

   • Testing extension in combination with other extensions: Providing a test framework for this scenario could result in being excessive especially if there are a large number of extensions that are still being explored by users and unlikely to be all used in combination. If a user runs into conflicts while using extensions in combination (which should be unlikely with sufficient loose coupling), the user can raise an issue to the respective extension owners who will sort it out. As an extension reaches later phases of the lifecycle and gets merged into the primary repository, it would be tested in combination with rest of library and any dependency conflicts will have to be resolved at the time.

5. Discoverability and Usability:

   • Make extensions easily discoverable with a publishing page showing the extensions that users have created and want to share for product usage.

   • Allow registration of extensions with the primary project for users to leverage extensions alongside the original project, thus keeping the same user experience.

6. Lifecycle of extensions and maintainability: Establish the lifecycle for extensions from creation to porting into the primary codebase, along with clear ownership guidelines.

   • Extension creators continue maintaining the extension, providing any support and fixing defects. Any extension left unmaintained will be unlisted from the publishing page.

   • Create criteria for when an extension can be ported to the primary repository, such as adoption of the extension by internal products and demand for the feature.

   • Porting process of the extension to the primary repository will follow more stringent code review guidelines as set by library maintainers.

Following these principles ensures that:

• Developers can add new features to a project's ecosystem without requiring them to write large amounts of boilerplate code.

• Extensions are discoverable in a repeatable manner by all users of the primary project; just because code doesn't live in the main repository yet does not mean it is not valuable.

• The maintainer burden is reduced until an extension has demonstrated that it fills an important gap in the primary project.

• The core project's common code (e.g. base classes and utility functions) can be a starting point for new development that extends project's domain. This avoids the need to port innovative work after-the-fact, thus reducing the overall burden of developing novel features for the project.

• Developers are more likely to contribute and stay involved in maintenance and building communities for their codebase, which is also good for the health of the overall project ecosystem.

Resulting Context

• The project is able to scale with the addition of new features, without adding maintenance overhead on the primary project repository.

• Faster release of new features for the community to explore, encouraging innovation and experimentation.

• Reduced the costly code review and feature hardening process until the feature is able to prove its utility. This has cost savings benefits for the organization.

• A post problem that can be introduced - what happens if an extension can not complete the full lifecycle?

  • If an extension is not adopted over a period of time and could not build a community around it to support maintenance, it would be up to the extension owner to continue maintaining it for however long they want to. If an extension is left unmaintained, it would be unpublished.

  • If an extension developer is unable to further maintain their project, and other developers in the community want to continue supporting it, they may maintain the extension going forward.

Known Instances

• IBM Corporation has adopted this solution to scale InnerSource AI libraries. Using extensions, developers are able to extend AI libraries with more algorithms and share their innovations with the company-internal community. The core libraries only contain strategic algorithms that have been adopted and validated, keeping them easier to maintain as we scale contributions.

Alias

Extensions to Manage Contributions at Scale

Status

Structured

Author(s)

• Sukriti Sharma, IBM

• Alexander Brooks, IBM

• Gabe Goodhart, IBM

Title

Document your Guiding Principles

Patlet

The usual InnerSource explanation of "applying open source best practices inside an organization" does not work well with people lacking an open source background. As a remedy the most important principles of InnerSource get documented and published widely.

Problem

The organization is trying to roll out InnerSource at a larger scale. The initiative started among open source enthusiasts. The goal is now to get buy-in from people that are lacking open source experience. For that audience the typical slogan of "applying open source best practices" is no longer sufficient to transport the message of what InnerSource is, which problems it solves and which tools it uses for solving these issues. As a result InnerSource adoption in the organization slows down. Teams develop diverging ideas of what the goals of InnerSource is about and how to best implement it leading to confusion when contributors are starting to cross team boundaries.

Story

Early experiments in an organization have shown that open source collaboration best practices can be beneficial. The next step now is to move the initiative to teams and individuals lacking a deep background in open source.

The goal now is to clearly communicate the goals of the InnerSource initiative as well as a clear path towards achieving these goals.

Context

• InnerSource as a term is circulating among employees.

• The initiative started among open source enthusiasts.

Forces

• Teams have trouble communicating exactly what the important aspects of InnerSource are.

• People lacking open source experience fail to understand what it means to bring open source best practices into the organization.

• On a daily basis teams trying to follow InnerSource best practices have a hard time deciding if what they are doing is inline with general InnerSource values.

Solution

Those driving the InnerSource initiative in the organization need to help the teams and individuals that are lacking a deep background in open source, and therefore have a less intuitive understanding of InnerSource.

Clarity should be provided to teams and individuals by documenting these two areas:

1. Purpose - Why does the organization want to adopt InnerSource?

2. Principles - Which InnerSource principles will help to address these challenges?

The following sections provide more details about both of these, meant as possible starting points to document them for your organization.

Why does the organization want to adopt InnerSource?

In the past InnerSource has proven to be successful to solve several issues commonly found in organizations.

However which organizational challenges does your organization hope to improve upon using InnerSource?

Instead of going for generalizations, try to exactly identify the solutions that match the challenges of your organization - preferably with those affected by the change you want to see.

Some challenges that others have addressed by following InnerSource best practices:

• Reduce development silos caused by excessive ownership culture.

• Increase innovation speed by reducing time spent solving similar issues by fostering healthy code reuse.

• Increase development speed by better cross-team collaboration.

• Solve project/ team dependencies beyond "wait it out" and "build workarounds", thereby reducing engineering bottlenecks.

• Increase quality.

• Increase employee happiness.

• To increase success of new hires.

• To build actionable documentation.

Which InnerSource principles will help to address these challenges?

Once teams understand which problems InnerSource will help them address, the next step is to explain which principles help address these challenges.

Based on basic open source development principles the following guidelines have been proven successful:

(1) Code must be transparently hosted within the organization

Source code, documentation, data relevant for project development must be available and easy to find for anyone in the organization.

(2) Contributions over feature requests

All stakeholders of a project act as potential contributors and are being treated and supported as such. Contributions remain suggestions instead of requirements. Coordination before a contribution helps avoid wasted effort. Projects provide contribution guidelines to avoid friction.

(3) Mistakes are opportunities for learning

With work visible across the entire organization any mistake is visible to everyone. As a result a culture must be established in which mistakes are opportunities for learning instead of failure that should be avoided at all cost.

(4) Written over verbal communication

For projects that span multiple teams, potentially on diverging meeting schedules, it needs to be possible to collaborate asynchronously. The goal for InnerSource projects is to recruit new contributors. For that, potential future contributors need to be able to follow the project progress on a self serve basis with a very low barrier to entry. If project relevant communication happens through synchronous communication, arguments discussed need to be made transparent in the written channel - decisions should be finalized only there. As a side effect this leads to passive base documentation that is very valuable for any newcomer to the project.

(5) Allow written advice to accumulate in a persistent, searchable archive

All project communication, in particular decisions taken and discussions leading up to those decisions, need to be archived. It must be possible to reference communication via stable URLs. Previous communication needs to be stored in a way that can easily be searched.

Two caveats though:

1. This does not replace structured documentation. It can serve as a starting point to collect structured documentation though.

2. There are exceptions to the rule of everything being written and accessible to the entire organization: People related discussions as well as security related discussions are sensitive and should not be held in public.

(6) Reward Trusted Committership

All contributions (e.g. source code, documentation, bug reports, input to discussions, user support, marketing) are welcome and are being rewarded. Those showing support for the project are being invited as Trusted Committers. All Trusted Committers of a project are published.

Resulting Context

• Organization members understand which challenges they can address by applying InnerSource best practices.

• Organization members lacking prior open source experience understand the basic values and principles of InnerSource projects.

• Organization members lacking prior open source experience are able to check their daily activities against a set of common established values.

• The organization's development practices become more similar to open source projects thus making it easier for organization members to participate in open source projects.

Known Instances

• Europace AG

• GitHub

• Robert Bosch GmbH

• Siemens' InnerSource strategy is built upon the guiding principles of Documentation, Workflow, Transparency, Continuous Integration and Culture which are detailed in their InnerSource portal.

Europace AG

The InnerSource principles listed in the Solution section above are mostly based on Europace's experience. See details (in German).

GitHub

Purpose

Often at GitHub we work in a model where teams contribute features to areas outside their area of responsibility. Common examples include sales engineering contributing features to unblock a sale, Special Projects contributing urgently needed, high impact features across the product, and a team working across multiple areas to deliver a feature.

Principles

Overall the principles outlined in this doc are to avoid increasing tech debt and support burden for the owning team. Oftentimes help is being lent to a team because they are behind due to support and maintenance costs in their area of responsibility and they do not have bandwidth to contribute to the feature. Any new features done by another team that add to that support burden or tech debt means even less time for the owning team to work on new features, so we want to make sure they are done right.

At the same time, we strive to be a company where engineers freely work across boundaries, and business priorities often require that we contribute to areas outside our core areas of ownership.

A good summary of the principles is to leave the area in as good as or better shape than you found it.

With that in mind, here are principles we agree on:

• Avoid minimum viable products (MVP) that accrue feature debt. It is ok to ship an MVP to get customer feedback, but the contributing team must be committed to finishing the feature set. Examples include:

  • Commitment to go beyond MVP to a solution that will satisfy most customers.

  • Full support for administration of new features (e.g. support in the settings UI vs. just doing a command line).

  • Surface features in both the UI and API vs. only deliver an API (or vice versa)

  • Ensuring features work in cloud and local server environments.

• Support the feature work up to and beyond its deployment to production

  • Coordinate incremental rollout

  • Handle support tickets

  • Plan time to address customer feedback (features and bugs)

• Build features in the right way (do not accrue tech debt)

  • Agree on requirements and solution with Product and Engineering teams

  • Proper architecture and design

  • Make sure data is stored properly to avoid later data migrations.

  • Appropriate telemetry is in place

  • Appropriate test coverage is in place

  • Supported on cloud and local production environments (including setup, configuration, backup / restore, migrations, etc.)

  • Bugs fixed

  • Documentation updated

Engagement

We use an engagement model because we like to lay out what concrete steps can be taken by a team when contributing features to areas outside their area of responsibility.

A typical engagement model at GitHub looks like this:

• Get approval on the feature set and rollout plan from the product owner.

• Get approval on engineering design, including addressing the non-functional requirements (telemetry, test coverage, multi-environment testing and support) from the engineering owner (typically engineering manager and director).

• Do code reviews along the way, along with reviewing any new or changed requirements.

Robert Bosch GmbH

Purpose

Fostering collaboration, learning and innovation is the main focus of the Bosch InnerSource initiative (BIOS).

Principles

To that end, Bosch applied the following principles:

• Openness: We lower the barriers for entry into BIOS communities as much as we can.

• Transparency: We are radically transparent and share our work products, our communication, and our decision making with all associates in the company.

• Voluntariness: The decision to join and contribute to a BIOS community is left to each associate. Associates should work within BIOS because they are intrinsically motivated, not because their manager told them so.

• Self-Determination: BIOS communities are free to choose what to work on, when they work and what tools and processes they use to work.

• Meritocracy: Power is vested in BIOS project members based on their merits, that is, based on the quality and quantity of their contributions.

The principles Openness, Transparency and Voluntariness helped grow diverse communities of intrinsically motivated associates.Meritocracy has proven to be an effective motivation for making great contributions.Self-Determination allowed the communities to use their limited time for contributions in the most effective and efficient way.

Status

Structured

Authors

• Isabel Drost-Fromm

• Georg Grütter

Acknowledgments

• Zack Koppert - for sharing GitHub's approach in the Known Instances

Alias

Explicit InnerSource Principles

Title

Repository Activity Score

Patlet

Problem

In which order shall InnerSource projects be presented? Typical ranking KPIs like GitHub Stars, Number of Forks, Number of Commits, Lines of Code, Last Update aren't sufficient to concisely indicate the activity of a project.

Active projects with a lot of traction, but also fairly new and enthusiastic projects that are in need of new contributors should be ranked higher than matured projects with little activity or in maintenance mode.

A new metric derived from several KPIs is needed to define a reliable and versatile score for a project's activity level. It can be used to sort projects according to their activity level.

Story

When InnerSource is practiced for a long time or scales beyond a certain number of projects (let's say 50 to give a meaningful threshold) it is hard to find the currently most popular and active InnerSource projects. Projects that exist for a long time are well-known but may no longer be very active. Fairly new projects on the other hand don't have a reputation or an active community yet.

A list of InnerSource projects should not be considered a static resource, but an exciting place to discover and explore new and active projects, just like a news page listing the most interesting topics of the day first. Thus it is beneficial when the order of the projects is regularly updated and changes according to the project's popularity and activity.

These considerations led to a first prototype to calculate a repository activity score, which worked surprisingly well and determines an ever-changing order of projects according to their activity.

Context

Forces

Automated KPIs that can be fetched by querying the GitHub API are only part of the truth. What about code quality, the availability of good documentation, or an active and helping community that makes the project a fun place to contribute?

Such "soft" KPIs would have to be manually or semi-automatically added to the calculation and the resulting score. If tools exist that provide more context for the repository, like a code coverage reporting, they can easily be worked in.

Sketch

Solutions

The repository activity score is a numeric value that represents the (GitHub) activity of an InnerSource project. It is derived automatically from repository statistics like GitHub stars, watches, and forks and may be enriched with KPIs from other tools or manual evaluations.

In addition, it considers activity parameters like last update and creation date of the repo to give young projects with a lot of traction a boost. Projects with contributing guidelines, active participation stats, and issues (public backlog) receive a higher ranking as well.

The code below assumes the variable repo contains an entity fetched from the GitHub search API and the participation object contains an entity from the GitHub stats/participation API.

Resulting Context

Contributors are free to commit a part of their time to InnerSource project. They may choose to contribute to a project that they depend on for the work in their regular team anyways. However they may also choose to contribute to something completely different, based on their interests and personal development goals.

Projects can be sorted and presented by repository activity score to give a meaningful order in a portal presenting projects to potential new contributors. The score can be calculated on the fly or in a background job that evaluates all projects on a regular basis and stores a list of results.

Rationale

The repository activity score is a simple calculation based on the GitHub API. It can be fully automated and easily adapted to new requirements.

Known Instances

• Siemens includes repository activity in their InnerSource project quality score. Maintainers can use the quality score to improve their project and communicate their score via badges.

Status

• Structured

Author(s)

Acknowledgments

Thank you to the InnerSource Commons Community for lightning-fast advice, and a lot of helpful input to feed this pattern! Especially:

• Johannes Tigges

• Sebastian Spier

• Maximilian Capraro

• Tim Yao

Title

Praise Participants

Patlet

When you receive an InnerSource contribution, it's important to thank the contributor for their time and effort. Extending your gratiutude not only effectively acknowledges the contribution but also engenders further engagement from the contributor and others. Praising contributors' positive contributions to your InnerSource project motivates those contributors (and their managers) to continue investing in the effort.

Problem

How can we properly express our gratitude to a contributor for their contribution to an InnerSource project? We may not know precisely which words or communication channels we should use to express ourselves sincerely. But recognizing and thanking contributors is critical for keeping those contributors (and their managers) engaged in the work. Luckily, effective praise for participants follows a pattern, and following this pattern helps ensure that our messages of thanks come across clearly and graciously. It also makes us less likely to forget to praise our contributors, which is unfortunately too easy to do.

Context

• You value the community of contributors and want to maintain and grow it.

Forces

• You are busy, which makes forgetting some soft touches (like praise and thanks) easier.

• You may not be someone that is comfortable in social situations or good with words.

• Peer recognition is very important to job satisfaction and career development.

Solutions

Being recognized by others feels good. And in a professional setting, recognition from peers can also increase your organizational influence and career growth. Any time someone contributes to your InnerSource project, recognize them with an authentic, sincere "thank you." Be sure to highlight specific examples of ways these contributions have impacted the project positively.

For non-trivial contributions (all code contributions and significant time contributions), say "thank you" via the following mechanisms:

(1) Call out the person by name in any chat location (e.g. Slack) where you organize your project activity. Let everyone know what they did and thank them publicly.

Example:

Everyone @here give a high-five to @andrew.clegg for updating the rcs-viewer to the latest version of the hebo-client (https://github.com/rcs/rcs-viewer/pull/81). Thanks for helping keep this library up-to-date, Andy!

(2) Email them and their manager (cc'd) privately, thanking them for the contribution. For code contributions, consider forwarding the merge notification mail.

Example:

Hi, Andy, I want to thank you again for making this update. It may have been a small amount of time, but it's attention like this from each person that make the RCS project work for all of us. Thanks for solving your own problem in a way that also makes the rcs-viewer better for everyone.

Resulting Context

Feedback like this leaves the contributor with a fantastic feeling and ready to re-engage in the project. Combining both forms of thanks gives them recognition in front of their peers (breadth) and in front of their direct manager (depth). There's a subtle encouragement for those peers in chat to consider contributing themselves and for that manager to look for appropriate circumstances to encourage their other direct reports to do the same. Additionally, awareness of the InnerSource project spreads to the manager, who may have previously not known of the team's use and involvement with it.

One caveat: keep it real. Make sure that your words stem from the sincere thanks that you feel inside for what they've done. Keep the level and verbosity of praise appropriate to their level of involvement. Overdoing it may feel insincere and mechanical and defeat your purpose in reaching out.

Related Patterns

Known Instances

• Nike (multiple projects)

• Siemens awards successful InnerSource projects and contributors at their yearly internal InnerSource Summit.

Status

• Structured

Author(s)

• Russ Rutledge

Acknowledgments

Title

Issue Tracker Use Cases

Patlet

The InnerSource host team fails to make not only plans and progress but also context for changes transparent. This is solved by increasing the use cases for the project issue tracker to also serve brainstorming, implementation discussion, and feature design.

Problem

A team develops a component that many teams in the organization depend on. It uses a standard issue tracker for tracking open bugs and feature requests. However, the context in each entry is very limited. As a result potential contributors have no way of knowing what change exactly each issue is talking about.

Context

The InnerSource project tooling is all setup. However, the project issue tracker is mainly used for sharing progress. In InnerSource projects there are many more use cases that an issue tracker can be used for that make remote, asynchronous communication easier.

Forces

• Contributors would like to understand whether the feature that they are missing is already on the roadmap. With a lot of context missing in issues though it is impossible to decide whether existing issues match the contributing team's needs.

• As a result a lot of duplicate issues are being opened that the host team has to deal with.

• As context in open issues is so limited contributors are unable to help the host team by implementing some easier issues that are open already. As a result a lot of work remains in the hands of the host team.

• With a strong focus on verbal communication it is impossible to discern after a couple months or years why a certain feature was being chosen for implementation. As a result refactorings, in particular simplifying the component becomes an exercise in project archaeology and brain picking of people who remember what was discussed.

Solution

Embrace the "written over verbal" philosophy not only for pure software development but also during the planning phase of new features:

• For bugs, planned features and feature ideas create separate issues. In each of those include as much information as possible so that potential external contributors are able to understand the context. Ideally, in particular for easier changes, include enough information for external contributors to support the host team by implementing the functionality in question.

• Potentially use the issue tracker as a channel to ask questions. This is in particular helpful if you are lacking other communication sources to tackle user questions.

• Make use of tags and categories in order to distinguish issues used for different purposes.

• For starting a brainstorming session asynchronously, open an issue for gathering ideas. When discussion is starting to calm down, summarize the points identified in this issue in a separate document. Post that for review as a pull request to drill deeper into individual points that still need clarification. The resulting document can be used to publish the results in other appropriate channels as well as for future reference.

• Most issue tracker implementations allow for issue templates. Make use of those not only to collect commonly needed information for bug reports but also include hints about what kind of information is needed for the other usage types.

Resulting Context

• Making more use of the project's issue tracker for communication enables external contributors to follow along and make better decisions on what to contribute.

• A focus on structured written communication enables host team members to participate remotely.

• Consistently communicating in writing means that passive documentation on project decisions accumulates as a by-product instead of needing added attention.

• Consistently using public communication channels leads to more humans following a discussion. This means that there are more knowledgeable humans that can answer questions, chime in on open issues, or point out flaws in planned features that would otherwise be found only much later.

• Moving discussions to a public discussion medium creates an opportunity for potential future contributors to lurk, follow along, get comfortable and learn the ways of the project long before they have the first need to get involved.

Known Instances

• Siemens manages work on their InnerSource Platform in a fully transparent way. Therefore the work on the InnerSource Platform itself is organized as an InnerSource project. This includes tracking enhancements and bugs, as well as marketing, communication activities and support requests from users.

Authors

Isabel Drost-Fromm

Status

Structured

Title

Review Committee

Patlet

The InnerSource working model is a radical departure from more traditional approaches, for developers and managers alike. By establishing a review committee as an interface between the InnerSource initiative and all senior managers of business units participating in it, the latter are more likely to familiarize themselves with the initiative and support it, as it affords them a certain level of oversight and control without fostering micromanagement.

Problem

Managers will perceive the InnerSource working model as a radical departure from the working models they are accustomed to and have experience with. As a consequence, it is likely that they will either reject or micro manage the InnerSource initiative in order to try to minimize the perceived risk of this change. In both cases, the benefits of InnerSource can not be realized. As a result, InnerSource is subsequently discredited.

Context

Company A wants to introduce its first InnerSource initiative. Most managers in company A are not familiar with the Open Source working model and are instead accustomed to hierarchical, top-down control style management.

Forces

• The more perceived control a manager has over the work in the InnerSource initiative, the more likely it is that she or he will support the initiative without prior experience.

• The less experience a manager has with the open source working model the more likely it is that she or he will want to control the risk of the initiative.

• The more heavy handed and micro managerial InnerSource initiatives are managed, the less likely it is that the open source working model can be adopted to the required extent. As a result, the benefits of InnerSource will not be realized.

Solution

• Establish a review committee comprised of senior managers of all business units which participate in the InnerSource initiative.

• The review committee members are given the authority to decide as a group which InnerSource projects will receive support in general and funding in particular.

• Applicants can be elected by review committee members before meetings to present their proposed InnerSource project during review committee meetings for consideration.

• Leaders of InnerSource projects currently funded by the review committee are obliged to report on the status of their project during every review committee meeting.

• Review committee members are obliged to provide constructive feedback to both new applicants and current project leaders during review committee meetings.

• Every InnerSource project is to be given the chance to react to feedback received on one session of the review committee until the next session in order to avoid shutting down the project prematurely.

• An InnerSource project leader can also present the motion to be shut down on its own initiative on a review committee. The review committee then has to decide whether or not the business units using the software need to be given time to put measures in place to ensure that development and/or maintenance of the codebase continues until an alternative solution to development by the InnerSource community is found (if business relevant or mission critical).

• The review committee should convene regularly. A cadence of two meetings per year has proven successful.

• The review committee can become optional, if InnerSource has been widely adopted and understood by the organization.

Resulting Context

• Managers apply a tool they are comfortable with to InnerSource in order to get the required amount of information about and control over the inner workings of the InnerSource initiative. This familiarity will make it more likely for them to sign off on the InnerSource initiative and grant the required degree of freedom for InnerSource projects.

• Developers can still self organize to a sufficient degree. Micro management does not happen because the review committee convenes rather infrequently.

Known Instances

• BIOS at Robert Bosch GmbH (in the early stages of adoption, only - 2009-2012)

Status

• Structured

• Finalized and Reviewed as of 8/31/17.

Authors

• Georg Grütter, Robert Bosch GmbH

• Diogo Fregonese, Robert Bosch GmbH

Alias

Cheese Interface

Title

Service vs. Library

Patlet

Teams in a DevOps environment may be reluctant to work across team boundaries on common code bases due to ambiguity over who will be responsible for responding to service downtime. The solution is to realize that often it's possible to either deploy the same service in independent environments with separate escalation chains in the event of service downtime or factor a lot of shared code out into one library and collaborate on that.

Problem

When teams are working in a DevOps environment developers are responsible for a feature end-to-end: From the customer down to deployment, maintenance and support. This poses a challenge when working across team boundaries: Escalation chains may not be the same for errors happening in either team. Coupling source code and deployment leaves the teams with the question of who is responsible for on-call support in the event of errors. As a result teams are reluctant to join forces even if there is significant overlap in requirements.

Context

• Teams are working in a micro-services environment.

• They are organized in fully functional DevOps teams: Each team is responsible for their contributions end-to-end, including maintenance, on-call and customer support.

• A team is tasked with providing a service to their downstream customers that is fairly similar to an existing service built by another team.

Forces

• Organizational escalation paths may be different for each of the teams.

• Members of each team may be unwilling to answer on-call support for errors that do not affect their own downstream customers.

• Severity levels for the same types of errors may be different across team boundaries due to different SLA definitions per team/customer relationship.

• Teams may have different security or regulatory constraints governing their deployments.

Solutions

Decouple responsibility for source code from deployment: Both teams work to identify exactly where there is overlap and synergies.

Only shared source code is kept as part of the InnerSource project with shared responsibility. The shared source should be coherent in that it includes all testing code (including integration tests if available) and as much of the CI pipeline as is possible to make contribution validation easier.

Decouple configuration and deployment pipelines from actual business logic. Establish a second deployment of the service for the second team.

Treat the common base as a library that is used by both teams with shared code ownership.

Deployment configurations can be included as separate projects in your InnerSource portfolio to allow teams to discuss/collaborate or a new team to copy them.

Resulting Context

Teams are willing to collaborate, benefiting from sharing the work of implementing the business logic.

A service that originally was built specifically to work in one environment is converted into a more general solution based on a specific business requirement.

Both teams get to know their respective escalation policy and deployment setup, potentially identifying improvements for their own setup.

The likelihood that changes are needed and made in the shared source code increases, leading to more frequent opportunities to refine, improve and optimize the implementation.

Encourages incremental operational standardization in release packaging, telemetry, health/readiness endpoints and so on as the teams realize they can more efficiently maintain this in the shared code if they agree on standard conventions.

See also

Known Instances

• Europace AG

Status

• Structured

Author(s)

• Isabel Drost-Fromm

• Rob Tuley

Acknowledgments

Thank you Tobias Gesellchen for review internal to Europace AG.

Alias

Service vs. library: It's inner source, not inner deployment

Title

Explicit Governance Levels

Patlet

Different teams within an organization use InnerSource practices in varying ways, leading to confusion and inefficiencies due to inconsistent expectations of collaboration and contribution rights. Establish centrally documented governance levels that define the extent of influence contributing teams can have on a project, improving clarity for contributors and host teams alike.

Problem

Several teams are using InnerSource practices. However the degree to which they welcome contributions and give equal collaboration rights to contributors differ. Despite these differences, all teams refer to their way of working as "InnerSource" without any additional qualifiers.

The result is confusion and frustration when teams collaborate as the expectation of what InnerSource means in practice is different in each team. This confusion also affects strategy planning and decisions on future InnerSource intent as the term is too vague which leads to long discussions and time lost on clarifications.

Story

Example of Confusion

New users of either project are regularly confused about the level of influence they can gain in the respective project. This leads to long discussions, escalations and time lost on clarifications.

Example of Delayed Decision

Project C is currently closed source and used only by team 1. Team 2 want to use project C and the leadership of the two teams negotiates options which include InnerSource practices. Agreement takes longer than expected because the "InnerSource" term did not describe a target state that could be agreed without ambiguity, and the teams had to document bespoke options for their leadership to consider before a decision could be made.

Context

• InnerSource concepts are established within an organization with multiple projects and teams adopting InnerSource.

• Internal InnerSource practices are not prescribed in detail.

• Teams/projects have the autonomy to optimize for their local circumstances.

Forces

• Projects adopt different InnerSource patterns and practices to optimize for their context.

• Users want clarity on the level of influence they can gain in an InnerSource project when deciding whether or how to use it.

• Leaders want clarity on InnerSource project intentions to understand the expected cost and benefits.

• Writing a detailed description of a set of InnerSource practices requires significant effort.

Solution

Create centrally maintained documentation of the project governance levels that are used in your organization. The governance levels describe how much influence the host team of a project is willing to share with contributing teams. Or in other terms, the level of influence a contributing team can gain in the respective project.

Note: Instead of "governance levels" we might also say "operating models", or "ownership models". We stick to the term "governance levels" throughout this pattern. Feel free to use whatever terms fits your organization best.

To establish governance levels in your organization, we recommend these activities:

1. Define your governance levels - Goal: Have a clear written description of the governance levels, that you can refer to as a reference.

2. Promote your governance levels - Goal: The governance levels are known and understood throughout your organization.

We will go into more detail on each of these activities in the following sections.

Define your Governance Levels

The goal of this activity is to have a clear written description of the governance levels, that you can refer to as a reference.

• Document the governance levels that are commonly used in your organization.

• Document additional governance levels that you don't have yet, but that would benefit the cross-team collaboration in your organization.

• Give each of them a distinctive and descriptive name.

• Use specific projects as examples where helpful.

• Keep this documentation in a central place that you can easily reference that can be accessed by everybody.

Commonly used Governance Levels

The following governance levels are commonly used when practicing InnerSource.

Each of these levels adds more influence/karma to the contributing team. However each step also requires more transparency and shared communication resources between both teams.

1. Bug Reports and Issues Welcome:

   • People outside the host team may use the code.

   • They can submit feature requests and bug reports for things they would like to see changed.

   • aka Readable Source, Shared Source

2. Contributions Welcome:

   • People outside the host team may use the code.

   • They can make modifications and submit them to the host team for inclusion.

   • aka Guest Contributions

3. Shared Write Access:

   • People outside of the host team can get write access to the project.

   • The host team may give outside contributors additional leverage in the strategic direction of the project.
4. Shared Ownership:

   • Members of different teams collaborate on the project as equal peers.

   • Everyone has the ability to merge code.

   • Everyone has an equal say on the project direction.

   • Everyone has an equal say in who else to add to this group.

   • aka Distributed Ownership, Maintainers in Multiple Team

Promote your Governance Levels

The goal of this activity is that the governance levels are known and understood throughout your organization, and that some of your higher profile InnerSource project start to adopt these governance levels explicitly.

• Present your governance levels in existing knowledge sharing forums in your organization. Make sure to explain the why, not just the what!

• Whenever talking about your governance levels, make sure to stick to he exact names/titles of your governance levels.

• Create training material containing examples of projects in your organization. That makes it easier for people in your organization to related to these examples and understand what these governance levels mean and how they work.

• Present the governance levels as a menu of adoption options when launching new InnerSource projects.

Resulting Context

• Cross team communication occurs efficiently without confusion, using terms that are universally understood and centrally documented.

• Organization leaders understand the nuances within practicing InnerSource and make better informed and more precise decisions that are easier to communicate.

• Increased standardization of InnerSource practices within the organization as the named and documented building blocks are used by teams as a menu for adoption.

• Teams can adopt InnerSource best practices in a step-by-step way which makes adoption easier and less intimidating.

Rationale

Like "InnerSource", Open Source is also a broad term.

There are projects on GitHub, published purely for the pleasure of the author with no intention of long term maintenance, not intention to fix bugs submitted by users. This would be the equivalent of "Bug Reports and Issues Welcome" - you can report the bug, but its on the owner to find the time to fix it. We call this shared source, which would not qualify as open source software (OSS) yet.

There are projects where the roadmap is created in-house, hidden from public view. Where commit rights come and go with the contract of the employees of one company (e.g. MongoDB, Elastic, Tensorflow). Users are welcome to submit patches, they will even be mentored through. All development happens in the open, but control and strategy is never shared. This would be the equivalent of stage "Contributions Welcome". We call this single vendor OSS.

There are projects that share write access, but do not share the power to decide who gets write access next. This applies to everyone who is only a committer at an Apache project.

There are projects that are fully shared across multiple independent organizations (e.g. k8s, any Apache project) - those would be "Shared Ownership". We call this vendor neutral OS.

The same levels make sense inside of organizations.

Known Instances

• Flutter Entertainment

• Europace AG

Flutter Entertainment

Status

• Structured

Authors

• Isabel Drost-Fromm

• Rob Tuley

• Tom Sadler

• Sebastian Spier

Alias

• Governance Framework (for InnerSource)

• Defined Project Governance

• Project Ownership Models

• Explicitly Defined Governance

• InnerSource Operating Models (seems a bit too broad, as readers might expect this to include CI/CD setups, code review tooling, and the like)

Title

Transparent Cross-Team Decision Making using RFCs

Patlet

InnerSource projects that want to achieve high participation rates and make the best possible decisions for everybody involved need to find ways to create participatory systems throughout the full software lifecycle. Publishing internal Requests for Comments (RFCs) documents allows for discussions early on in the design process, and increases the chances to build solutions with a high degree of commitment from all involved parties.

Problem

For an InnerSource project to be healthy, it needs a substantial amount of contributors. These contributors (or teams) maybe have different requirements for the given project. e.g. they may want to add features to the project that are not compatible with one another or lead to an unhealthy bloat in the architecture.

Discovering such disagreements or misunderstanding late in the process, e.g. once the software has already been built, is very costly. These disagreements may lead to frustrations by all parties involved, and can even be disruptive to the health of the collaboration culture in the project. A common situation where such a disagreement surfaces is a change request (pull request) which is open for a very long time because the author of the change request and the maintainers of the project essentially don’t agree that the proposed change should be made at all.

For an InnerSource project this situation happens more frequently when the project is maintained by multiple teams in the company i.e. shared ownership.

Story

A project, or application made up of multiple projects, is maintained by a number of different teams, with each team owning different areas of the project or application. These teams do make InnerSource contributions to each other's areas, but larger, cross-cutting changes are only ever driven by the teams' technical leads working together, or don't happen at all. This results in most engineers unable to effect large scale, cross-cutting change, reducing innovation and opportunities for collaboration.

By implementing a process and template for RFCs, teams and individuals are empowered to propose large, cross-cutting changes via a transparent decision making process, with consultation across teams done asynchronously. This results in greater innovation, closer collaboration, and more knowledge spread. This is dependent on buy-in from all disciplines at all levels, and an environment of psychological safety so that people can openly propose and debate ideas.

Like with any process, this must be continually improved upon. There may need to be changes to the RFC template or process to ensure it is inclusive, collaborative, and effective.

Context

• shared ownership by many teams of an InnerSource project

• overarching design decisions cannot be made from a central body all the time (e.g. a group of architects) as they have neither enough time, nor sufficient domain-specific knowledge to make good decisions in all the cases

• various types of users have input on the direction that a certain project is taking. Such user may be: Developers, Product Owners, Product Managers, etc

• decisions need to be made in a asynchronous fashion, at least partly, as it isn’t feasible to call frequent synchronous meetings with all participants

• there is a desire to document the decisions made, i.e. making sure that they are made in writing, rather than just verbally

Forces

• most of the times, the involved parties want to make a decision fairly quickly (e.g. the up-front design time is fairly limited)

• writing things down (without already implementing things) is often a new skill for many of the people involved

Sketch

Solutions

Important elements of the solution are:

• a description of when to publish an RFC (and when not to)

• a template for RFC documents

  • should provoke RFC author to consider their proposal from multiple angles

  • should prompt both high level accessible overview, and detailed in-depth explanation

• a well known, lightweight process surrounding RFCs e.g.

  • how to publish RFC and share it with all stakeholders (e.g. Slack, mailing list)

  • how to collect feedback for the RFC

  • how to work in the feedback

  • how to move the RFC towards a conclusion or decision (e.g. relevant nominated maintainers to sign off)

  • appropriate tooling chosen (e.g. non-engineers may not have access to source control tools)

• a commitment to iterate on the RFC template and process

Examples/Templates

Resulting Context

Implementing an RFC-like process has proven to be valuable, as it makes the cross-team decision making process more transparent for everybody, allowing for all voices to be heard.

Observable positive effects:

• democratization of the decision making process for decisions that impact many teams (also offloading team leads from that burden)

• a open asynchronous communication method that works well across multiple teams and geographies

• empowers individuals and teams to effect large scale change

• record of decisions made for people to refer back to for context

• scales impact of experienced engineers as they can contribute to solutions asynchronously and remotely, rather than needing to be present in a meeting

• terminology alignment e.g. by spelling out our testing terminology such as “what is a system test?”

• process alignment e.g. by spelling out the out-of-hours support process

• greater clarity of thought, as writing an RFC makes the author challenge herself more than they would normally

The RFC approach also has risk that we want to call out:

• It doesn’t always work! e.g. some people might still argue against a decision that was already made via an RFC. However having the decision making process in writing is still beneficial in these scenarios, as you can point people to when and why a certain decision was made.

• An RFC may become big and too unwieldy. This often shows in long comment threads and discussions surrounding it. In those situations we may decide to complement the RFC with synchronous communication such as a working group and in-person meetings. But time is still saved, as people can read the RFC before the meeting rather than having all the information shared during the meeting.

Rationale

Known Instances

Status

Structured

Author(s)

• Tom Sadler

• Sebastian Spier

Aliases

• Architecture Decision Record (ADRs) - Not necessarily a direct alias, as they can sometimes be used very differently e.g. RFCs for seeking input and building consensus, ADRs for recording decisions and implementation detail

Title

Maturity Model

Patlet

Teams have started adopting InnerSource. The practice is spreading to multiple departments. However, the understanding of what constitutes an InnerSource project varies. The solution is to provide a maturity model to allow for teams to go through a self check and discover patterns and practices that they are not yet aware of.

Problem

When InnerSource adoption in an enterprise starts to increase, individual mentoring of each project through one evangelist becomes unfeasible. Also, more and more people are gaining at least a basic understanding of what it means to work in an InnerSource project. Looking at all InnerSource projects though the depth of understanding for the concept will diverge. Teams may not be aware of proven patterns that would help them move to the next level and solve issues and pain points that they are dealing with.

Context

Several teams have started adopting InnerSource practices. The exact level of understanding of the practice diverges between teams. The exact problems teams run into diverge depending on the context and working environment of each team. As a result the definition of what are important best practices in an InnerSource project differs depending on each team.

Forces

Teams sharing InnerSource learnings run into misunderstandings as they are not aware of their respective level of InnerSource adoption.

Teams are not aware of best practices that would help them solve issues that they run into in their daily doing.

Solution

Ask teams to self assess against the proposed maturity model.

Transparency

Plans & Products

InnerSource project benefit from planning being transparent across the organization by enabling stakeholders to better understand decisions and influence them in a way that can be followed by others.

• PP-0: Individuals and teams do not regularly disclose their plans or products to multiple stakeholders. No formal actions exists at the organization.

• PP-1: Individuals and teams give visibility to their plans or products to multiple stakeholders, before they are started. Shared roadmap.

• PP-2: There are already shared roadmaps with clear guidelines and contribution rules where stakeholders can provide feedback. However, this is not standardized across the organization and not all of the projects provide this info.

• PP-3: Roadmaps are shared by default and there is a standard process and homogeneous way to do this across the organization at the level of each InnerSource project. This contains clear rules to contribute and influence in the roadmap.

Development Process & Tools

InnerSource projects thrive when contributors become active and participate. As a result, making contribution easier should be balanced with pure technical goals.

• DP-0: Each team follows its own development process and tools. They are not defined to share knowledge and artifacts outside development team. Siloed development teams.

• DP-1: Development teams use shared code repositories, internally. Some teams develop their own CI process, using non corporate or standard CI tools. There is no code review process defined, although some projects teams do it internally.

• DP-2: The organization sponsors and promotes a shared repository for collective knowledge. Some teams develop their own CI process, using corporate CI tools. There are CI environments. Code review process defined, and used by some projects. Sometimes code review is done by outside team members.

• DP-3: Most teams develop their own CI process, using corporate CI tools. There are CI environments. Code review process defined, and used. Code review is done by both, internal and external team members.

Decisions

In order to motivate colleagues to contribute work outside of their core team they need visibility into the decision-making process of the host project - but also feel that their voices are being heard and valued.

• DC-0: Decision-makers often intentionally or accidentally withhold data and resources related to project decisions.

• DC-1: Materials that are part of decision-making practices become available for review after decisions are finalized.

• DC-2: People feel like they know about—and are helping to shape—most (but not all) important decisions as those decisions are unfolding. Materials that are part of decision-making practices are available at defined project milestones.

• DC-3: People feel like they are a part of a shared, standard process for collective decision-making that the organization endorses. Materials that are part of decision-making practices are continuously accessible during work processes.

Helpful Resources

In order to attract contributors helpful supporting material needs to be easily accessible.

• RS-0: Individuals and teams neither contribute to nor draw upon a shared repository of knowledge.

• RS-1: Individuals and teams release project materials for review internally, after they've finished their work. Individuals and teams share resources, but in disconnected, fragmented, or individualized/siloed systems or repositories. Individuals and teams share resources, but there is no commonly expressed or shared understanding of the criteria used to determine whether information is sensitive or not. Do not "share thinking on others".

• RS-2: Individuals and teams make project-related materials accessible to some members of project teams according to clearly defined and shared formats and/or protocols. Individuals and teams withhold sensitive data and resources, provide limited details, context, and scope.

• RS-3: Individuals and teams make project-related materials broadly accessible to the organization—and possibly outside the organization as well—according to clearly defined and shared formats and/or protocols. Individuals and teams who must withhold sensitive data and resources are clear about what they're not sharing, and others understand why those materials are not available to them.

Stories

When working in host teams mistakes will automatically be widely visible. In order keep contribution levels up, corporate culture needs to celebrate failure as an opportunity for growth and learning.

• ST-0: Individuals and teams do not share successes or failures for others to learn.

• ST-1: Individuals and teams are comfortable sharing stories about successes, but not about failures.

• ST-2: Individuals and teams are comfortable sharing stories of successes and failures during retrospectives and reviews.

• ST-3: Individuals and teams are comfortable sharing stories of successes and failures, and learn from failures according to formal protocols.

Collaboration

Channels for Providing Feedback

For silos to be reduced colleagues need to be comfortable sharing feedback openly. One easy way to support that is to use the same communication principles across hierarchies.

Ideally you will end up with proper communication channels that are known by anyone in the organization - with channels focused on different goals (announcements, user support, development channels, infra discussions, etc.). Some of the best practices you will establish as your InnerSource projects mature: Adoption of netiquette guidelines, opening a proven set of standard channels (which are being archived, publicly accessible, searchable) for each new InnerSource project.

• CF-0: There are no processes nor established channels. Some members of the organization share materials via private channels or discussions.

• CF-1: The organization is in the process of establishing internal guidelines and channels for encouraging diverse points of view about company/departmental decisions, so that anyone belonging to the organization can use them. Some members of the organization share decision-making materials informally using unofficial platforms. Leaders maintain at least one clear and direct channel for organization members to share opinions constructively on some matters relevant to their work.

• CF-2: The organization has established internal guidelines and channels, and provides specific resources (training programs, access to content, etc.), for encouraging and soliciting diverse points of view on team or decisions.

• CF-3: Members of the organization share decision-making materials on officially sanctioned platforms Members of the organization share materials openly via multiple channels and methods for feedback. Leaders use those channels themselves, openly encourage others to use them, and maintain team-facing or public-facing records of the feedback they've received and/or the actions they've taken to address this feedback.

Leadership

InnerSource projects encourage employees to contribute to projects outside of the direct influence of their direct line manager. This needs a culture of trust.

• LS-0: Command & control culture, within a highly hierarchical organization.

• LS-1: Some leaders are open to receiving feedback and creating an environment where people feel safe providing it.

• LS-2: Most leaders in the organization are open to receiving feedback and creating an environment where people feel safe providing it. Leaders show passivity about understanding whether all members feel empowered and enabled to share. Organization encourages leaders to actively seek voices not present in dialog out for inclusion.

• LS-3: Members feel empowered and enabled to share opinions constructively on any matter relevant to their work or about which they feel passionate.

Organizational and Functional Structure

When InnerSource leaves the pure coding level and enters the community and working group level, there is potential for reducing silos even where direct code collaboration is not possible.

• OF-0: Working groups tend to be static in terms of membership and skill sets.

• OF-1: Cross-functional teams exist, but team roles are often unclear and governance structures are vague.

• OF-2: Cross-functional teams are common, and teams post their roles and goals publicly.

• OF-3: Cross-functional teams are common and make their activities known broadly to the organization; in turn, the organization promotes best practices for working together.

Contribution

The goal with designing contributions patterns needs to keep collaboration in mind if it's to reduce silos.

• CB-0: Completely siloed, no collaboration outside the teams. Just some collaborations due to cross-functional teams.

• CB-1: Members of the organization and teams collaborate but frequently say it's "too difficult". Teams infrequently revisit the outcomes of their collaborations.

• CB-2: Members of the organization and teams actively seek opportunities to collaborate. Teams routinely discuss, revisit and debate the outcomes of their collaborative efforts, and make these outcomes available by default.

• CB-3: Members of the organization collaborate both internally and externally in ways that benefit all involved. Teams routinely discuss, revisit and debate the outcomes of their collaborative efforts, and share their learnings outside the organization, and make these outcomes externally available by default.

Community

Sharing Policies

Having a baseline of shared values makes it easier to work across team boundaries. Crossing boundaries becomes easier if a limited set of baseline rules and guidelines apply everywhere and can easily be referenced.

• SP-0: No sharing culture nor written policies.

• SP-1: Some members of the organization unite to define values and principles, but are not clearly supported when they do.

• SP-2: Members of the organization collectively document shared visions and agreements like mission statements and codes of conduct, make them easily accessible, and reference them often. On-boarding materials and orientation rituals provide adequate context for helping new members understand how the organization will benefit from their contributions.

• SP-3: Shared values and principles inform decision-making, conflict resolution, and assessment processes among members of the organization, who reference these values and principles consistently in both verbal and written formats.

Feel part of the Organization

One of the possible reasons for introducing InnerSource into organizations can be increased engagement. This point tracks how engagement is changing while adopting InnerSource.

• PA-0: Low engagement, no collaboration and people do not feel comfortable sharing with others.

• PA-1: Members of the organization feel comfortable sharing their thoughts and opinions without fear of retribution, but only in familiar domains. People understand that the best ideas win, and leadership responsibilities accrue to people with histories of contribution and commitment.

• PA-2: Members of the organization feel comfortable sharing their thoughts and opinions without fear of retribution. Leaders demonstrate dedication to the organization's shared values.

• PA-3: The organization is proactive in telling members that it benefits from their contributions; as such, members demonstrate shared consciousness and empowered execution, and feel a sense of responsibility to the community. Leaders understand that they grow by helping others grow, and they mentor junior members of the organization.

Governance

Rewards

In order to drive adoption, extrinsic motivators can be used to increase cross team collaboration.

• RW-0: No rewards.

• RW-1: Leaders are encouraged to reward exceptional collaborations, but there are no policies or processes established.

• RW-2: Standard processes are established to reward collaborations outside the developers' teams. Team leaders or boards decide who has to be rewarded.

• RW-3: Rewards are not only proposed by the organization, but the communities are able to define their more valuable rewards. The community is responsible to decide who has to be rewarded.

Monitoring Policies

InnerSource projects need a means for self assessment. Metrics can be one aspect to facilitate this assessment. Also, in organizations with a mature InnerSource adoption level we expect adoption of the method to be tracked based on clear, agreed upon metrics.

• MP-0: No existing monitoring policies at any level in the organization.

• MP-1: Metrics are important for certain teams, and they start using them in an isolated way.

• MP-2: There is a strategy at the organizational level with respect to metrics that help to validate specific policies across the organization. This monitoring policy exists at the level of some InnerSource projects.

• MP-3: There are clear guidelines, recommendations, and trainings about the use of metrics with certain infrastructure provided by the organization. This works at both levels: InnerSource program to understand the general InnerSource adoption within the organization, and at the level of InnerSource projects.

Support and Maintenance

Not only should feature development be owned by InnerSource teams - support and maintenance is also part of the teams core tasks.

• SM-0: Support given by the core development or support team. A business contract guaranties the support. There is no knowledge about the product outside the team.

• SM-1: There are rules and regulations to formalize the support on the product, given by a dedicated supporting team.

• SM-3: There are rules and regulations to formalize the support on the product, given by a mature community.

Culture

There are multiple levels moving towards a collaborative culture.

• CL-0: Silos - teams work independently but also in isolation.

• CL-1: Reactive - teams work independently, but know how to react to flaws in dependencies.

• CL-2: Contributive - teams actively help improve their dependencies by contributing.

• CL-3: Activist - teams actively seek help, mentor and recruit new contributors.

InnerSource Roles

InnerSource comes with explicit roles. While in early stages some patterns may be useable without adopting those roles, communicating within projects using explicit role titles becomes easier.

• RO-0: There are no specific roles helping InnerSource adoption. Only common development roles are present: developer, analyst, tester, etc.

• RO-1: Occasionally some individuals and teams contribute to other projects. These are technical contributions, where the user/contributor role is seen. For some teams, it can be identified at least one member being a technical reference, who explains the development process to other development team members. He/she could be a candidate for covering the trusted committer role.

• RO-2: An InnerSource Officer role is in charge of governance and support, including processes, etc. Identifies the education needs and ensures it is provided to the organization. Leads and mentors the organization in the engagement in IS projects. Is the first formal step in the way, defining the IS vision and roadmap. The organization has defined a trusted committer role, being a point of contact/reference not only for development team members but also for external contributors. There is a standard process describing how to contribute to the community, contributor role is present. Data Scientist role is in charge of managing the traces of activity left by the InnerSource initiative, needed to measure the IS evolution. Trusted committer role will evolve to a more technical profile, and a community manager will be in charge of "energizing" the community, being his main responsibility to attract and retain new developers/users (contributors/community members).

• RO-3: Evangelists are moving inside organization, to let others know about the current work, what InnerSource does and how to do it, and help others to understand and become part of the initiative. Non technical contributors appear.

Resulting Context

All teams are aware of available best practices.

Teams understand their level of InnerSource adoption.

Prior to adopting InnerSource as a working model, teams are aware of the practices that are expected of them - both in the short term and in the long term.

Known Instances

• Entelgy

• Zylk

• Bitergia

• Airbus

Authors

• Daniel Izquierdo Cortazar

• Isabel Drost-Fromm

• Jorge

• Nerea

Acknowledgments

• Alexander Andrade (special thanks for the spelling fixes)

Alias

Maturity model: Learn about InnerSource best practices

Status

• Structured

• Drafted in September 2019

This glossary defines essential terms that are commonly used when writing new patterns. It focuses on key terms and resolves ambiguities where necessary.

Through this the glossary helps members of the Patterns Working Group to use consistent language when writing and reviewing patterns.

• legal entity - An entity that has its own legal rights and obligations (synonyms: company, subsidiary) (e.g. Lufthansa Systems GmbH, Lufthansa Industry Solutions TS GmbH, ...)

• organization - An umbrella for multiple legal entities. (synonyms: group, enterprise) (e.g. Lufthansa)

• project - Projects serve as a planning and tracking tool that can integrate with the issues and pull requests within one or more repositories. In GitHub documentation, projects are described as an adaptable spreadsheet, task-board, and road map that integrates with your issues and pull requests to help you plan and track your work effectively. A single project can include items (e.g. issues and pull requests) from multiple repositories.

• repository - A repository is a central location for source code, files, where each file's revision history is stored and managed. It enables version control and collaboration among multiple contributors. Repositories are designed to facilitate collaboration, discussion, and management of work through features like issues, pull requests, and project boards. A single repository can be associated with multiple projects.

Note that his glossary is far from complete. If you see terms that are used frequently in our patterns and should be defined in this glossary, please add them.

Mission

This should contain a brief (3-5 sentences) description of the mission of your project. The goal is to state what you are planning to work on and help external contributors understand roughly which types of features will likely be welcome for this project.

See also mission statement chapter in Producing Open Source Software.

Getting Started

This section should contain brief documentation written for first time users on how to get started using the project. Further more detailed documentation can be linked to from here.

Further information

This section can list any or all of the following:

• A list of features, use cases that the software addresses.

• Information on design principles that are used to resolve trade-offs

• Links to further user level documentation

• Answers to frequently asked questions (FAQ), preferably in a format that allows to link to specific questions and their answers for easier reference.

Getting help

This section should contain a brief documentation on how to get help for the project as a user. This could be as simple as pointing users to the issue tracker if this is how your project would like to answer questions. It could also point to an archived and searchable chat channel, some archived searchable mailing list, some online user forum.

Getting involved

This section should include information on how to get in touch with the project: Typically this will contain links to archived, searchable and linkable communication channels.

Who we are

This is a good place to give credit to Trusted Committers of the project.

It's also a good place to include information on what being a Trusted Committer means for this project - although ideally all projects in an organization use the same definition that is only linked to from here. The reason to keep the link here is for colleagues who have no or little experience with working in and contributing to InnerSource projects to have a direct link back to company wide information from the technological projects they need for their daily work.

Contributing

This section should document (or link to documentation) on all things that a first time contributor needs to know to get started. Typically not all of the topics below will be covered. Focus on what differs in your project from standard setup and what previous contributors found hard to understand.

• Finding the source code.

• Finding a list of issues that your project needs help with - these can be both, technical and non-technical issues. Typically you will keep those in an issue tracker accessible to contributors.

• Links to further documentation e.g. about the architecture of the project, general coding conventions, testing conventions...

• For technical contributions: Making changes, building the project and testing your changes.

• Submitting your changes back to the project.

Ideally you also include information on what the preferred process for changes looks like for the project: Should contributors first open an issue and submit a proposal, or are they welcome to submit changes right away? What is important to you when reviewing contributions?

In addition you should outline any design values you want to follow in the project. Making those explicit often helps resolve trade-offs more quickly and more easily. In addition it helps making changes to otherwise implicit assumptions transparent.

Over time you will notice that this section grows substantially. In that case think about moving the information to separate files, e.g. a CONTRIBUTING.md and TESTING.md.

Title

Short Title Here

Patlet

Concise 1-2 sentence description of the problem and solution. Readers may quickly review dozens of these patlets to discover and browse the larger library of patterns. From http://wiki.c2.com/?PatLet

Problem

What is the problem - crisp definition of the problem. Short description, usually not more than a couple sentences, that describes what the issues and challenges are. Be careful not to morph into information found in other sections below.

Story (optional)

Sometimes there is a story that helps people understand the pattern better.

Context

Where does the problem exist? What are the pre-conditions?Unchangeable before the solution goes into place. The content here is often tied to the applicability of the pattern for other readers: "Do I have this same particular situation?"

Forces

What makes the problem difficult? What are the trade-offs? These are constraints that can be changed at a cost. The solution might change one or more of these forces in order to solve the problem, while also in-turn changing the context.

Sketch (optional)

visual illustration

Solutions

Verified resolutions and possible resolutions to the problem.

Resulting Context

What is the situation after the problem has been solved? The original context is changed indirectly by way of the solution. Often this section can include discussion of the next possible Patterns/problems introduced. This section can be short in content - the solution may not introduce new problems or change much context.

Rationale (optional)

Explains why this is the right solution; using totally different words WHY this solution balances these forces and this context to solve this problem. Can expand on what-if's or theories.

Known Instances (optional)

Where has this been seen before? Helps to reinforce that this is a REAL pattern and that you match the context.

May mention:

• A particular business

• Anonymized instances ex: "3 companies have proven that this is a good solution" or "A large financial services org...".

Status (optional until merging)

General pattern status is stored in GitHub's Label tagging - see any pull request. Note that this GitHub label tagging becomes less visible once the pattern is finalized and merged, so having some information in this field is helpful.

You might store other related info here, such as review history: "Three of us reviewed this on 2/5/17 and it needs John's expertise before it can go further."

Author(s) (optional)

Often, this is yourself. If you need to, find someone in the InnerSource Commons to be the nominal author (As Told To). Could also be no-one if you do not want to take on authorship (common with a donut looking for a solution).

Acknowledgments (optional)

Include those who assisted in helping with this pattern - both for attribution and for possible future follow up. Though optional, most patterns should list who helped in their creation.

Alias (optional)

If this pattern is also known under a different name than what is listed unter Title, please list those alternative titles here. e.g. if the pattern is named after the problem it solves, a helpful alias might be one that describes the solution that is applied.

Types of contributions

Provide information on what kinds of contributions your project is looking for here. For example these can be bug reports, help with answering user questions, improving documentation, fixes to bugs, as well as new feature implementations.

Bug reports

Add information on how to submit bug reports here. This should include hints about which type of information the project will need in order to reproduce and fix issues. It can also include information on commonly found misconfigurations that look like bugs.

Also include information on what contributors can expect in terms of time to first response and process after that.

Feature requests

Add information on how to submit feature requests here. Also include information on what contributors can expect in terms of time to first response and process after that.

Contributing documentation

Include information on any documentation best practices your project follows as well as how to build documentation, checks to run and how to submit the changes made back to the project.

Contributing source code

This section should contain information on

• How to access the project source code,

• General project layout,

• Any requirements to the development environment,

• Code formatting guidelines,

• How to run the test suite.

How to become a Trusted Committer

This section should make the process for becoming a Trusted Committer explicit if that route is open to contributors.

How to nominate Trusted Committers

This section serves as a reminder to existing and explanation for new Trusted Committers detailing how to add others to the host team. Again ideally this information is identical for all projects in the organization so central information can be linked to from here.

Put an individual COMMUNICATION.md file tailored to the project in each repo. If project repo ownership is transferred to a different team in the future, they need to be able to access and edit documentation related to the project. This includes documentation that outlines the communication processes that users should use to contact the team.

Delete top paragraph when this section is filled out.

Team Communication

Team Slack channel:

Special Slack Channels: (topic specific and accessible to anyone who would be an external contributor)

Team Email:

How to Contact Us

The following types of actions can be moved to the appropriate section and more added.

Roles and Responsibilities

Managers or roles and specific situations they should be contacted for outside the team channel.

(this is set up this way so that the document can easily be changed if there are new members on the team)

Outbound Communication

Documentation Contacts

Tell how to find the owner, responsible party, or group people should contact if they have questions about documentation in the repo.

Describe this communication process.

For example:

• If you have questions on a specific piece of documentation, you can find the team member responsible for the information by looking here:

• You can contact the responsible party by sending a message in the xyz channel, send them a direct message in chat, email, etc. The individual who last certified the documentation is the responsible party.

Title

Standard Release Process

Patlet

Teams may hesitate to adopt an InnerSource project if they are unsure of its maturity. To address this, consistent release notes and published artifacts are crucial. These practices showcase a strong dedication to the project, instilling confidence and assuring users of ongoing commitment to sustainable and well-managed software.

Problem

When a team is deciding whether to use an InnerSource project, one of their considerations is whether they can rely on the given project for an extended period. Switching the tools/projects that they are using has a cost, so they only want to make those investments when necessary and has tangible benefits.

It is common practice for Open Source projects to have versioned releases, with notes documenting breaking changes, and new features along with either a published binary or link to a Docker image. This practice may not be as transparent or well documented/visible for InnerSource projects, modules, etc.

InnerSource projects that don't have a published artifact or release process reduces trust. Teams won't know when they can expect the next release, when breaking changes are introduced, etc.

Context

Large organizations produce a lot of internal software, much of which could be reused by teams across the company. Operational tooling, software libraries, and infrastructure as code (IaC) modules are common examples of this type of software. Most large organizations, however, don't publish internal software to be consumed by other teams in the company. This can occur either because they are to busy to provide documentation or don't realize the projects value to others.

An internal or public source repository should be available where source code is stored, but teams lack a process for making software consumable by outside teams.

As an organization grows and more internal software is written, the value of this pattern grows.

Forces

Difficult for organizations that don't have a central CI/CD system

For organizations that don't provide engineers a centralized CI/CD system, automating a build and release process can be challenging. The team may need to stand up their own tool (Jenkins, Drone, etc). Without a CI/CD system, builds and release notes can still be produced, however, it may require a local build of the software and manual upload to whichever tool is hosting build artifacts.

Added burden of publishing release notes

In addition to building your source code, writing release notes can be tedious without the ability to auto-generate a list of git commits. This would be left for someone to do manually, in addition to writing more high level details on a release.

Increased difficulty without a location to host artifacts

If a company does not provide a centralized location for storing build artifacts (jars, npm modules, etc.) and docker images, engineers may be left deciding for themselves where is appropriate to store versioned software. Tools like GitHub provide this for you, however, if a company is not using one of these popular tools, this could pose a burden.

Solution

By providing clear release notes and a published artifact you increase people's confidence that you are publishing a quality product that they can rely on.

The following are key elements to achieve this:

• A CI/CD pipeline is located within your repository that automates the release process

• Build artifacts are generated by the CI/CD system (binary, docker image, jar, etc)

• Releases are clearly labeled and tagged with semantic versioning

• Releases include notes on New Features, Bug Fixes, and any "Breaking Changes"

A good example of quality release notes can be found here.

Resulting Context

Teams who come across your project will see published release notes and gain confidence in your tool. Published artifacts also make using your product easier and quicker to adopt. Having well-defined and visible processes such as these also help with cross-team collaboration and new contributors. Folks can be confident that their contributions are made available and distributed in a reasonable amount of time with a clear usage path.

Release notes are also a great opportunity to praise participants! As we know, documentation is extremely important for new folks looking to get involved with your project. Praising outside teammates for contributions, including documentation and release notes, is a great way to foster community and grow your user base.

Known Instances

• Comcast (multiple projects)

• GitHub (multiple projects)

Authors

David Grizzanti

Status

Structured

• Feature Name: (fill me in with a unique identifier, my_awesome_feature)

• Start Date: (fill me in with today's date, YYYY-MM-DD)

• Nominated owners: (Representatives of technical ownership areas affected by the RFC. This will often be tech leads, but they may delegate. RFCs cannot be accepted until all nominated owners have signed off.)

Summary

One paragraph explanation of the feature.

Retrospective

This section is essential to allow us to learn from the things we are implementing.

When is the retrospective?

[ ] Retro completed?

(where/how it will be held, how can people get involved, where are the results?)

Motivation

Why are we doing this? What use cases does it support? What is the expected outcome?

Guide-level explanation

Explain the proposal as if it was already existing and you were teaching it to another engineer. That generally means:

• Introducing new named concepts.

• Explaining the feature largely in terms of examples.

• Explaining how engineers should think about the feature. It should explain the impact as concretely as possible.

• If applicable (e.g. code/architecture proposal), provide sample error messages, deprecation warnings, or migration guidance.

• If applicable, describe the differences between teaching this to existing engineers and new engineers.

For implementation-oriented RFCs, this section should focus on how contributors should think about the change, and give examples of its concrete impact. For policy/process RFCs, this section should provide an example-driven introduction to the policy/process, and explain its impact in concrete terms.

Reference-level explanation

This is the technical portion of the RFC. Explain the design in sufficient detail that:

• Its interaction with other features is clear.

• It is reasonably clear how the feature would be implemented.

• Corner cases are dissected by example.

The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work.

Drawbacks

Why should we not do this?

Rationale and alternatives

• Why is this design the best in the space of possible designs?

• What other designs have been considered and what is the rationale for not choosing them?

• What is the impact of not doing this?

Prior art

Discuss prior art, both the good and the bad, in relation to this proposal. A few examples of what this can include are:

• For language, library, tools etc: Does this feature exist in other places and what experience have their community had?

• For community proposals: Is this done by some other community and what were their experiences with it?

• For other teams: What lessons can we learn from what other communities have done here?

• Papers: Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background.

This section is intended to encourage you as an author to think about the lessons from other places, provide readers of your RFC with a fuller picture. If there is no prior art, that is fine - your ideas are interesting to us whether they are brand new or if it is an adaptation from other places.

Unresolved questions

• What parts of the design do you expect to resolve through the RFC process before this gets merged?

• What parts of the design do you expect to resolve through the implementation of this feature before stabilization?

• What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC?

Future possibilities

Think about what the natural extension and evolution of your proposal would be and how it would affect the teams and projects as a whole in a holistic way. Try to use this section as a tool to more fully consider all possible interactions with the project and teams in your proposal. Also consider how the this all fits into the roadmap for the project and of the relevant sub-team. This is also a good place to "dump ideas", if they are out of scope for the RFC you are writing but otherwise related. If you have tried and cannot think of any future possibilities, you may simply state that you cannot think of anything. Note that having something written down in the future-possibilities section is not a reason to accept the current or a future RFC; such notes should be in the section on motivation or rationale in this or subsequent RFCs. The section merely provides additional information.

Title

Start as an Experiment

Patlet

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

Problem

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.

Context

The company is considering 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.

Forces

• 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 radical 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.

Solution

Declare the InnerSource initiative as a time limited experiment. Define and communicate the criteria for projects to join the InnerSource experiment. Choose criteria that will maximize the chances of building a healthy community. A set of criteria is a good one if the insights generated from it within the context of the experiment can intuitively be applied to contexts involving other potential InnerSource projects.

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 Project Valuation to highlight their value contributions.

Resulting Context

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

• The experimental setup eases the need for 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 that they have to prove to management that InnerSource yields the promised benefits. It will therefore help to focus work on those activities 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.

Related Patterns

• Trial Run (from the book Fearless Change)

Known Instances

• Robert Bosch GmbH (globally distributed software development)

• Airbus: the data science community collaborated on shared Python libraries that eventually lead to a group-wide InnerSource scheme for any software.

• Siemens started their InnerSource Platform code.siemens.com from a single department with a few hundred users. Over the years they scaled it to a company-wide service with 50,000 active users.

Status

• Structured

Author

• Georg Grütter (Robert Bosch GmbH)

Acknowledgments

• 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)

Title

Trusted Committer

Patlet

Many InnerSource projects will find themselves in a situation where they consistently receive feedback, features, and bug-fixes from contributors. In these situations, project maintainers seek ways to recognize and reward the work of the contributor above and beyond single contributions.

Problem

• Project maintainers want to find ways to scale their ability to support a project

• Project maintainers want to find ways to lengthen the value delivered by a project

• Project maintainers want to visibly reward frequent contributors and empower them to amplify their value contribution.

• Lack of mechanism and language for recognizing contributions across teams within an organization

Context

• You are the maintainer of a cross-team library, service, or shared resource

• You receive regular contributions

• You receive regular feature requests

• You receive regular bug-fix requests

• There are motivated contributors looking to build expertise through InnerSource projects

Forces

• Over the lifecycle of a project, the focus of the maintainers may shift away to accommodate changing business priorities

• Contributors seek visible recognition of their contributions, demonstrating value

• Maintaining a project of reasonable complexity is taxing for a small team

• Developing project features at scale is taxing for a small team

Solution

Defining the Trusted Committer Role for a Project

What a Trusted Committer handles is up to each project and its maintainers. Ensure you document within the project the scope of your Trusted Committer role. Clear documentation sets expectations for new community members and establishes the role for future candidates.

The following are a few guidelines for identifying a potential Trusted Committer:

• An active participant in community channels (Slack, JIRA issue triaging, etc.) becomes a Trusted Committer, thereby formalizing their role in community support.

• Someone who frequently submits code, documentation, or other repository changes. Start by including this person on pull requests. If they are actively engaging in pull requests, consider approaching them about opportunities for further collaboration on the project.

Formalizing Trusted Committers

The first step is to approach candidates about becoming a Trusted Committer. Maintainers should educate candidates on the role of a Trusted Committer. There is no expectation that candidates will accept the role of Trusted Committer. Each candidate should assess if they have the available bandwidth to take on the responsibilities.

When a candidate accepts the role, it is up to the project maintainers to publicly recognize the transition from user to Trusted Committer. It is also a good idea to add their name to a Trusted Committers section in your project's README. As an example:

# project-name

... your project's readme ...

## Project Leaders

### Maintainers

  - Your team

### [Trusted Committers]

  - The name of the new trusted committer

[Trusted Committers]: https://example.com/link/to/your/trusted/committer/documentation.md