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:
- 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.
