Introduction

Check out the Introduction to learn about the types of problems where InnerSource can help, how to do it, the types of benefits you can expect to see by participating, and the underlying principles that make it all work.

Introduction

This Learning Path gives an introduction to InnerSource. InnerSource is the application of open source practices and principles to software development within the enterprise. InnerSource software remains proprietary to the company, but within it is open for anyone to use it and contribute to it. This strategy enables wide and effective collaboration, producing software that is responsive and nimble to the changing needs of its many internal stakeholders.

This Learning Path teaches how to recognize situations that are good candidates for InnerSource. We’ll outline at a high level how InnerSource can help in those situations. You’ll become familiar with shared terms used when discussing InnerSource. We’ll also enumerate the key principles upon-which InnerSource is based and the benefits seen when it is applied effectively.

What Problems Does InnerSource Solve?

InnerSource encourages and rewards collaboration and code reuse with anyone, regardless of their position in a company’s organizational structure. This approach differs from what is seen in traditional organizations where ideas and work product tend to stay trapped within the boundaries of the internal corporate hierarchy and its silos. Let’s explore one situation that gives an example of this idea.

Imagine two teams at the same company deliver separate pieces of software with one team’s software depending on that of the other. An example could be a user experience that depends on an API service to retrieve data for display. This situation is common in a large enterprise where a single team producing software may have dozens or hundreds of consumers.

When consuming teams need many features, producing teams normally have some sort of requirements and prioritization process to decide which features they will work on. For critical feature requests that are not prioritized for immediate work, the consuming team may commonly choose one of 3 options, each of which comes with their own drawbacks.

1. Wait it out. The consuming team may do nothing and limp along without the requested functionality. This option requires the least amount of work on their side. Depending on the benefit of the feature request, waiting might be just fine. However, it may come with real amounts of pain, especially if the requested functionality is never delivered.
2. Workaround. A consuming team that doesn’t want to wait may do extra work somewhere else to compensate for the absence of their requested feature. This extra work may come as change in the consuming project. Alternatively, they may create a new project that meets their needs and replaces their use of all or part of the producing team’s system (code/project duplication). This strategy allows the consuming team to get the requested feature via their own efforts only. It comes with several drawbacks, though.
   1. Any work done by the consuming team remains unavailable to any other consumers with the same feature request.
   2. The consuming team has inadvertently signed up for the long-term burden of maintaining the newly-written code, which is not in the domain of their core team competency.
   3. The company as-a-whole acquires duplicate projects and code in the same problem space.
3. Escalate. The consuming team may not take “no” for an answer and, instead, advocate to someone in the producers’ management hierarchy to influence (or force) the producing team to do the work. This option sounds attractive for the consuming team because they get the requested feature without doing the work to implement or maintain it. It is still a drag on the team, though, because it necessarily diverts some of their attention and work to the non-engineering task of escalation. Additionally, this option does not scale as there are only so many times that a consumer can escalate feature requests before damaging their credibility. Escalation is similarly disruptive (even more so) for the members of the producing team, who are taken out of their normal workflow and prioritization methods to deal with the escalated feature request.

This discussion sets the stage for InnerSource. InnerSource applies to the same type of situation where a consuming team is unable to get what it needs via feature request. InnerSource provides a way for the teams to gain the benefits of wait it out, workaround, and escalate without the associated drawbacks.

InnerSource also provides a general improvement to engineering culture as engineers have the chance to work with a wider variety of new technologies and people. Developers mentor and learn from one another as they share ideas and solutions across organizational silos. Engineers and teams can reuse internal solutions to commodity problems, allowing them to focus on higher value streams of work for the organization.

How Does InnerSource Work?

Let’s say that team A uses software produced by team B. Team A submits a feature request to team B, but team B isn’t able to implement that feature in time for team A. In an InnerSource setting, if team A can’t get this feature request then it submits a pull request instead. That is to say team A implements the feature directly in team B’s software and submits a pull request with the code changes. Team B partners to review and accept the submitted code.

In this example, we call team A the Guest team and team B the Host team. The terms Guest and Host suggest a situation analogous to receiving a visitor in the home. In that situation, most people want to be a good host. They ensure that things are kept neat and tidy in anticipation of their guests’ arrival. Visitors are greeted at the door and invited in. They can use the features and utilities that are in the home’s public areas. There may be a few house rules that guests are asked to follow. Similarly, most guests want to show respect for the home and their host. They’re careful with the items in the house and follow the rules for the duration of their stay. They may hope for or expect a return invitation as long as they’ve been courteous and polite. These concepts around a home visit are a metaphor for the attitude and behaviors that teams should bring as one hosts another making a guest contribution to the codebase.

Let’s take a closer look at how the mechanics of the InnerSource process can work. To aid in this explanation, we’ll name a few key individuals on the guest and host teams. First, the Product Owner determines what functionality the host team is willing to accept as a contribution. The Contributor is the individual on the guest team that submits the code contribution for review by the host team. The Trusted Committer represents the host team in providing any timely support and mentorship that the contributor needs to successfully submit the pull request. On small, grass roots efforts a single person often fills both the product owner and trusted committer roles.

With those definitions, here is the basic outline of an InnerSource contribution.

• Guest team or contributor requests a feature from the host team.
• Product owner ensures that user stories representing the feature request are created, either by members of the guest team or host team. These stories should describe the requested feature in terms agreeable to the guest team. They also list any details from the host team on how the feature should be delivered in order for the work to be accepted. Examples of such details include architecture constraints, coding conventions, dependency usages, data contracts, etc.
• Supported by the trusted committer, the contributor submits the pull request to implement the requested feature.

Note that these steps do not assume a specific system for the general organization of a team’s time or priorities. InnerSource assumes that teams already have existing methods of organization and provides a framework of how to use them to work together where there is a guest team desiring to contribute code to a host.

This option works well for the guest team because they get the functionality they need when they need it without taking on the long-term burden of maintenance of the solution. It works for the host team because they are able to better scale and serve their consumers. It works for the company at-large because solutions to shared problems end up in shared, centrally-maintained locations where anyone can use them. More engineering time stays focused on producing code that solves company problems rather than the mechanics of the feature negotiation and escalation process.

• The host team can be represented by the Core Team pattern.
• The Trusted Committer pattern.

What Are The Benefits of InnerSource?

There are many benefits to collaborating via InnerSource. InnerSource gives a company a scalable strategy for guest teams to get feature requests when they need them without the long-term burden of maintenance. The company as a whole wins as the time of guest teams is put into code that others can use.

While that result is a shining benefit of InnerSource, there are many benefits to hosts that receive regular InnerSource contributions. Recall that, as part of the InnerSource process, the product owner on the host team agrees from the outset that contributed features are good and desirable. InnerSource allows the host team to receive help in creating a better product for its consumers!

InnerSource provides the host team a scalable strategy for fulfilling varying amounts of features requested from its many consumers. Given the fixed capacity of the full-time members of the host team, it’s likely that, at times, the combined business roadmaps of its consumers will require very (or even unreasonably) large amounts of work to be done in the host team’s products. Without InnerSource, this situation easily leads to a stressed, overworked team dealing with many feature requests escalated to its leaders.

However, if the host team operates via InnerSource, the engineering resources required to build those features will appear in proportion to their importance in the form of guest contributors. InnerSource becomes a force multiplier that allows the host team to temporarily act larger than its actual size during times of high demand. When the demand has ended, the team throughput scales back to normal levels, all without any micromanagement of team headcount or work items. InnerSource allows engineering time to organically flow where the organization needs it at a given time.

Beyond the raw work that the host team is able to accomplish in its system, regular InnerSource contributions give the host team better requirements and prioritization alignment with all of its consumers. A host team can do its best requirements gathering on the work it produces, but when the consumer itself is the one submitting the work the chances are much higher that the resulting change is aligned to just what the consumer needs. While it may be only one single guest team submitting the change, that team is likely representative of many other consumers.

In addition to this alignment, there is also a general training and education of contributors as they work with and learn from trusted committers. This interaction helps contributors to learn and grow in their career, resulting in higher job satisfaction. Project documentation improves to enable these contributions at scale. Contributors feel a stake in the host team project. It’s something that they recommend to their colleagues or new teams that they join. They understand the project better and are able to answer questions about it to others, relieving the host team of some of that burden. More people contributing to a project naturally cross-pollinate ideas from all over the company. This learning and cross-team alignment over time serves to break down traditional company silos.

InnerSource Principles

Every company, team, project, and individual is different. Because of that fact, the exact way that the concept of InnerSource works will vary from one situation to another. At its core, however, are four principles that form the bedrock of any successful instance of InnerSource. These principles have inspiration in successful open source projects and are required in order for InnerSource to achieve the benefits described earlier.

The principles are:

• Openness
• Transparency
• Prioritized Mentorship
• Voluntary Code Contribution

Let’s take a look at each of these principles in more detail.

The configuration of an open project enables frictionless contributing. Projects should be discoverable and well-documented through README.md and CONTRIBUTING.md files within the root of the repo. Anyone within an organization should be able to find a desired project and ramp up without an inordinate amount of direct guidance from host team members. Host team contact information should be prevalent with as many channels as makes sense for the project. Host team intentions to accept InnerSource contributions to their project should be shared through relevant organization channels to raise awareness. Particularly in smaller settings you may want to establish a regular “broadcast” on the InnerSource work your team is doing. In larger settings, however, such broadcast may create a lot of noise, and it may be more appropriate to make sure the project is discoverable in a easy-to-use tool. Remember, the goal is awareness use the appropriate channels that work in YOUR company.

By no means is the above an exhaustive list. Project openness will typically be directly related to how successful a project is in terms of InnerSource. The more open it is, the fewer barriers are put in place for prospective contributors. The less open it is, the more difficult it becomes for anyone to contribute.

In order for guest teams to be able to contribute meaningfully to a project, the host team must be transparent. This means that guest teams should be able to have an understanding of:

• The project/repo and its direction
• Outstanding feature requirements
• Progress on feature requirements
• Decision making of the host team

When possible, the above should be communicated clearly and in detail, from teams’ internal definitions of items to special-case scenarios specific to the project. This communication should be done in a manner that can be easily queried and understood to those that are not part of the host team.

Mentorship from host team to guest team via trusted committers is a key aspect of InnerSource. Contributors on guest teams are upleveled so that they understand enough about the host team’s project/repo to change it successfully. In the process of doing so, they come to better understand the host team’s software system as a general consumer and ambassador for the project/software. This individual contributor can, over time and with experience, take on a broader role in the project as a trusted committer.

It’s critical that this mentorship for contributors is Prioritized by the host team. The host team should strive to make time to mentor guest team contributors at the time that the contributor needs it as opposed to when it’s convenient to the host team. At times it may be a culture change for engineers on the host team to spend time helping others to code rather than just coding themselves. This mentorship is valuable to both the individual contributor and the host, and it is worth doing well. It proves to be mutually beneficial in the long run. By improving the code, the contributor forges or improves relationships within an organization that may not have existed otherwise. Open source readily recognizes this point and considers it as an honor to achieve trusted committer status on a project.

The first word Voluntary means that engagement in InnerSource from both the guest and host teams occurs of their own free will. The guest team voluntarily donates code to the host team and the host team voluntarily accepts it. This opt-in nature means that each team needs to be certain that their involvement adds value to the others’ objectives. Never is a host team required to accept a contribution that isn’t in ultimate alignment with their overall mission. Never is a guest team required to submit a contribution that doesn’t ultimately further their own mission and priorities.

The word Code emphasizes that the collaboration between guest and host goes all the way to the code. Guest involvement in opening issues, updating requirements, fixing docs, etc. is good, but collaboration needs to reach as far as submitting code to achieve all of the benefits that we’ve discussed.

Conclusion

In this learning path, we’ve given an introduction to InnerSource. InnerSource applies open source best practices and principles to internal software development. It gives an additional option to consumers when producing teams are not able to deliver a needed feature request. Successful InnerSource involves a product owner and trusted committer from the host team as well as a contributor from the guest team. Done effectively, InnerSource brings many benefits to both participating teams. They key principles upon-which effective InnerSource works are voluntary code contribution and prioritized mentorship.

While this training contains a high-level overview of InnerSource, there are many more details useful in making InnerSource actually work for your team. If you want to stay connected to the ongoing conversation around InnerSource and its best practices, then join the InnerSource Commons. The commons sponsors a Slack channel, an InnerSource patterns working group, and multiple in-person summits each year. Participation in the commons is a great way to stay connected with the latest in InnerSource.

Is InnerSource Right for My Project?

InnerSource is the application of open source principles to company-internal software development. Done right, it unblocks progress and eases adoption of shared services and modules. This article contains guidance and questions to ask yourself when considering adoption of an InnerSource approach to running your project.

An InnerSource approach only makes sense if contributions are expected from the project’s users. You can expect contributions to come if you see or anticipate noticeable amounts of energy directed at your project area by its users. Some examples:

• High amounts of project usage and adoption.
• More feature requests than your team has time to fill.
• Users doing workarounds to compensate for lack of features in your project.
• Feature requests that take nearly as much time to explain as they would just to implement.
• Multiple roadmap dependencies on your project.

Even with willing contributors, the code doesn’t just flow in. You will need to encourage and support contributions via activities such as:

• Understanding users’ scenarios and suggesting what contributions in your project could help them to meet those scenarios.
• Inviting users to make the contributions that they need and following up with them to ensure that they do them.
• Maintaining an CONTRIBUTING.md document that contains everything an engineer needs to know to contribute to the project.
• Giving up-front guidance and direction as to how to implement a given contribution.
• Being available during regular hours for any ad hoc questions that contributors have.
• Timely review of incoming pull requests.
• Ongoing maintenance of submitted code (after the warranty window).

InnerSource projects make sense when the project is specific to the company or when its exclusive usage gives the company a strategic business advantage. Other collaborative projects should be run as open source to increase the contribution pool and impact.

If contributions will come and you will support those contributions and your project is company-specific, then InnerSource is right for your project.

The InnerSource Mentality

InnerSource helps when there are multiple teams at our company that have a shared need – business or technical. We want one shared project that all can leverage. This sharing allows each team to spend as much time as possible in their unique business area instead of reinventing what someone has done before.

We manage shared projects via InnerSource, meaning that we apply open source practices and principles to the way that they are run. These projects are open for reuse and contribution across the company. In theory, any project can be an InnerSource project, but you can find popular InnerSource projects listed in the company InnerSource portal.

InnerSource needs to be a part of the way we work. When delivering on your software roadmap, when you come across a need that is likely shared with other teams, stop and think. Has anyone else at the company already build something that (almost) solves this need? If so, on-board to that project, even if that means contributing to it first to extend it to meet your use case. If there is not an existing project, then build it in a sharable way with yourself as its first consumer, and then list it in the InnerSource portal.

Working in this way helps us to get the most as a company out of the engineering time that we all put in and enables us to spend more time on our unique mission as a company. Adopt The InnerSource Mentality.

Workbook

TIP: More than one answer may be correct in some questions.

1. Your team lacks the resources to create its core software
2. You are badgering a high-level manager to get another team to implement a software change
3. Most of your software is bought rather than built
4. Not enough software changes are being submitted to your team

Why 1 is incorrect: InnerSource allows other teams to upgrade your software to meet their needs. You can’t depend on other teams to take on your own priorities, nor can you assign a project to another team. InnerSource relies on voluntary contributions, and works where the interests of the guest and the host team align.

Why 2 is correct: Large organizations that assign different teams to different parts of a code base routinely suffer battles over priorities. What’s critical to your team’s business plan may be seen as an extraneous annoyance to the host team that owns the code. With InnerSource, you add the code you need directly to the other team’s project, although you are responsible for following their guidelines and the host team vets it before it goes in.

Why 3 is incorrect: If a third party delivers a proprietary solution, you can’t participate in its development. However, free and open source software from third parties offers excellent opportunities for collaboration. The skills you learn doing InnerSource can be applied to open source projects outside your company, and vice versa.

Why 4 is incorrect: InnerSource exploits the desires of other teams to enhance your software. If your software is mature and doesn’t need many changes, there is no reason for you or other teams to enhance it. Your skills can be directed to new projects.

1. It prevents multiple teams from having to implement different solutions to shared problems
2. It brings in high-level managers to help teams decide on priorities
3. It requires fewer developers to create the same amount of code
4. It restricts maintenance to people who know the code base well

Why 1 is correct: When each team is responsible for a single code base, different teams tend to add code to their particular code bases to implement the same feature. This is not only wasteful, but can lead to incompatibilities. With InnerSource, the teams collaborate on adding code to a single code base to implement the feature.

Why 2 is incorrect: InnerSource allows team members to set their own priorities. It is a voluntary system that features grassroots participation. In fact, at its best, it reduces the involvement of high-level managers, allowing them to put their efforts toward other strategic needs of the organization.

Why 3 is incorrect: InnerSource is not magic. The same amount of work is needed to write a thousand lines of code as before. People engage in InnerSource to make sure they get the code their projects need, and invest the necessary time to write it.

Why 4 is incorrect: The whole idea of InnerSource is to spread around maintenance as well as new features. Anyone in the company who sees a problem is empowered to fix it. Teams use InnerSource because they see widespread participation as a strength.

TIP: More than one answer may be correct in some questions.

1. End user
2. Contributor
3. Trusted committer
4. Product owner

Why 1 is incorrect: InnerSource is a technical activity in which developers (both contributors and trusted committers) participate, supported by product owners. Although meeting the needs of end users is the ultimate goal, end users do not determine who does the work or how it is done, and therefore are not part of the communications and activities that constitute InnerSource.

Why 2, 3, and 4 are correct: The three keys roles in InnerSource are the contributor who creates the basic contributions (code, documentation, and guidelines), the trusted committer who mentors contributors, and the product owner who represents the needs of the organization.

1. Rigorous training to ensure that all engineers know the company’s entire codebase
2. Getting product owners to vet each change
3. Code reviews by trusted committers
4. Reviews by experts outside the company

Why 1 is incorrect: It’s unreasonable to think that every engineer can understand all the company’s code. Each engineer needs to understand only the code that has an immediate impact on his or her work. However, InnerSource allows engineers to explore the code from other teams to the depth they want, and to contribute to other team’s code while having a limited understanding of it. The engineer may simply read one function and provide a bug fix, for example.

Why 2 is incorrect: Trusted committers vet each change. InnerSource places responsibility closer to developers, lower in the organizational hierarchy, and frees product owners to concentrate on strategy and requirements.

Why 3 is correct: Are trusted committers are chosen by their community for their demonstrated ability to write excellent code, their communication and mentoring skills, and their knowledge of the code and the team’s goals. They review all contributions before allowing them into the code base.

Why 4 is incorrect: InnerSource, unlike open source, keeps code within the company. Of course, teams are free to bring in outside experts (such as for security reviews), but this is not part of InnerSource.

1. Ensuring that the code matches their team’s style guidelines
2. Writing the code as requested by the contributor
3. Mentoring the contributor
4. Merging the contributor’s code into their team’s code base

Why 1 is correct: Every development team has to maintain standards for coding style, structure, quality, security, and general adherence to the project’s goals. Although these are written and shared with contributors, the trusted committer is the key transmission point where the team conveys its guidelines to outsiders.

Why 2 is incorrect: The goal of InnerSource is to empower outsiders to contribute to a team’s code, offering the mentoring in quality control as well as standards and guidelines. It would undermine the whole premise of InnerSource if a member of the team did the writing requested by the outsider; that would simply be a traditional response to a feature request. Furthermore, if the trusted committer wrote the code, InnerSource would simply impose new communication burdens without removing any programming burdens.

Why 3 is correct: A contributor’s code is an excellent starting point for training the contributor. Mentoring can produce educational and personal growth that is even more beneficial than the code contribution itself. And contributors, even if competent and knowledgeable about the code base and team’s goals, can benefit from guidance to bring their contributions in line with a team’s goals and standards.

Why 4 is correct: The trusted committer, along with educational and mentoring responsibilities, plays the typical role of a committer on a project, ensuring that the code works well and does not break something else in the application.

TIP: More than one answer may be correct in some questions.

1. It improves the code with contributions from its users
2. It frees them from having to understand their user’s needs
3. They receive fewer interruptions during periods of high-volume activity
4. It highlights their importance to the larger organization

Why 1 is correct: The host teams open their code base to others and put effort into vetting contributions precisely because their code end up better and with more features than if they did all the coding themselves.

Why 2 is incorrect: InnerSource has no impact on the definition of requirements and priorities. As with any professional software development, developers have to understand their users.

Why 3 is incorrect: Contributors from many teams submit changes to the code, one hopes, during periods of high-volume activity. This means that the host team has to juggle many interactions with outsiders. The result, however, is more code in a short period of time.

Why 4 is incorrect: Outsiders make contributions come to projects that they recognize as important, The importance precedes the voluntary donations of code. Because InnerSource solicits voluntary contributions, outsiders work only on projects that they see as important. However, a team can ask outsiders to contribute, by persuading them that the project is important.

1. Managers allocate more money to the team
2. People outside the company can view and comment on code
3. Contributors can supplement the work of the host team on the team’s own code base
4. It leads to a permanent enlargement of the team

Why 1 is incorrect: InnerSource has no effect on funding for a team. It’s true that managers of other teams can allocate money so that their own team members can work on high-priority code in other teams. They pay their own team members to work on code, not the members of other teams.

Why 2 is incorrect: InnerSource is not open source. The code is not published outside the company. However, some companies choose to open their code at some point, turning an InnerSource project into an open source one.

Why 3 is correct: InnerSource invites company staff outside the host team to work on the host team’s code. The host team benefits from the outsiders’ understanding of their users’ or consumers’ needs, as well as from the new features added.

Why 4 is incorrect: InnerSource can be a valuable force multiplier during time crunches, bringing people from many teams together to complete high-priority code quickly. But after the crunch, people go back to working on projects within their own teams.

1. Establish clear barriers between team’s responsibilities
2. Replace traditional training with mentoring
3. Bring the insights of one team into another
4. Establish all requirements before any coding begins

Why 1 is incorrect: InnerSource blurs the responsibilities taken on by each team. Its goal is to enable people from one team to collaborate with another. The outsiders learn not only the host team’s code, but its style and standards. In InnerSource, the host team encourages outsiders to take on increased responsibility for its code.

Why 2 is incorrect: Traditional training is still important for basic skills such as learning programming languages, development tools, and good software engineering techniques. However, mentoring can enhance this training, and is an important part of InnerSource.

Why 3 is correct: On a large project, one team often produces services consumed by other teams. The team coding the service often doesn’t understand the ultimate purpose and requirements as well as the teams that build upon the service. InnerSource improves communication between teams, and lets the team with the greatest knowledge of the user put its code directly into another team’s code base after vetting by the host team.

Why 4 is incorrect: Requirements are not closely related to the decision to use InnerSource. For instance, InnerSource allows developers inside and outside a team to negotiate features as they go along. It is compatible with either a rigid requirement setting (a waterfall model) or a loose requirement setting (an agile model). But because InnerSource tends to devolve power and decision-making to outer leaves of the organization, including individual developers, it encourages people to set their own requirements within the context of the project, and to change them to meet new aspects of the environment.

TIP: More than one answer may be correct in some questions.

1. Serve as role models
2. Stop their own coding to take on the role
3. Increase their scrutiny of contributed code
4. Review code written by their own team

Why 1 is correct: Trusted committers are chosen because of their superior performance at coding tasks and their commitment to building a community. Therefore, their behavior serves as a model to others in the pursuit of better code and a stronger community. Many contributors aim to become trusted committers.

Why 2 is incorrect: Trusted committers continue to participate fully in all the activities of their team. The trusted committer role intensifies their contributions, rather than replacing them. They also need to keep coding (although probably not as much as before) in order to understand their team’s code well enough to help outside contributors and judge their work. Finally, the trusted committer role is temporary for some developers, and they plan to go back to full-time coding.

Why 3 is correct: When a single team develops its own code, team members tend to share a tacit understanding of the code and its goals. They may need no vetting, or may provide minimal vetting. InnerSource brings in outside coders who need more careful checks of their code, because they will come to the project with their own views and experiences.

Why 4 is correct: All contributions can benefit from a second pair of eyes. So trusted committers review code both from outsiders and from their own team.

1. Responding to code submissions with constructive feedback and advice.
2. Writing excellent code themselves.
3. Conducting in-person trainings and presentations.
4. Pair programming.

Why 1 is correct: Education is often most effective and long-lasting when learners focus on specific projects and derive general lessons from their own efforts. Few learning experiences are more powerful than asking someone to write code and then explaining how it can be improved. This is a key role for the trusted committer.

Why 2 is incorrect: Writing great code is a wonderful preparation and prerequisite to being a trusted committer, but mentorship is more than example. Mentorship must actively try to teach others and improve their ability to code in the project.

Why 3 is incorrect: Each trusted committer role is coupled to a specific project and is designed to help individual code contributions to have the support that they need for their contributions to be accepted into the code base. Most trainings and presentations are designed with a large audience in mind and so have a more generalized topic. Trusted committer mentorship mostly happens at a one-on-one level.

Why 4 is incorrect: While pair programming can be done remotely, there’s no guarantee that contributors can coordinate specific times with trusted committers. Trusted committer mentorship happens mostly asynchronously and digitally.