Learning Path – Contributor

The Contributor section covers what it means to be an InnerSource Contributor, the aspects of behavior that will make you a successful Contributor, contribution mechanics and the benefits of InnerSource for your team and organization.

Introduction

Have you ever been blocked in your next coding task because another team didn’t have time to add a feature in their system that you depend on? Perhaps after a while you even had to do some extra work in your project to work around the missing feature. How nice would it be to never be blocked in this way?

With projects that incorporate InnerSource principles, you’ll never be blocked waiting for another team to deliver some needed feature. If you’re not getting what you need, you can make the change you need directly in the other team’s code repository by acting as an InnerSource Contributor.

The Contributor role describes a person that makes contributions to the repos of an InnerSource community project. This person may or may not be part or see themselves as part of the community. However, for quite a few people there is a sort of journey that contributors can make from just knowing about the community to using the community’s product to interacting with members of the community and finally starting to contribute. Finally, some of them may become Trusted Committers.

As a Contributor in an InnerSource community you will interact with people playing other roles of InnerSource, such as Trusted Committer or Product Owner and possibly with other contributors. At times, these roles can be played by the same person, such as Trusted Committer and Product Owner in small grassroots style projects.

This section gives you a very short overview of the other two roles, but we’d like to encourage you to read the introductory article of the Trusted Committer role, and we recommended you read the Lowering the barriers to entry article, too, before you delve deeper into the details of the Contributor role in this section. You can also watch the videos (introduction, lowering the barriers to entry) instead of reading the articles.

A Trusted Committer will be your host for your stay in the hosting community. They are the gatekeepers to the project’s code repository, and will move your contribution closer to production once they accepted it. It is their role to mentor you on your way to contributing to their community. They may help you directly or provide information to enable you to help yourself. This information could be established house rules for reviews, proposal templates for larger changes, pointers to documentation or code sections relevant for your contribution.

They also need to care about product quality, sustainability and project evolution from technical as well as general perspective, about reducing the barrier to making contributions for everyone, as well as about caring for their community in general. Caring for the community involves keeping it healthy, upleveling it and its participants, and advocating its needs in their organization.

The role of the Product Owner has some similarity with the product owner role of your average project. However, there are differences – depending on the size of the project, this role is often filled by the same person that acts as trusted committer. In larger projects, or in teams that only partially use InnerSource as an approach to fill their needs by accepting contributions, this role is likely filled by a person separate from a trusted committer.

Your interaction with the product owner role will likely focus on working out the fit of your contribution into the general product and its roadmap. You might work with the product owner role to make sure that general aspects of documentation, or consistency of UI/UX, are kept upon merging your contribution.

Last but not least, someone acting as product owner might have been involved in bringing the project, its benefits and community to your attention.

If you want to learn in more detail what these other roles are about, and we encourage you to do so, we’ve prepared separate sections about the Trusted Committer and the Product Owner.

In the following 5 segments you will learn more in detail about the various aspects introduced here.

The next segment will detail mindset and habit that create opportunities to become an InnerSource Contributor.

In the third segment we’ll look into the ethos of the Contributor – i.e. aspects of behavior that will lead to a pleasant and productive time for you and the host team, and might spark more collaboration. The guest-in-home analogy presented in the introductory videos will serve as a vivid example.

The fourth segment describes the hands-on things to do to make your contribution a success – the mechanics of Contributing. We’ll give practical tips to leverage when preparing to work on a contribution, during development, and also in the pull request.

After we’ve dealt with the personal, the interaction-focused, and the technical aspects of the contributor role, the fifth segment presents the benefits of making the effort to contribute. We’ll show benefits from various perspectives: yours, your team’s, and the perspective of the company at large.

The last segment will recap what we’ve learned about being an InnerSource contributor. We’ll share how you can continue your learning of InnerSource both with other online videos and articles, and through involvement with the online InnerSource community.

Becoming an InnerSource Contributor

InnerSource contributors operate outside of regular team boundaries, they are the links crossing organizational silos. As such, they need to be aware of a few common practices that make this work more effective.

So – you’re implementing a new feature for your team’s product. You need some functionality to get this feature working. Instead of jumping right into the implementation, slow down for a bit: does this functionality reflect a general issue? Is it something that other teams in your organization face as well due to the shared business domain? Is this functionality orthogonal to the domain of your project? If any of that applies, then start looking beyond your own team: is there a shared solution that you can use or improve to fit your needs? Should there be one?

There is an African proverb stating that “If you want to go fast, go alone. If you want to go far, go together.” The same is true for software development teams:

If you want to move fast, it’s a great idea to break dependencies. The downside to that can be duplicated effort. In particular when reimplementing core logic, there is a very real risk of the cost of duplication outweighing the benefit of independence.

Collaborating with other teams enables you to share development cost. Just like in Open Source projects, it can enable your team to build something bigger than you alone could have accomplished.

But every team has a different roadmap! I’ve tried to use shared components before – they always took longer to integrate than it would have taken me to reimplement them. Those components were always lacking in some aspect or another – and my feature requests never got priority on the roadmap of the other team!

In contrast to a traditional project, InnerSource projects come with the role of a Contributor. Yes, there will be times when you wish that the shared solution had a new feature. As a Contributor, you have the freedom to check out the source code of the component, make modifications to it and use the resulting improved version.

Yes, there will be times when you urgently need a bug fix on your timeline that doesn’t have the same priority in the host team. Becoming a Contributor enables you to act yourself and support the host team with fixing that bug.

This way of working requires a change in mindset for many: instead of waiting for features to be implemented or bugs fixed, instead of working around issues, there’s now a third solution. Spend your time and energy to check back with the InnerSource project on what your needs are – and then make the change directly in the shared project. So in addition to your coding skills, you need communication skills to be successful in an InnerSource project – to clearly articulate your needs and come to a solution that works for both your team and the host team.

“But I could simply go and fork the project, make my changes there and save myself from all this coordination overhead!”. Sure – forking the project is a way to get your job done. Except in the long run this means it’s on you to maintain that forked version for your team – and carry your changes forward for any new release the host team makes. Contributing your changes to the host team also means you get to benefit from their deeper knowledge of the component. They may spot issues in your patch that otherwise would only have become obvious in production.

A good Contributor can comfortably make a call for when it makes both technical and business sense to introduce a dependency and reuse a component instead of duplicating work. They can talk to management to explain the benefits of InnerSource contributions.

So is InnerSource only about SourceCode? Of course not. If your team’s business depends on an outside component, you want to make sure it’s well maintained and well run. As an InnerSource Contributor, you can help the host team in multiple ways. Reporting issues you see when using the component is a valuable contribution. Creating or fixing test cases that show that the code isn’t working as expected is valuable. So is improving documentation, so others spend less time using it and contributing to it. Supporting other users, helping with bug triage can be valuable contributions. Improving builds is another example of a valuable contribution.

To summarize no contribution is too small to contribute. Here is one that I made to tensorflow/models. A simple label change in a graph.

In this article you learned about what it takes to become a Contributor. We looked at the sharing mindset. We took a deep dive into the benefits of sharing solutions. Finally we had a look at what the scope for InnerSource contributions typically looks like.

Contributor Ethos

In the last segment we have outlined why you would want to reuse components and become active as a Contributor. This article shares best practices on how to successfully contribute your changes to the host team’s code base.

An InnerSource Contributor trying to make a contribution to the host team is essentially a guest in their home. In general, a good guest is expected to behave in a certain way:

• They knock at the door.
• They anticipate and follow house rules.
• They understand they are not the home owner and act accordingly.

How do these expectations apply to InnerSource projects?

When visiting your neighbors, you will likely not enter their home without knocking or ringing the door bell even if the door is open. Likewise in InnerSource as a visitor you won’t be able (or invited) to commit directly to any code repository.

Instead, after making your changes to the codebase you’ll submit them as a pull request. Much like you wouldn’t go about making large changes and what you consider improvements to your neighbors home, in InnerSource you will anticipate and follow the project’s collaboration guidelines. In turn, your hosts will show you the way – in InnerSource that translates to existing trusted committers spending their time to mentor guests.

What about those lovely summer parties that you went to? There is usually some planning ahead of time to choose the right date and time, to prepare enough food, or to have it contributed by guests. The same happens for bigger changes in InnerSource projects: a project will likely ask you to submit an issue describing your need and your proposed solution before making a large modification. Spending time on initial design instead of jumping right into the implementation saves contributors from having to redo a lot of their work. Sharing progress early – even when it’s not finished yet – helps the host team to mentor the Contributor towards a better solution. Much like Yonik’s law of unfinished patches explains: “A half-baked patch in Jira, with no documentation, no tests and no backwards compatibility is better than no patch at all.”

Does that imply that InnerSource projects place no value on face to face communication? Not quite: there is value in meeting participants face to face. Remember that all written communication lacks a lot of bandwidth compared to meeting in person: there are no gestures, no mimics, not even the tone of voice to help with understanding. In-person meetings are particularly valuable for interpersonal challenges, resolving conflicts and misunderstanding. However, communication about project decisions should be kept in writing, so that others can follow along and influence the project, and even years later it’s possible to trace why a certain decision was made.

Here’s my general rule of thumb: feel free to meet over coffee. Often that helps build a stronger team, especially when the team is split into multiple physical locations. Do make sure though that all decisions are made in a transparent and asynchronous way so that everyone – including those lurking in on your conversation – can jump in and become active contributors. One example of just how far one can take open decision making is explained in several exercises in the Open Organization Workbook.

Now, how do you figure out where an InnerSource project would like to discuss changes and future direction of the project? Many InnerSource projects outline how they like to be approached by potential Contributors in their README.md. If that document becomes too large to handle, contribution guidelines tend to be split out into a file named CONTRIBUTING.md files. Following those recommendations greatly helps Contributors selling their offer.

In all of these interactions, be prepared to “sell” your contribution to the host team. Articulate the value that the contribution will bring to their ecosystem.

The host team will be the one taking over maintenance for your changes. It makes sense to offer to fulfill a 30-day warranty on your submission. This can alleviate the host team’s fear of the Contributors not being available for support with fixing bugs after the time on contribution.

When you are visiting your neighbors, they will likely help you around in their apartment: they’ll show you the way to their living room and where the restroom is located. If you’re staying longer, they will probably give you more details: in my case an example would be to avoid turning on the dishwasher and the electric kettle at the same time to avoid blowing the fuse.

Similarly, every software system comes with its own quirks and intricacies. Often the most obvious ones are well documented. In smaller projects this documentation can be found in the README.md. In larger ones, contribution specific documentation can often be found in the CONTRIBUTING.md document.

In these files you can expect to find information on how to check out and build the project, how to run the test suite, how to submit changes to the project. It may point you to further documentation if it deviates largely from standard tooling – or if there are things you should keep in mind when making changes.

Going through that documentation usually turns out to be a huge time saver as it stops you from going down the wrong path and warns you about dead ends. If you find that things are missing from it based on your experience – patches to that documentation are typically very welcome: there’s nobody better suited to improve it than a new contributor who sees the project for the first time.

Try to figure out together with the project in their preferred communication channel if the changes you have in mind make sense overall. At the beginning it can be scary to have these conversations in a company public medium that is archived and searchable. The benefit here is with others coming after you with similar proposals: instead of walking the exact same path again, they can learn what was already discussed, and start from there.

Being a Contributor essentially means being closer to the host team than someone merely requesting a feature. Still, Contributors are not accountable for the software project to which they are contributing.

As a result, the final call on what the contribution must look like is with the host team. It helps to approach the host team with a humble mindset, with the assumption that all are collaborating towards the purpose of the shared organization. It helps to be open and transparent – not only about what was implemented and how, but also why the change was needed.

Treat any feedback as a gift: others are trying to improve your solution, saving you from trouble further down the road.

There is a chance that the host team does not accept your contribution at all. In that case it helps to work with the team, figure out if there is a sub aspect of your need that can be solved in their project. Collaborate on that sub aspect, and then find another way to solve the remaining issues on your end.

In this segment we have learned how to best approach an InnerSource project as a Contributor. We also looked at how to best communicate our need for the change and work on the solution together with the host team.

Mechanics of Contributing

Are you ready to start contributing to other teams projects/repos? Do you look forward to reducing your blockers not by management escalation but by collaboration? This section gives practical advice and highlights gotchas to remember when making an InnerSource contribution. It enables you and the host team to have as pleasant an experience as possible, setting the foundation for more contributions and great collaboration.

This article is separated into the three steps you will likely experience

• Soliciting your contribution opportunity and preparing to work on it
• Actually creating the contribution
• Polishing and wrapping the gift nicely and presenting it to the host team.

If your contribution is larger, you’ll possibly go through (some) of these steps repeatedly as you iterate towards your common goal. It is very likely that, as you do this, everything will feel more and more natural – maybe you’ll even wonder why you were doing anything else before.

One key difference is the turnaround time. With every first time contribution you are coming to a new (host) team. As a result, you’ll need to get to know their code base, technologies used, and also their preferred development environment (think test framework, build system). Even in cases where this type of tooling is standardized, each team will have developed some individual peculiarities. In addition to the technical side, you may be faced with differences in communication (think code reviews). Even if you are coming back after a while, the teams’ ways and members might have changed. Take your time as you would to catch up with a friend you haven’t seen in a while and whom you are visiting now.

Give yourself enough lead time. Start early enough, so that your work is available for you to leverage at the time you need it. It’s better to add more slack time initially – you’ll get a feeling about the turnaround times once you work with the host team. Often, you will notice a reduction in turnaround time per host team after making a few successful contributions to that host team. This effect can be observed with Open Source as well, you can read more about it here.

In your classic teams everyone had an idea of the expected lead times. Within an InnerSource context this might not be the case, either due to large time-zone differences (e.g. Seattle, USA with PDT vs Berlin, Germany with CEST) or you not being available full-time as with your original team, even if they are in the same physical location as you are. Thus, to prevent frustration on both sides, impatience and other non-trust-building effects, you’ll need to explicitly do expectations management with regards to your expected reaction times. One approach is to just quickly react with a “I’ll look into it, I won’t get to it in the next few days though” to a Trusted Committer’s feedback if you know that you’ll only be able to come back to them in a few days. Ideally, you can provide them with a rough estimate when you will likely have time to take a look at their input. Doing so builds trust by reliability even over non-physical contact, longer distance or otherwise asynchronous media. Established trust will allow you to overcome uncertainty bumps in the collaborative road ahead of you.

InnerSource puts huge weight on written communication – in particular when it comes to project decisions. Does that imply that in-person communication is forbidden?

Clearly not: while written communication shines when it comes to archiving and searchability, in-person communication shines when it comes to communication bandwidth. Try to make time to meet with people behind the names. If possible, try to meet them over your favorite beverage or some food. When you’re able to hear people speak, when you know their idiosyncrasies, remote collaboration will become easier.

Do you have a large feature that you want to contribute? Excellent! Wouldn’t it be horrible if all your work would be wasted? That can happen when the host team is already building something very similar, is planning to deprecate the software, or does not see what you are proposing to be a fit for their project. This challenge is a frequent one, and many team relationships suffered from not agreeing in advance that a contribution is a good fit.

Make yourself and the host team happy (and possibly save some work) by getting agreement from the host team on the user/technical design of the contribution before working on the changes and submitting a pull request. You’ll have to understand how the host team would like you to reach out for this. It’s best to ask a Trusted Committer about how to best discuss your proposal.

It is time-and-again-proven wisdom from the Open Source arena that, if you get to select how to discuss your proposal, you should try to select a written way. Ideally, choose the way where artifacts are public, searchable and perma-linkable to enable referencing your proposal in later discussions on this future contribution or other contributions to come – by you or others.

This type of high-level, early upfront agreement will save time in rework or rejection of your pull request down the road.

Great, you’ve made yourself familiar with the host team’s approach, and they are looking forward to receive your pull request. Which gotchas are there waiting for you now?

First, you’ll be in less direct contact with them. Second, you aren’t expected to be as knowledgeable and proficient as you might be on the full-time projects that your team owns. How can you now deal with this the best?

Try to peruse their documentation, the conversation archives and code artifacts from the host team to unblock yourself. This is similar to the situation you and likely most people find yourself in when using one of the popular OSS projects.

Much like in Open Source projects, ask the host team if things are going nowhere even after trying to unblock yourself. The questions you ask and the answers you receive will help others coming after you solve the same issues. Make sure that your communication ends up in a searchable archive that is closely linked to the project itself. Should you see easy improvement opportunities to reach said goal if it is not reached yet, you could try to – very politely – suggest an improvement to your host team. Sometimes the status quo arises from pure happenstance and stays that way because no one had a different idea or cared enough. Suggestions for improvement might be welcome in such cases. It doesn’t do either side any good for you to spin forever on a problem that could be resolved in a few-minute conversation with someone more knowledgeable about the project. It’s OK to ask for help.

There’s one key difference though, bringing advantage to you and other people in the future: In almost all cases you should prefer the projects’ official communication channels – this can be a mailing list, a chat room, an issue tracker or something similar, depending on the purpose of having a more synchronous or asynchronous way of interacting, or the varying needs for structure in the communication. All of those usually have in common that they are text-based, archived, searchable and come with stable links – this means your question and the answer will be written down, and the references you link in those answers will also be kept reachable. This way you can benefit from this passively documented knowledge in your search AND help future contributors have the same advantage. Such passive documentation could even serve to enrich ‘official’ documentation, should it happen to contain especially valuable gems – such as important definitions that got created ad-hoc.

As you work, if you find missing (or out-of-date) documentation, do a favor to the next Contributor and update it with what you’ve discovered. Project teams are often happy to receive additions, updates or corrections for their existing documentation – you’ve just found another opportunity to contribute! (Or just politely provide them with a feedback on your experience, and what would have helped you.)

We all have our preferences and opinions on code style, indentation, etc. The host team’s project has them as well. Try to adapt and match those preferences even if it’s not what you would normally do, and even if it is not specified in the projects’ `CONTRIBUTING.md`. If you are unsure, you can always ask politely. Nevertheless, a guest contribution for a feature or a bug fix is not the time to introduce a new way of structuring or formatting project code.

You’ve completed all the essential work, figured out all the quirks of the problem and the project you are contributing to, the time you’ve planned for the new feature to be used comes nearer, and you want to make sure your contribution gets merged in as fast and smooth as possible.

Here’s what you can do to make reviewing and merging as easy as possible for the the Trusted Committer and the host team. This might actually be pretty similar to what you may already be doing on your own project to get your changes accepted. If that’s the case – great, this is going to come natural to you!

The basic point here is to enable the Trusted Committer to validate the contribution without your presence and to ensure easy maintainability. Imagine you’ve built a feature or handling of an unsolvable quirk, or an important performance tweak, and your code is not entirely obvious (or might even look hacky / wrong at the first glance). If you have covered this with a test – and ideally have shed some words on the rationale behind it in a comment – a future editor will get reminded about the purpose of the code, and the test(s) will ensure that the value your code realizes will be kept, even in the new implementations. To achieve this, do the following:

• Add tests for your code contribution, so that validating the function of your contribution by others works well, even after some time, when you work in other projects or might have stopped contributing to this project.
  • Often projects will have automated checks against pull requests using those tests and the level of code coverage. Try to meet the criteria these tests enforce.
• Many projects will provide project build and validation scripts that enable you to locally test your changes.
  • Use those to ensure that your contribution works as well as possible before opening a pull request.
  • Having to review defective pull requests with easy-to-fix errors often bugs trusted committers. They will not fix your code but ask you to do so. This might create more round-trips and slow the merge.
  • No one is perfect though. Do your best, use prepared validation scripts if there are any, and give it your best shot with a pull request!
  • If your pull request keeps breaking tests, and you can’t find out why after giving it your best shot: try to highlight those tests in the pull request comment, illustrate your current understanding of the problem and ask for help on it.
• Don’t forget your own project that triggered your contribution in the first place. Create a modified build of the shared project with your changes and try it out in your own project that consumes it.

You want to ensure that your pull request includes any documentation updates that are relevant to your changes. Should the documentation live in a different place, make sure you add them there and link to them in your pull request.

To make the actual code review as easy as possible for the trusted committer or other persons reviewing it, try to follow these hints:

• Be sure that your pull request includes only the relevant changes for the issue you’re completing.
• Try to avoid super-large commits, commits with unclear commit messages, gazillions of files, incoherent changes (e.g. touching multiple topics).
• Provide a clear description of what this pull request changes, why it does so, and which issue and design documents (if there were any) it refers to.
• If there is anything uncommon or unexpected in the pull request, highlight it and provide the explanation. This will make it easier to reason about and solve potential blocking questions that a reviewer might have during the review.
  • The same goes for the scenario where you were unsure of the implementation or your approach – highlight it and ask for an insight.
  • Be civil and expect civility from the Trusted Committer’s review.
• Making pull requests too broad and large makes them more difficult to review, so it will take much longer before they’re accepted.
  • If you have a larger feature that you are contributing, it often helps to split it in multiple pull requests that are submitted, reviewed and accepted sequentially. You can still bind them together with an issue that you are referring to.
    • Some tools also have Draft / WIP pull request functionality that you can use to explicitly mark unfinished and non-polished work and still get early feedback from your host team’s Trusted Committers.
    • This allows you to ensure that you are going down a path that your host team is happy to merge once it’s done, adhering to the “release early, release often” idea in a way.
    • The host team’s responsibility is to create an atmosphere where sharing and discussing not-totally-polished work is possible and welcome. If you can’t fail safe, you can’t innovate, and collaboration becomes very hard.
    • Try to balance between asking for a review early and providing meaningful changes to review.

Some of these resources might be hidden behind paywalls. Sometimes your employer has a subscription enabling access, otherwise public university libraries often allow access for guests, too.

Benefits of Becoming an InnerSource Contributor

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

Conclusion

Thanks for reviewing the Contributor segment of the InnerSource Commons Learning Path. With this section you’ve learned about the Contributor role – the life blood of InnerSource projects. Contributors are external to the component owners’ team, and they bring additional valuable input to the project.

In this section you’ve learned about how to become a contributor by finding opportunities to contribute. We have reviewed the mindset and habits needed to find or create such opportunities. We’ve also discussed the ethos of the role and a suggested approach that is likely to lead to successful contributions.

Given the right mindset, habits and ethos, there are still a few details that might keep you from successfully contributing – hence, we’ve discussed these nuts and bolts in greater detail.

Last but not least, convincing your teammates and your organization at various levels can be hard, thus we’ve discussed the benefits of contribution from various perspectives to make this process easier for you.

We hope you’ve enjoyed watching the videos, and/or and reading the articles, and will be able to take away some interesting new insights for your journey towards InnerSource and being a good contributor.

If you haven’t done so already, we would like to invite you to learn more about the other aspects of InnerSource in our InnerSource learning path: http://innersourcecommons.org/learningpath/

We invite you to check out the InnerSource group InnerSource Commons online – feel free to join the discussion and share your experiences and lessons learned in your organization.

Live long and have prosperous projects!

Workbook

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

1. I can make sure others have to follow my suggestions to improve the project.
2. The host team will maintain the features I add on behalf of my team.
3. I can shape the solution to better fit my team’s needs.
4. I can help to shape all aspects of the project beyond the code itself (for example, GitHub reviewing, bug triage, tests, documentation).

Why 1 is incorrect: Open communities are not a dictatorship. As a contributor, you are part of a community helping the solution to grow and thrive. This may involve compromise at times, but will pay longer term benefits to you and the community.

Why 2 is incorrect: Reducing the amount of work needed to get a customer feature implemented is one of the main reasons for InnerSource. It’s correct that contributing changes back to host projects means that the host team becomes aware of the change and will take it into consideration in any refactorings that they are making going forward. That way the work that you as a contributor have to do to adapt to new versions is being reduced significantly. Still that does not imply that on acceptance the host team will be the only people responsible for making sure the change you submitted works as intended: The 30 day warranty pattern provides a formal means to defining how long contributors are responsible for fixing issues in the modification they submitted. In practice contributors often move closer to the host team and provide their expertise going forward.

Why 3 is correct: Shared solutions develop out of contributions from interested parties. Becoming a contributor allows you to shape the solution, always in consultation and collaboration with other community members.

Why 4 is correct: Contributions go beyond just code. There are many aspects that help to keep a solution healthy and thus make it successful, different aspects require different skills, though don’t make one more important than another. If the code is the machine, then think of these areas of contributions as the grease that keeps the machine running smoothly.

1. Needs that are shared across the business are good candidates for InnerSource.
2. My project will move the fastest if I have as few dependencies as possible.
3. The hosting team will implement the features that I need.
4. I should work only on features needed by my team.

Why 1 is correct: When many teams across the business have the same need, an InnerSource project is a great way to meet those needs at scale without duplicated work.

Why 2 is incorrect: If you skip the chance to leverage code that is already written, you will waste time coding solutions to problems that are already solved rather than adding unique value in your team.

Why 3 is incorrect: You can ask, but there may be times where the next need that you have in the project is not the next priority for the host team to work on. In these cases you can still get what you need by making an InnerSource contribution to the project.

Why 4 is incorrect: Working on other features of a project, or doing background work such as reorganizing code or documentation, may indirectly contribute to your team’s success, so it is legitimate for you to invest time on those things.

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

1. My team’s work is crucial for the company’s success, so my team’s voice has more weight in a shared solution community than others.
2. As I am a guest to the project, I am entitled to quick and comprehensive answers to my questions from host team.
3. As a guest to the project, I should make sure I understand and adhere to the rules and guidelines as outlined in the associated documentation (starting with, but not limited to, the README.md and CONTRIBUTING.md files) and can ask questions respectfully afterward for clarifications or help.
4. My commitment is to the change I provide. Once my contribution is accepted my work is done and I can focus on the core of my own project again.

Why 1 is incorrect: Even if your team may play a more central role in the company, you are still the guest when interacting with an InnerSource project. Ultimate accountability for decisions made about the project lies with its trusted committers.

Why 2 is incorrect: There is nothing wrong with asking good questions, and they should be responded to in a timely fashion. However, you are a guest and need to respect the time and effort of others in the community. Therefore, make sure to read and understand all available documentation before asking questions, and be prepared for answers from any educated project member, not just host team leaders. This helps your status in the community and avoids randomization.

Why 3 is correct: InnerSource stresses the creation of documentation, both as background to the work (for instance, README.md and CONTRIBUTING.md, and to justify individual decisions and code changes. The reason for a culture of documentation is to provide you, as a contributor, with the background you need to fit your change successfully into the project.

Why 4 is incorrect: Getting your contribution accepted is an achievement to be celebrated. However, your involvement does not end there. You should plan to be available at a minimum to fulfill a 30-day warranty on your changes (and their impact), or even better: stay close to the community and help out with additional contributions.

1. The solution owners and reviewers depend on contributions, so I help the project by posting a code change (such as a fix to a bug I have discovered or new feature I need) right away. The code review will then shake out any issues.
2. I am confident that my contribution will not be rejected, as this would constitute hostile behavior towards contributors.
3. I stay engaged and available for the project to support my changes and help drive the project forward.
4. I work only with people I am accustomed to working with, as this makes collaboration more efficient.

Why 1 is incorrect: Before contributing, you need to communicate your intent to other project members. Surprises in projects create a great deal of confusion, wasted effort, and irritation. Early and open communication will send a clear message of intent and will increase the chances of a smooth contribution experience.

Why 2 is incorrect: Great contributions are valued in open, shared solutions, but keep in mind that you are a guest. Suggested changes to the code may be rejected for many reasons: because they run counter to the intent of the solution, do not meet the coding standards, etc. This is not a personal reflection on you but a professional decision. Mitigate this by understanding the outlined requirements in the project documentation (README.md, CONTRIBUTING.md, etc.) and the project plans for the future. If documentation is missing, ask about the project’s standards, expectations, and plans. Your first contribution may well be to write or review the missing documentation.

Why 3 is correct: Projects need people to be engaged and stay atop of the open issues, help to fix issues, and weigh in on plans. Staying engaged will help you build a positive reputation and provide you with the opportunity to learn more about the project’s problem space.

Why 4 is incorrect: When engaging, you should engage with the community as a whole (all the guests as well as the host in our metaphor) and work in the open. Physical location or organizational location should not play a role in how you engage or with whom you engage. After all, InnerSource is about working together across boundaries for everyone’s success.

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

1. I understand that contributions to a good InnerSource project take about the same time as contributions to my team’s project.
2. I communicate my intent of contribution to the host team early on and ensure agreement on scope and timing.
3. I plan to refactor code I come across during my contribution work to my code style so that it is homogeneous in style and easy to understand.
4. I plan my pull requests to be narrowly scoped to make them easier to understand, review, and integrate.

Why 1 is incorrect: For many reasons, contributions to an open and shared solution will likely take more time than changes to a closed, single-team project. For example, coordination with the host may not be straightforward as it is with your immediate team. Your interests and the hosts’ interests may not easily align, and compromises may need to be found. Logistics may also add overhead, such as simply working in different time zones. To mitigate against these delays, plan with additional time. This will alleviate stress and tension and increase your chances of a successful engagement.

Why 2 is correct: Through communication, you allow everyone to understand your intent and give advice where needed. Communication ensures that you understand the plans and goals of others and can work together optimally for the greatest impact.

Why 3 is incorrect: Contributing a feature or bug fix is not the time to introduce a different coding or documentation style. Changing coding styles and convention in a project is a big undertaking, so you should rather align your changes to the coding and documentation styles in the project. If a different code style is needed, bring it up as an issue and have a discussion with the hosting team and the other participants outside of your current contribution.

Why 4 is correct: Small-scoped changes are easier to understand, not only in the code involved in the review, but also regarding the impact your suggested change may have on the rest of the solution. Limited-scope discussions will lead to a quicker acceptance of the changes and thus a more immediate benefit to the solution.

1. If I get stuck, I review the documentation and code to get going again. If that fails, I ask for clarification or help in the project’s public channels.
2. My code has tests for the changes I am contributing, I have tested and verified my changes before I contribute, and the tests are integrated into the CD/CI pipeline for the project.
3. I updated the documentation and tests to align with the code changes I contribute.
4. My contribution matches the project’s style.

Why 1 is correct: You should delve into the documentation that is provided to answer your questions. When you recognize that your answer is missing from the documentation, or is not clearly enough explained, asking a question to the project is the right next step. Not only will a clarification get you moving again, it will help future contributors.

Why 2 is correct: Having proper tests for the code you write is a general good engineering practice to ensure that the code is robust and maintainable. In an InnerSource project, the tests also help to build confidence in you as a contributor. Automating the tests as part of a code integration process also allows InnerSource projects to spread maintenance across all trusted committers of the project, independent of their membership status with the team the InnerSource project originated from. Thus, continuous integration and continuous delivery (CI/CD) are valuable in InnerSource.

Why 3 is correct: Checking tests and documentation for any needed changes are part of a solid contribution and will help guide future contributors down the right paths.

Why 4 is correct: Code conventions were put in place to enable all participants to understand the code quickly. Your changes need to blend in with the current existing code styles and conventions to ensure that your contribution is also easy to review and maintain by all others.

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

1. I can implement a solution I like without the team’s constraints.
2. I share the development effort with others and thus get functionality I otherwise would have needed to implement and maintain by myself.
3. I am building my reputation within the company.
4. I can become a better engineer.

Why 1 is incorrect: You have to work within the constraints of the shared project. In that respect, InnerSource is really not much different from working within a healthy team.

Why 2 is correct: In shared projects, you effectively pool your resources, thereby multiplying your impact and the speed at which features can roll out.

Why 3 is correct: As you interact with people outside your immediate team, more people will learn to know you, your work style, and your abilities, thus helping to build your reputation.

Why 4 is correct: Interacting with other engineers from different teams will broaden your knowledge and scope, thus helping you to design and build better code.

1. A contribution to another team’s code base requires typically less maintenance from you than a change to your own code base.
2. A broader spread of key knowledge reduces the risk of losing organizational memory as people leave.
3. Because others depend on your contributions, you can make sure the dependent teams support your team’s mission.
4. You can influence and help direct shared projects in support of your usage scenarios.

Why 1 is correct: Once the contribution has been integrated into another team’s project, it becomes an integral part of it. The contributor usually maintains responsibility for the new feature for an agreed-upon grace period, after which the hosting team maintains the code just like the rest of the project. However, your team should stay engaged, because you depend on the code and know it well. This will help to maintain your influence and avoid surprises down the road.

Why 2 is correct: Organizational changes are a fact of life. People change jobs, organizations need to adjust to new company directions, and so on. When key knowledge is restricted to a single individual or team, it can get lost fairly quickly. When the knowledge spreads through the community using the shared code base, there should always be someone with enough knowledge to help drive the project or solution forward in a consistent manner.

Why 3 is incorrect: Contributions are not a means for gaining leverage over others. They are a means to share a common path to the benefit of all participants. The attempt to use contributions as a lever to gain advantage is often met with harsh criticism, even triggering a split in the community and a fork of the code, which in this case is unhealthy and undesirable.

Why 4 is correct: Contributing to an InnerSource project gives you the best chance of ensuring that the shared project has the functionality needed for your scenarios. Not only can you contribute code to accomplish what you want, but the InnerSource process creates communication channels and decision-making procedures that take your views into account.

1. Fewer developers are needed to complete projects on time.
2. Increased documentation helps you determine afterward why decisions were made, and helps new developers come up to speed.
3. Broader spreading of knowledge encourages learning outside the immediate area of work and eliminates expert silos about important projects.
4. Shared projects lead to overall better alignment between teams and company-wide cross-collaboration.

Why 1 is incorrect: InnerSource should be adopted in order the align development more closely with the goals of each team, but not for cost savings or staff reduction. InnerSource projects require just as much coding (and somewhat more communication) than siloed projects. Satisfaction, however, should be higher at the end among teams as well as customers.

Why 2 is correct: InnerSource adopts, from the open source model, the principle that all discussions and decisions should be written and preserved. Through mailing lists and forums, comments in the version control repository, and bug reports, the organization preserves information about the goals of the project and the trade-offs developers have made. This is valuable later on for many purposes.

Why 3 is correct: InnerSource practices connect developers to both code and people with whom they wouldn’t normally interact. These connections spread technical knowledge about specific projects and create new social avenues where knowledge flows more easily in the future. Both of these aspects have the result of reducing siloed knowledge in the company.

Why 4 is correct: As projects are shared more widely, the teams using them tend to come in closer alignment as a necessity of using the same shared code base. This shared vision reduces duplicative work and is an overall benefit to the company.