Contributors are the life blood of InnerSource projects. Every project that is run as an InnerSource project comes both with the promise and with the ultimate goal of expanding their development team beyond the original founders, tapping into the potential of further collaborators amongst users (also sometimes referred to as customers in corporations) of that project.
However, what would motivate an individual developer to spend time on a project that is not under the direction of their manager? What would motivate a manager to make time for their developers to improve projects that are not 100% under their purview?
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 maintainting 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.
Team level motivation
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 organisation.
In general it is well understood that projects with a bus factor of one or two people pose a risk to the organisation - 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 organisation. As a result, the impact of individuals will improve. Best practices and positive innovation will spread more easily across the entire organisation. 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.