Winston Churchill and the open source way
Winston Churchill was known as a charismatic leader and statesman, able to rally his country to great things when they needed it most. He was also fond of the occasional salty outburst when needed—I won't repeat one of his more famous ones here, except to paraphrase it a bit:
"Keep Calm and Move On"
Despite the fact that he never actually used that specific phrase, it's been widely speculated that he would have heartily approved of the very trendy Keep Calm and Carry On meme going around today. At the heart of these two ideas is the notion of overcoming barriers and finding alternate means of achieving your goals. Even in today's world of increasing open source usage, there are still organizations that fear the perceived issues with using or contributing to 'free and open' code. With that in mind, here's a proposal for those championing the open source way inside organizations to help move your cause forward—consider advocating the use of an innersourcing model for your company.
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. Implementing an innersource community is actually very similar to creating a new open source effort, but entirely within the walls of your trust circle. Here, I highlight some of the major do's and dont's.
Do have clear community goals and 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 and 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 and 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 decentralized 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 showstoppers, 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!
Comments are closed.