Keep Calm and Innersource On

by Guy Martin (Red Hat)

“Open source is scary!”

“How can something ‘open’ be secure?”

“Won’t using open source in my products mean I have to give away my IP?”

These are all examples from real-world conversations with both external and internal stakeholders during my career as a developer and consultant.  There are many more such examples, which I previously built into a blog titled Top 10 Signs Your Enterprise Doesn’t ‘Get’ Open Source.  The good news is that with the emergence of Linux, Apache, JBoss and other important open source technologies, we don’t hear these kinds of things as often.  The bad news is, there are still quite a few industries and companies where these fears are the norm.

However, there is a middle ground that many companies have yet to discover: innersourcing.  What is innersourcing? It’s the practice of applying open source methodologies and best practices to internal software development efforts. Properly implemented, the results can be dramatic – harnessing the energy and passion of your developers while helping drive software reuse and increased ROI in your organization.  In short, it’s the perfect way to calm the fears of management who may not be completely ready to go ‘fully open source,’ but who want to take advantage of what makes open source so successful from a development perspective. It also gives your developers freedom to show you what they can do when they are free to innovate.

Keep calm and innersource on

Image Courtesy of

Implementing an innersource community is actually very similar to creating a new open source effort, but entirely within the walls of your trust circle. To that end, it’s worth highlighting some of the major do’s and dont’s:

Do Have Clear Community Goals/Identify Collaborators

Understand the teams and projects you are choosing for this new style of development.  Entrenched teams working in a very specific silo of expertise may not be the best choice when starting up an innersourcing effort. See if you can pick a team working on a library or component that is used by multiple teams – these teams are usually better equipped to deal with a new style of development.

Don’t Neglect Bug/Task Tracking & Documentation

Just as in regular external open source communities, it’s important to lower the barrier to contribution by others outside of your immediate team.  To do this, make sure that the project has an up-to-date bug/task tracking system as well as current documentation that can be easily accessed and used by the entire innersource community.  If you lack documentation, you can still make that a task for a new contributor to work on – it may garner you some contributors whom you otherwise wouldn’t have expected. Having this information available for potential new contributors and community members gives them something to latch onto – a place where they feel they can contribute something useful and valuable.

Do Define Your Contribution Governance Model

Give some thought to how contributions back to this innersource community happen – is this a benevolent dictatorship, with one person approving all changes, or is the control distributed to a committee of contributors that approve/review contributions from outside of the core community?  While the former has worked well for projects like Linux, it’s probably easier and more effective to take the latter approach (or one similar to it), since it allows for a sense of shared control for all of the community contributors. Having this de-centralized control of code commits also gives potential contributors something to aspire to – in a true meritocratic community, those contributing the most value to the project can and should be given membership in the ‘committer circle.’

Don’t Forget About the Human Element

For an innersourcing effort to work, companies need to consider the human resources and compensation ramifications inherent with this model.  For example, making sure that developers are measured on and given credit for their contributions to projects outside of their direct scope is vitally important.  There may also be some management perspectives and other cultural barriers that need to be addressed.  None of these things need be show-stoppers, but failing to address them early on can make the transition to an innersourcing model more difficult.

And Finally…

Remember the open source maxim: ‘Release Early, Release Often.’ Pick one or two small projects to start with, and iterate on the process of getting those teams to collaborate together in an open source fashion. By doing so, you can garner some quick wins and showcase the value of open source methodologies at work. Very few leaders will argue against the benefits of collaboration, but actually proving those benefits by implementing an innersourcing strategy will win you the support you’ll need to continue pushing your organization toward an open source future. For additional resources on implementing an open source-style practice in your organization, refer to The Open Source Way handbook.

Also, if you have an innersourcing success story, please post it in the comments section of this blog – we’d love to share success stories of organizations benefitting from this model!

Guy will be discussing the concept of Innersourcing during a live webinar on Thursday, October 4, 2012. Learn more about the event and register here.

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.