Benefits of becoming an InnerSource Contributor

The most obvious motivation is what typically draws early contributors into open source as well.

Remember that annoying bug you’ve been working around for so long? The time and energy that maintaining those workarounds costs? What if instead of waiting for the upstream team to fix that issue sometime in the future, you could go ahead and fix it yourself? In this "scratch your own itch" situation first-time contributors often start with fixing issues in projects they depend on for their daily work to reduce the number of workarounds in their own codebase.

When deciding whether to create and contribute a fix instead of maintaining your own workaround, think about the benefit that the contribution will bring to the quality of your own changes. Instead of working in isolation, those working on the upstream project will be able to not only review but also improve your solution. You get support and mentoring which greatly speeds up your own development effort.

Spending more time with others means that over time you will learn how the team works, how it organises itself, which tooling it uses in which way to build their project. Oftentimes your own projects will benefit from that experience: instead of only reading about some new library or build system, you’ll be able to gain practical experience with it before going ahead and introducing it in your own projects. Working on more than one core project means that you will be exposed to a larger ecosystem from which to draw best practices and solutions to challenges.

A nice side effect of being able to spend some of your time in other teams is that your reputation and impact expand the boundaries of your own team. So in addition to learning from others and growing yourself, you get to influence projects. You influence directly via your own contributions and by sharing your experience and knowledge on project tooling and setup. This sharing might help the upstream project improve and accelerate development cycles.

Aside from all of these objective criteria there is a component that is very hard to measure, but has been reported both in InnerSource and in Open Source projects alike: people participate because they find work on those projects personally fulfilling and fun. Most likely, the aspect of being in a position to truly self select tasks to work on does play an important role. This self selection typically also leads to host projects being very welcoming and supportive in their effort to keep contributors motivated.

Remember that annoying bug that’s been finally fixed upstream? Why should your team spend an extra effort to contribute that fix to the upstream project?

For one, it means that maintenance cost and time is now with the upstream project. For every new release it’s on them instead of on your team to make sure it keeps working with your modifications and requirements.

Having team members work as active contributors in projects your team depends on means that they may get to have a say in the project direction and timelines, which can be beneficial for your team.

By using InnerSource teams can establish a middle path between "be independent and build your own" (including any number of new bugs that you own) and "save time and money by relying on existing implementations" (at the cost of creating long term dependencies which can only be influenced in a limited way). That way balancing reimplementing versus reuse becomes easier.

Remember that functionality that’s specific to your company domain - but that is maintained in multiple implementations across the entire company? What if there were a way to avoid a dozen buggy implementations and merge them into a shared asset? What if the development process for this shared asset ran without the usual drain of energy that central dependencies bring to the table? Many open source projects are being used by a huge number of players - some of who participate in their design and development. Encouraging cross team collaboration in InnerSource projects at the corporate level means that you can drive central innovation from the edges of your organization.

In general it is well understood that projects with a bus factor of one or two people pose a risk to the organization - all the more, when that project turns out to be central to the purpose of the business. InnerSource helps not only with making such projects transparent, but also provides tools to improve that situation by putting focus on mentoring and expanding the contributor base.

While cross team collaboration makes assessing individual contributions hard, it also enables learning and knowledge sharing within the organization. As a result, the impact of individuals will improve. Best practices and positive innovation will spread more easily across the entire organization. As a side effect, improvements to the work environment will more easily spread across the organization - helping retain employees.

On the technological side having more eyes with a more diverse background implies that code changes will be put under much more scrutiny, leading to better overall quality and security.

Finally, the focus on enabling project users and customers to participate in development provides a very clear incentive to make these projects easy to get started with: based on standard tooling, easy to understand, easy to re-use and as a result more modular and replaceable.

As we’ve seen in this article, many of the reasons for individuals and corporations to get active in Open Source also apply to InnerSource projects. We have also seen that it’s not only altruistic reasons that drive people to collaborate in InnerSource projects - often it’s easy to identify business reasons for when collaboration like this makes a lot of sense.