Learning Path – Project Leader

This section covers how InnerSource fits with other aspects of project leadership including agile, open source, capacity planning, and more.

InnerSource for Project Leaders

After completing this segment, you will have a better understanding of how InnerSource speeds up product development. We will also cover how it relates to Agile development best practices.

To achieve agility, organizations strive for autonomous teams. However, in a complex, interconnected world, some dependencies cannot be avoided. InnerSource provides an alternative to “wait it out”, “build workarounds” and “escalate”: Teams that need modifications in their dependencies can offer a helping hand. InnerSource facilitates cross team collaboration. Through its focus on written communication, it is well suited even for remote-first mode.

In this section, you will learn where Agile development and InnerSource use similar terminology and even technology – but differ substantially in the details. Instead of running into common misunderstandings, you will benefit from knowing the differences in culture but also in purpose of tools used.

You will understand the impact of InnerSource on capacity planning. Also with InnerSource there is no free lunch – host teams need time for mentoring contributors. We will also look at the additional negotiation possibilities that InnerSource brings – keeping the balance of Give and Take.

But let us start with a brief example. Imagine you are building a lovely new music app. In order to understand how your users are interacting with the app you start collecting some interaction logs. Over time, you dig deeper when analyzing those, feeding your learnings back into development. Now, imagine another team bringing content into your application also has a few needs – they may want to reward content creators based on how many users they reached. So them, too they start using your collected logs. But they need some additional analysis steps that you hadn’t thought of at first. They are now faced with a challenge: Build a workaround, or go through your backlog to get their request prioritized. With InnerSource they will have a third option: Make the changes themselves – with your help. Sure, that may be slower than if you had made the changes. But it will still be faster than waiting for you to get around to making the modifications.

In an ideal InnerSource organization you can scale that up even further: Remember the last time you had to make cross cutting concern modifications across your entire platform? When going the “put it into the backlog of each team” this often feels like it’s dragging on forever. On the other hand, it speeds things up substantially to provide those teams with a patch that implements the modification. The complexity of modifications in that approach depends on the maturity of the organization and the maintainability/modularity of the code produced.

InnerSource and Agile

You want to improve your product and deliver faster to customers. You want to make stakeholders happy. InnerSource helps your team deliver value and maintain autonomy in a highly interconnected world.

Organizations try to deliver value to customers quickly. One common cause for delays are dependencies in the delivery process. As a result organizations prefer cross functional teams covering customer communication, design, implementation, testing and operations thus eliminating costly handovers. To achieve high performance, teams eliminate waste and re-use existing components. From a team perspective each reused component adds another dependency outside of the control of that team. The negative side of this optimization is clear: The team depends on another team if they need changes in the component used. To be able to implement those often lengthy roadmap discussions are scheduled, sometimes leading to the need to optimize detailed priorities globally. In complex situations as much as in large organizations this leads to an increase in time needed to adjust to changing business needs. For very popular central components often there are so many requests coming in that one central component team runs out of capacity to implement all of the requested changes.

In traditional organizations there are only two ways of making changes to dependencies:

• Submit a feature request/ bug report and wait for the other team to prioritize that change and implement it.
• Build a workaround to avoid the bug or locally provide the functionality needed.

If none of those options is successful typically the issue is being escalated and decided at a higher hierarchy level.

Neither solution is particularly satisfying. Looking at Open Source though there is an obvious solution: A team depending on a component becomes a contributing team and provides a helping hand to the host team.

Now you may ask yourself: “Doesn’t that lead to complete chaos where people randomly write into code repositories of teams they are not a member of?” InnerSource comes with a set of roles and processes that bring clarity to what otherwise would indeed lead to chaos:

• Each InnerSource project has a set of Trusted Committers with clear accountabilities that go beyond simply reviewing code. Trusted Committers set the rules for contributions.
• Contributions happen in a structured way:
  • Contribution intent is shared early to make sure the contribution fits within the Host projects’ vision and scope.
  • Progress is shared early so the host team has a chance to mentor the contributor and guide them on the path to a desired design and architecture. That way frustration due to having to decline a contribution late in the process is avoided.
  • Decisions and vital communication happens asynchronously to be able to work around differing meeting schedules of people in different teams. As a result contributing teams gain autonomy to fix upstream artifacts without sacrificing the quality of the component that is being contributed to.

As a side effect InnerSource provides teams with best practices that make working in a remote first culture easy.

Instead of working in silos InnerSource fosters collaboration between teams. Much as in Open Source that means standing on the shoulders of giants: Instead of building every component locally InnerSource fosters reuse. It reduces the cost of reuse by providing a clear path to supporting the upstream team with the work of fixing bugs and implementing features.

Much like in Open Source InnerSource fosters a thinking of combined forces: Components that all business units and product teams need as a foundation can be built together. As a result all the boats are rising together: Innovation created in one part of the organization can create benefits all over the entire corporation. With teams that are familiar with InnerSource the load to move this type of innovation forward can be shared by all teams that benefit from and depend on the resulting components and services.

InnerSource gives your team the initiative and tooling to fix issues that block shipping features to customers. When done right maintenance of core components and services can be shared in a well structured way by a “virtual InnerSource team” that is larger than any specific product team.

In advanced settings those involved understand the value of contributors working on simpler features that may not directly benefit their customers – under the condition that it frees the host team to work on more complex changes that contributors have a business need for.

Short answer: No, not at all. Instead the two complement each other:

Well factored and well tested code is one goal of any agile team. In an InnerSource setting on-ramp times for team members but also for team-external contributors get shorter.

Teams familiar with collaboration who avoid assigning tasks are in a good position to also deal with external contributions in a flexible manner. They also bring a mindset and communication style that works well for motivating contributors over whose priority they have no direct influence. Working with intrinsic motivation instead of directing work means that host teams have the tools to successfully collaborate with contributors.

Teams pairing to work on problems are already comfortable with sharing progress early. There are two challenges moving to InnerSource from a pairing only culture: The host team needs to make time for supporting contributors and schedule that into their planned work. In addition when crossing team boundaries it is often hard to find time slots for pairing – in those cases it should be complemented with asynchronous collaboration. To avoid frequent disruption, host team members often need to intentionally plan their day more rigorously in InnerSource settings. Often it is simplest to set aside certain hours in the day or a day a week for mentoring contributions. Making that explicit at the team level takes a lot of pressure off the engineers trying to fulfill their own team goals but also helping out contributors. Another challenge with pairing is that it allows pairs to move very quickly together – often at the expense of writing important information down for the rest of the team. In an InnerSource setting it does take training to remember to bring all relevant decisions back to shared communication channels for both, host team and contributors. From a product perspective that does bring a lot more transparency to the development process. It also means that decisions that otherwise may have been taken at the engineering level only are now visible for everyone involved.

Remember last time you insisted that your product be well tested, preferably with automated tests so deployments can happen frequently and without human intervention? This goal now helps with InnerSource as well: Contributions are much easier if contributors can check locally if their changes are safe. Tests also ensure that the host team remembers to keep the contributed functionality if they are reminded of the reason for it by a failing test.

Remember last time you insisted on your team spending time to follow the goal of “leave code in a better shape than you found it”? That mindset helps in the InnerSource model: It makes sure that quality and cohesion of code remains high even when there are multiple contributions from different sources.

InnerSource and Agile uses some of the same tooling – for different purposes.

Issue trackers: In agile teams user stories are a conversation with the customer. Often the are put as sticky notes on a whiteboard. But also often they are stored in an issue tracker. As a result issue trackers are mainly perceived as planning tools, essentially a replacement for sticky notes on a whiteboard. In InnerSource, issue trackers serve for a conversation with the customer, but also for communication between members of a team of trusted committers and contributors working on one common InnerSource component. Issues in InnerSource become much more lengthy and wordy than in your average organization. They also track the implementation history and detailed design decisions for a change.

Code Reviews: In traditional organizations code reviews often serve auditing purposes.

They are done when development is finished. In InnerSource code changes are shared very early in the process, sometimes when nothing more than a rough sketch is done. The goal is to seek early feedback and mentoring. This is particularly helpful for teams that are on diverse schedules and cannot find any time for pair programming. Often teams have the aspiration that nobody walks alone – in reality though this often isn’t much more than an aspiration never achieved. In particular where contributions cross team boundaries.

Tools used in InnerSource can formalize this ask for more than one human to be involved with any change.

Focus on written communication: The goal with InnerSource is for the project to be transparent enough so that developers who are not part of the team can understand project decisions and follow along the process of software creation. As a result all communication needs to be in a place that everyone interested in the conversation can follow along: written, public, searchable and linkable. The goal is not to reduce distractions to others – the goal is to make all project conversations transparent.

As a result direct messages and mails are to be avoided. In order to make following conversations easier for everyone, messages related to one InnerSource project should be tracked in one separate communication channel: The goal is not to reach every person in the team of the InnerSource project. The goal is to find a common shared room for everyone involved with the project where they can have discussions focused on that InnerSource project.

Focus on written communication does not mean verbal communication is disallowed. There still needs to be time for a shared cup of coffee. Also solving problems together, pairing with others or in person hackathons are valuable to find solutions quickly. The team needs to make sure though that all project relevant decisions are kept in channels that everyone has access to. That also may mean to postpone important project decisions until everyone is back from vacation or waiting for another day or two if those working in another country are now on holiday. This is not only relevant for coding decisions, but also relates to general project mission, roadmap and direction. Without that information contributors will have a hard time understanding which contributions will have a good chance of getting accepted.

All discussions in InnerSource projects are visible to everyone in the company. Blaming people for their errors, ridiculing them for their mistakes, talking behind their backs about what they did wrong is a sure fire way to kill that trust and leads to the failure of that InnerSource project. This is particularly important for anyone in a leadership or role model position.

InnerSource and Planning

Planning plays a role in InnerSource in two important situations:

Contributing teams need to understand that working on upstream code typically does need more time than making comparable changes to their own codebase that they are well familiar with. They need to be aware of the fact that even if the host team does not have to implement the change they still need to be available for mentoring and reviewing. The time needed for that increases with the size of the change required. As a result early communication with the host team is important in particular in cases of larger changes.

Host teams also need to be aware of the time needed for mentoring and reviewing. Simply telling contributing teams that they can submit changes as patches does not reduce the time to make the change to zero for the host team. In addition host teams can find themselves in the rare situation where they are flooded with pull requests. For that event there needs to be a clear understanding of business priorities for the projects sending these pull requests. When overwhelmed with patches it is often time to think about sharing ownership of the component. In particular contributors that are coming back regularly and have earned trust of the host team are good candidates to receive the title Trusted Committer.

Some friction due to slightly different work culture cannot be avoided though. For these cases it is important to explicitly set expectations.

Imagine the following situation: As a contributor you finally made the change needed – likely with a little help from the host team. You proudly submit the pull request. Then – nothing happens. A day later – still no reaction. You start wondering if the host team has seen your patch. You wonder where to best ping the team about an update. This silence is very frustrating in particular for first time contributors. There are several remedies to this situation – remedies that need no coding knowledge, but require at least some basic communication skills:

• Make reaction times that can be expected of the host team explicit – e.g. in the contributing documentation.
• As soon as a pull request is received communicate the expected time it will take to receive substantial feedback instead of letting contributors wait.
• Communicate ways for contributors to get in touch with the host team and watch communication there.

Neither of these tasks needs code writing skills. This underscores the need for people beyond those who have programming knowledge. It is good practice to consider people covering these tasks as committed to the InnerSource project and include them as Trusted Committers as well.

Small changes and patches are easy to handle – they are quick to review and often do not carry a lot of risk when merged. One way to help host teams is to make time for splitting changes into smaller chunks. Make sure to communicate the wider context these changes belong to though.

Often making larger changes requires communicating intent and purpose early. It can also be beneficial to make sure contributing team and host team have enough time set aside for working on the change together. This means that people setting team priorities need to think beyond their own team when prioritizing changes. However coordination can still happen fairly independently as typically only the pair of contributing and host team are involved.

Rarely host teams run into the challenge of receiving too many patches from contributing teams. In that case it helps thinking about moving trusted contributors to the Trusted Committer role. In addition to simply help with reviews, new Trusted Committers can help with issue triage, mentoring new contributors and the like.

When faced with a lot of interest in contributions one additional factor to consider when prioritizing mentoring help for contributors can be interest of the contributors in a long term relationship with the host team. The more time is needed for mentoring, the more likely it should be for contributors to stick around longer.

In practice sharing ownership of the component with very active contributors has proven to keep the newly minted Trusted Committers engaged with the project over a longer period of time. Typically they help keep the component up to date and mentor new contributors long after the initial motivation for the contribution has been addressed.

InnerSource and Negotiation Skills

Coding and negotiation? You may ask yourself how these two go together. In particular for InnerSource host teams it helps to have a few stumbling blocks in mind when it comes to change negotiation.

As discussed in the last training segment, smaller code changes tend to get accepted faster. For the host team the advantages are clear and should be communicated to contributing teams:

• They are easier to review.
• They have less impact – both, positive and negative.
• They are faster to integrate.

As a result making small changes in an ad-hoc fashion typically causes little to no friction. They are a sweet-spot for drive-by contributions and often can be handled without much coordination support. Typically this is how InnerSource contributions start: Engineers in teams start collaborating on smaller changes and find that work very easy and light weight. Smaller changes are also changes that tend to go through without any need for escalation.

This may cause teams to adopt a mindset where InnerSource is only for the software engineers. However this learned ad hoc working model breaks as soon as the scope of contributions increases. If kept purely to software engineers, in the worst case even with push back from other roles in the teams this means that escalations will happen way more often. For modifications with a larger scope other roles in the contributing and in the host team need to be aware of the InnerSource work and need to bring their skills to the table:

• Together, the two teams need to figure out a good time for working on the contribution. If the host team has no time for mentoring the contributing team is more likely to get frustrated for lack of support. They may also be more likely to develop a solution that is likely to need a lot of rework causing frustration for everyone involved. If the contributing team has no time to focus on the contribution refinement cycles for the changes may become too long and interruptions too high.
• Before any source code is written the contributor and the host team need to figure out if the changes fit into the vision of the InnerSource project. Ideally this also means that tech and business level expertise needs to come together, preferably on the same communication channel where everyone can participate. Often this results in negotiations around if the changes should be made in the InnerSource project – with maintenance subsequently covered by the host team. It can mean that those involved need to clarify what the value for everyone involved is, but also if and how the contributing team can help the host team lower the maintenance burden.

“Just write the code and send us your patch” – sounds easy enough. Except in reality this is only true for the most trivial changes. In particular larger changes need coordination so that everyone involved has time to participate. Otherwise longer waiting times are expected. Crossing team boundaries also often means subtle changes in communication culture. People who are strong communicators can help cross these gaps by translating between teams in case of misunderstandings.

In contrast to teams working only on local code InnerSource host teams need to make sure their roadmap and vision is communicated with all potential contributors. In addition the host team needs to make sure that design, architecture and performance requirements are explicit and clear to everyone working on the code-base – including occasional contributors. This transition is particularly hard for teams used to work in very cohesive local settings. Essentially everything that in a very local team is clear implicitly needs to be made transparent and explicit. In the short term this does cost time – in the long term it helps contributors get up to speed faster requiring less support from the host team. One thing that has been proven successful in Open Source is making it easy for contributors to walk the correct path. This includes automated quality checks that fail at build time. While time consuming to write and maintain those take work off of the shoulders of the host team as obvious issues are highlighted automatically.

One difference with InnerSource to regular inter-team negotiation are opportunities to think out of the box: Imagine a contributor Bob who needs a very complex change in the InnerSource project maintained by Alice. Bob is just beginning to understand the code base and would have trouble understanding it on his own. In addition mentoring him through the process would take Alice a lot of time. However Alice has several high priority but easy to implement features on her backlog. What if Bob took some of those issue off of her backlog and implemented them – in return Alice has time to work on the change that Bob needs? For the sake of transparency those agreements should be explained to both, the host team and the contributing team. Otherwise they will have a hard time understanding why Bob and Alice are not working on the changes that each of their customers needs.

For another example, imagine a host team that is working on a very popular InnerSource project. Likely it is central to the business of the company. Over time more and more contributors are capable of making the changes they need turning the host team into a review bottleneck. To deal with that issue, a clear perspective on overall business priorities and importance of the contributing teams’ helps understand which patches to prioritize and stops the host team members from shifting focus constantly. As a next step the host team needs to think about expanding the number of Trusted Committers working on that InnerSource project. As mentioned earlier one option could be inviting people committed to the project who report to a different business line.

In particular when faced with a lot of contributions that are fairly complex, host teams need to understand where the time invest to mentor contributors is a worthy investment. The more time needed for mentoring the more likely it should be that these contributors will have time to stick around for longer.

Options for Shared Ownership

“If everyone owns it, nobody is accountable.” Traditional organizations prefer to have a single point of contact in case of issues. On the other hand allowing simply everyone to make changes surely will result in a mess that can no longer be maintained.

Based on that observation each InnerSource project has a dedicated team of Trusted Committers. Interest in maintaining an InnerSource project often is motivated by enlightened self interest: A team understanding that they themselves need the InnerSource project to fulfill their customers’ needs and understanding that opening the project up for contributions can spread the workload to move the project forward. Opening a project up for contributions though doesn’t mean that Trusted Committers have to accept all submissions. It is the team of Trusted Committers that sets the mission and goals for the project. They are then in a position to set direction and decide on change acceptance accordingly.

“Trusted committers are responsible for an InnerSource project. They review submissions and mentor contributors.”

This is a very simplistic summary of what the role of a Trusted Committer looks like. In reality one of the first questions often revolves around the need to accept each and every contribution. In particular where contributors have already invested a lot of time in the contributions can become frustrated when hearing that their work was in vain. Communication skills are important to make sure that contributors know roughly what the roadmap of the InnerSource project looks like. They are also needed to make sure that contributors know to share intent and progress very early on to avoid spending a lot of work without results. Last but not least rejecting contributions needs very good communication skills. To cut a long story short: Even if you are not writing source code yourself, your support is needed to clearly communicate the vision of the InnerSource project, to potentially help when contributions need to be rejected. Another aspect that becomes more important as the InnerSource project becomes more popular: Review and mentoring become more time intensive and over time need to be scheduled into the day explicitly. This does have impact on general capacity planning and should not happen “under the radar”.

On the other hand for contributors it is important that code review is not a last stage quality gate. Instead it is a way for continuously guiding contributors through the code development process ideally leading to better results faster. For that to work out in practice there needs to be time and space for team building – but across traditional team boundaries. Having at least a vague understanding of the different cultures in teams makes misunderstandings much less likely and the contribution process much more smooth.

In particular when host teams are flooded with contributions project leaders that otherwise focus only on their local team need to take a more global perspective: * Help the team understand different priorities for incoming contributions depending on overall company strategy. Often not all contributions are equally urgent. * Another way to help the team is to take over tasks like issue triage, handling initial responses to contributors and guiding larger contributions through the process. You can help your team by communicating to contributors if integration of the change takes a bit longer. * When faced with larger contribution requests teams can benefit from help negotiating with other teams the best time to work on these contributions. Often that is still way faster than your team doing all the work on their own. In particular first time contributors may need some hand holding – in particular for larger changes. Coordinating the timing around that mentoring can be a big help for your team.

“But we could simply fork permanently” …​ a misconception where potential guest teams believe that simply copying the code would be faster.

In the short term that is true. In the long run it means added maintenance. As a project leader you can help your team understand why contributing changes to the project you depend on is in the best interest of the business: Less work overall. Maintenance for the long term is taken on by the host team.

“We are using pull requests to develop our component – so we are using InnerSource on a daily basis”. While using pull requests and reviews is a crucial component, it is just the baseline for InnerSource projects. Just because two projects you depend on use pull requests on a daily basis does not mean that their openness to team-external contributions is the same.

InnerSource comes with different best practices. In order to avoid confusion and frustration for contributors it is important for host teams to define for their InnerSource project which governance model they want to adopt. Much like in Open Source these governance levels can differ substantially.

In the InnerSource Commons we provide an InnerSource pattern that defines at least three governance levels: * Source code is visible to everyone – but the team has no time to mentor contributors. From the outside this may look like your everyday InnerSource project. Making the refusal to mentor and accept contributions explicit though avoids confusion from colleagues trying to interact with the project through InnerSource means. Instead this communicates to those depending on the project that only feature requests and bug reports can be handled by the team. Essentially that means falling back to a regular traditional software development project. * Source code is visible to everyone – plus the team of Trusted Committers has set aside time for mentoring contributors. For these projects patches and pull requests are welcome. The team of Trusted Committers makes sure that project relevant communication happens in a written, archived, searchable and linkable channel. The team also makes sure that project relevant decisions are taken where contributors can see and follow them. Final decision making though rests with the team of Trusted Committers – and becoming a Trusted Committer of the project is tied to working for the initial project team. * As above – but the team of Trusted Committers is open to the idea of sharing write access. This approach requires a process for building enough trust with contributors for the team of Trusted Committers to share write access. This is particularly helpful where there is a long term relationship with contributors. Shared write access can remove the review bottle neck. * In the final stage the team of Trusted Committers is also ready to share control over who gets write access next as well as project vision and mission. While this will often result in the highest level of commitment from contributors it also requires a high level of coordination crossing team boundaries. It also requires the highest level of transparency when making decisions about the project.

To summarize each governance level needs a different approach to collaboration and coordination * Increased sharing increases the need for communication and co-ordination. * Increased shared accountabilities can slow down decision making.

What is implicitly clear for team members is best made explicit and documented if the project would like to encourage contributions. Topics like * Response times to expect when submitting changes, * communication channels to use when getting in touch with the team of Trusted Committers, * communication channels to use when trying to follow the project as a contributor * governance levels to expect from the project are all topics that the entire host team has to agree and communicate to contributors.

Increased sharing of accountabilities for InnerSource projects also has an impact on performance reviews. In hierarchical settings those often consider contributions local to the team. InnerSource contributors however are starting to have an impact outside of their own teams. InnerSource Trusted Committers have an impact on teams that can be outside of the scope of their own team. That means direct line managers are losing a certain level of control. They are also losing direct oversight. As a result, performance feedback from potentially remote teams should to be taken into account.

A common best practice for cross functional teams is a “you build it, you run it” setup. With contributions potentially coming from downstream users this best practice seems to break. There are several ways to use InnerSource in that context as well:

• Option number one is to move to greater modularization and collaborate only on the parts that are the same across teams and keep operations local.
• Alternatively work with contract tests to avoid API breakages.
• Work with internal service level agreements, make contributors sign up to warranty periods to remove the fear of the host team that contributions break production systems.

Relation to Open Source

InnerSource is the application of Open Source collaboration best practices inside of the confines of corporations. This makes understanding two aspects of Open Source easier for teams through parallels with InnerSource:

Much like in InnerSource, Open Source projects have different governance levels. Not all Open Source projects are created equal: While some groups only publish the source code, expecting no interaction, others want downstream users to become active and submit patches. Other projects have processes set up to allow for sharing impact on the Open Source project. Understanding these governance levels means that deciding which open source project to use in house will take Open Source governance into consideration as well. A downstream user of an InnerSource project will have learned to correctly evaluate the balance between moving fast but being unable to influence a project vs. moving at a slower pace but being able to influence a project together.

Working in InnerSource projects helps teams practice what it means to share the cost and effort to build platforms together. Sharing the work across teams helps innovate faster overall: Product teams with different focus areas can join forces to develop a needed base platform faster and share the resulting maintenance load.

The same dynamic drives several Open Source projects as well. Understanding it means that participation in these projects is natural for any team that has experience with InnerSource. Knowing that dynamic from practical experience also makes it easier for teams to recognise which open source projects are being developed according to these principles. Typically this understanding subsequently also has an impact on which Open Source projects teams decide to use internally.

Platform features that many teams need can then be created by collaborating instead of re-implementing them locally over and over. That makes it easier to understand the concept of how sharing effort can help to make the pie bigger for everyone and how it can help drive industry standards if done in an open source way instead of only internally.

In terms of mechanics both practices are very similar. The major difference is the visibility of projects: For InnerSource that is limited to the corporation, for Open Source they are public.

What sounds like a tiny difference on paper is a huge difference in practice. Going Open Source means that each and every message is publicly visible and potentially archived forever. This implication can be very uncomfortable in particular for employees not used to that way of working. In addition all actions being public means they are also available for public scrutiny – no longer can every move be vetted by corporate communication experts. Similarly produced artifacts are available for public scrutiny with regard to license compliance, security and the like – e.g. for competitors, for potential future new hires, for customers.

On the other hand it also opens the door to collaboration with others outside of the walls of one corporation – taken to the extreme that can result in co-opetition where competitors join forces to build a common technical platform, innovating and competing against one another on top of that.

Going open source also reduces the tax implications of collaborating across the boundaries of legal entities. While transfer prizing as a hot topic for many InnerSource effort it is irrelevant for any Open Source project.

While “what about publishing projects as Open Source” often is the first thought when talking about becoming active in the Open Source space. When experienced with InnerSource it becomes clear that publishing entire projects is only one way of being active in the open source space.

Instead it is much more natural to adopt an enlightened self interest point of view: * Where teams use certain Open Source dependencies in vital parts of their components it is important to ensure being involved upstream – even if the only goal is to understand the future roadmap of the project. * Where teams have a need for changes in open source projects they depend on, experience with InnerSource makes the advantages of participating upstream obvious: Clearly it is not only about a “sharing is caring” mindset – but it does have clear economic benefits where contributing teams have a highly reduced maintenance overhead if their changes are integrated upstream.

Taking another step back even the decision of which Open Source project to adopt and use internally will be influenced by the InnerSource experience of a team: * InnerSource trains teams to understand what to look out for in terms of ways of collaborating and communicating – from personal experience they will understand why it’s important for project to have clear, archived, searchable communication channels. They will also understand why it’s important that every major project decision is taken on these communication channels. * Understanding the different governance levels in InnerSource teams are well prepared to understand the implications of Open Source projects operating according to different levels of openness.