Soliciting contributions in an InnerSource community is more challenging than it is in an Open Source community for a number of reasons:
-
The sheer number of potential Contributors is lower in InnerSource communities.
-
Contributors will want to contribute during their work time, which means they are more time constrained.
-
Work in InnerSource might not necessarily be part of Contributors' official performance goals, so time spent working on InnerSource may seem to detract from achieving those goals.
That’s why it’s important for Trusted Committers to make the processes for making contributions and onboarding Contributors as frictionless as possible. There are a number of things that can help:
-
Have a good README.md in each code repository. A good README.md explains what’s in the repository and what it can be used for. In addition, it should provide detailed instructions on how to get, build, test, and use the software in the repository, including information about the license.
-
Have a good CONTRIBUTING.md that outlines what is expected of the Contributor. It should answer common questions, such as:
-
How do I submit a bug report or feature request?
-
Who and how do I contact if I have questions?
-
What are the conventions for code style, branching or commit messages?
-
What is the definition of "done" for a contribution?
-
What are the process steps that govern contributions?
-
What is expected of me in terms of supporting contributed code after the contribution is accepted?
-
What is the code of conduct and what are the guidelines to how the community operates?
-
If you have an internal license attached to the software, which in some companies is a prerequisite for sharing software across legal entities, include a copy of that license and an explanation of the rights and obligations in layman’s terms.
In addition to these documentary tasks, similar to Open Source software development it should be easy and straightforward to run and test the software being developed locally by potential Contributors, so they can start implementing and validating their contribution with as little effort as possible.
There are two common models for making contributions: shared repository and fork and join. Both have advantages, and as a Trusted Committer, you want to support both models to accommodate different needs of your potential and current Contributors. Your Contributors will often have questions about the contribution process or about the community itself, and someone has to be available to answer these questions. It is therefore important for any InnerSource community to have one or more contact persons that are available for answering such questions. Someone from the group of Trusted Committers is usually that contact person, or else they need to make sure there is a community member "on call".
It is also important to help potential Contributors determine what contributions are needed. These can be code contributions but also noncode contributions, such as writing documentation, creating artwork, or organizing events. One common way to do this is to tag "newcomer tasks" in the issue tracker used by the community or to implement a marketplace for open tasks Contributors can use.
In summary, it is super important for InnerSource communities in a corporate environment to keep the barriers to contributing as low as possible to allow as many people as possible to contribute. That means providing both access to helpful documentation and people in the community to answer any questions and to encourage collaboration. In sum, Trusted Committers should make sure that onboarding and contributing are positive experiences.
