Join us on Tuesday, 21st May, at 5pm BST / 6pm CEST / 11am CDT / 9am PDT to hear Michael Basil, from Dojo Center, & Guilherme Dellagustin, from SAP SE, discuss

Atomic Mindshare: InnerSource Dojo Way.

Join us on Thursday, May 23rd, at 9am BST / 10pm CEST / 1:30pm IST / 6pm AES, when Clare Dillon, from University of Galway, Ireland, will discuss the State of InnerSource 2024

Is InnerSource Right for My Project?

Is InnerSource Right for My Project?

InnerSource is the application of open source principles to company-internal software development. Done right, it unblocks progress and eases adoption of shared services and modules. This article contains guidance and questions to ask yourself when considering adoption of an InnerSource approach to running your project.

Will Contributions Come?

An InnerSource approach only makes sense if contributions are expected from the project’s users. You can expect contributions to come if you see or anticipate noticeable amounts of energy directed at your project area by its users. Some examples:

  • High amounts of project usage and adoption.

  • More feature requests than your team has time to fill.

  • Users doing workarounds to compensate for lack of features in your project.

  • Feature requests that take nearly as much time to explain as they would just to implement.

  • Multiple roadmap dependencies on your project.

Will I Support Contributions?

Even with willing contributors, the code doesn’t just flow in. You will need to encourage and support contributions via activities such as:

  • Understanding users' scenarios and suggesting what contributions in your project could help them to meet those scenarios.

  • Inviting users to make the contributions that they need and following up with them to ensure that they do them.

  • Maintaining an CONTRIBUTING.md document that contains everything an engineer needs to know to contribute to the project.

  • Giving up-front guidance and direction as to how to implement a given contribution.

  • Being available during regular hours for any ad hoc questions that contributors have.

  • Timely review of incoming pull requests.

  • Ongoing maintenance of submitted code (after the warranty window).

Is it Company Specific?

InnerSource projects make sense when the project is specific to the company or when its exclusive usage gives the company a strategic business advantage. Other collaborative projects should be run as open source to increase the contribution pool and impact.

Summary

If contributions will come and you will support those contributions and your project is company-specific, then InnerSource is right for your project.

Contributors