Innersource: Applying Open Source Strategies to Internal Software Development
Organizing Internal Open Source
How do you run an internal open source initiative? Start by identifying a vision and general architecture for your efforts and then build an initial version of the software following your typical development process. This initial version need not be complete, but it should provide some initial value to the people who leverage it, while reflecting the overall vision so as to provide guidance to developers who choose to evolve it. A product page, or set of pages for large efforts, that links to your artifacts (for example, the product overview, the source code, your test suite, frequently asked questions and licensing definitions) for the software, should be set up on your intranet. Ideally, the definition of usage rights should be fairly straightforward because your software should only be used within your organization, although issues such as chargebacks (and politics in general) can get in the way. And if you’re bogged down defining your own internal usage license, your organization’s culture likely won’t allow you to successfully develop innersourse software—or any other software.
Identify a team who will be responsible for shepherding the effort as well as accepting submitted changes. Shepherding often simply entails staying actively involved with the initiatives’s chat room, discussing suggested solutions and their potential impacts, communicating the vision, and trying to put people together who are working on similar issues. Changes need to be reviewed for applicability as they are submitted and then should be made available to the overall effort.
Innersource Tooling
To make your internal open source initiative successful you will need the following tools:
- A code repository, typically a version-control tool from which people may check out and submit code and other artifacts.
- Communication software, such as a chatroom, to facilitate collaboration between developers.
- Defect-tracking software enables developers to post identified problems and their solutions.
- Software development tooling.
Luckily, your organization likely has all of this software in place already.
Making Innersource Work
To ensure success:
- Inform developers that the software is available for their use either through an internal marketing campaign or by word of mouth.
- Apply innersource strategies not only to code but also to documentation templates, internal standards and guidelines, and common software models.
- Focus on quality and not quantity—two or three reusable programs employed by several teams offer more value than 20 or 30 products gathering electronic dust.
- Overcome cultural and political obstacles. Forget cost chargeback schemes, forget complex management processes, forget endless meetings and instead focus on developing software in a collaborative manner.
- Be prepared to keep an eye on individual developers: Programmers should be plugging away at innersource because it makes sense to do so for their current, primary initiative.
- Be prepared to scale. Critical innersource initiatives will have hierarchies of people involved: Some will be allowed to directly submit their changes, whereas others, often people new to the effort, will first submit their changes through some sort of quality gate.
Contrary to popular belief and to their commonly chaotic appearance, open source initiatives are often well organized. The same can be said of innersource efforts.
Related Resources
- Reuse Through Internal Open Source – The Original Article
- Knowledge reuse and InnerSource: paving the way to a communication culture
- What is Innersource?
Suggested Reading