Contained InnerSource
Apply InnerSource methods to facilitate collaboration in a cross divisional project but don't invest in soliciting contributions from outside of that project.
Traditional development practices do not work as effectively for cross divisional projects as do InnerSource style practices. However, Management does not support adopting InnerSource practices because it regards efforts for soliciting and facilitating contributions from outside of the project as detrimental for the required efficiency.
- The company plans to develop a new software-intensive product; multiple business units (BUs) are involved in the development of this product
- There is not one single BU which has the required resources or knowledge to do the development on its own.
- An InnerSource program and required tools exist.
- The InnerSource program advocates using the full spectrum of InnerSource practices (we call this Full Scale InnerSource for the purposes of this pattern).
- The product's importance to company revenue and the committed feature content and dates require a development paradigm that provides known, stable development resources (headcount).
- Full Scale InnerSource includes substantial effort for soliciting and managing contributions as well as onboarding new contributors, which is hard to plan for and may have some effect on the ability to control the timeline for completion and deployment.
The BUs involved in the development of the new product each dedicate development resources to develop the new product, apply the InnerSource working model and adopt InnerSource tooling to facilitate collaborative development but limit the scope of InnerSource practices to the project. No effort will be spent on facilitating and managing contributions from outside of the project.
The application of InnerSource is contained to the project. The project may share the developed artifacts outside the project but is not required to do so.
Contained InnerSource effectively allows and facilitates the development collaboration of multiple BUs where existing traditional development infrastructure and processes would not have worked efficiently.
Product development can be successfully completed. Even though Full Scale InnerSource was not implemented and the full benefits from InnerSource practices, such as exemplary documentation which facilitates reuse beyond the project context, are not realized, the project's success still achieves several benefits that wouldn't have been possible through traditional development. In addition, it lends credibility to the concept of InnerSource.
- Large Company
- Initial
- Tim Yao
- Georg Grütter