Ambysoft logo

Innersource: Applying Open Source Strategies to Internal Software Development

Follow @scottwambler on Twitter!

For the December 2000 issue of Software Development Magazine (later merged into Dr. Dobbs Journal) I wrote an article entitled Reuse Through Internal Open Source where I introduced the concept of a internal open source strategy for software development. This later evolved to innersource development, which has a much nicer ring to it. This article is an update to the material I originally wrote about internal open source.

One way to leverage open source is to start an internal open source, or innersource, initiative within your organization by setting up a private open source environment within your own intranet, as opposed to a public one on the Internet. You would make your work available to others within your organization, allowing them to evolve it and then share their changes as they see fit. This is true, honest teamwork between developers—other teams become involved if it is to their advantage, not because they are forced to by senior management. Your work must have an intrinsic value to the developers, however, by solving a problem that others are struggling with and doing so with sufficient quality. A properly run innersource initiative allows you to achieve reuse within your organization, reducing your development and maintenance costs, while protecting your unique software from the prying eyes of the outside world, thereby safeguarding your intellectual property (IP).

Innersourcing, when implemented properly, reflects many common reuse practices. To throw some pattern and antipattern names around, innersourcing results in the development of robust artifacts through self-motivated generalization while supporting and enhancing a reuse-friendly culture. It goes beyond traditional approaches to reuse—such as project-driven reuse, repository-driven reuse or items being declared reusable—approaches that often flounder because they don't motivate developers. Why do I believe that innersourcing is attractive to developers? Most existing open source projects are efforts that developers work on in their spare time—if developers are willing to invest their own time working on open source software (OSS) then it isn't much of stretch to think that they would be willing to invest company time on an internal initiative.


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:

Luckily, your organization likely has all of this software in place already.


Making Innersource Work

To ensure success:

  1. Inform developers that the software is available for their use either through an internal marketing campaign or by word of mouth.
  2. Apply innersource strategies not only to code but also to documentation templates, internal standards and guidelines, and common software models.
  3. 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.
  4. 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.
  5. 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.
  6. 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


Suggested Reading

Choose Your WoW! 2nd Edition This book, Choose Your WoW! A Disciplined Agile Approach to Optimizing Your Way of Working (WoW) – Second Edition, is an indispensable guide for agile coaches and practitioners. It overviews key aspects of the Disciplined Agile® (DA™) tool kit. Hundreds of organizations around the world have already benefited from DA, which is the only comprehensive tool kit available for guidance on building high-performance agile teams and optimizing your WoW. As a hybrid of the leading agile, lean, and traditional approaches, DA provides hundreds of strategies to help you make better decisions within your agile teams, balancing self-organization with the realities and constraints of your unique enterprise context.