Although OSCON wrapped up Friday, I have a few more thoughts and observations that I will share this week. Danese Cooper, Arnold Goldberg and Manish Jain from PayPal gave a Key Note where they discussed InnerSource. This wasn’t a term I was familiar but as I watched the keynote, I thought how the concept, better code and craftsmanship, was applicable to software development in general. The keynote includes a video from Paypal employees describing the benefits of using InnerSource.
InnerSource is not simply using open source in your company, it is defined as
The application of best practices, processes, culture and methodologies taken from the open source world and applied to internal software development and innovation efforts.
Danese’s believes that InnerSource is now important because open source is so prevalent in companies. The focus to date has been getting more code out in public. Companies that can figure out open source on their already have. Also that simply adopting open source or sprinkling it inside your enterprise doesn’t change culture and that many of the tenants of open source can make companies better at any software projects. Danese also believes that:
Open source has a long tail and that tail is InnerSource
So when should you consider using InnerSource? If you problems include development Silos, code quality, no time to document.
A company adoptiong InnerSource can see the following benefits: developer satisfaction, which leads to productivity, better craftsmanship, mentorship and velocity.
I heard several times at OSCON that if code is written with the expectation that it will be open sourced, developers will do a better job. Developers will get to the level of documentation where the code is easily understandable because they know someone else will be reading and or using it. If you wrote code with the mindset that it may end up as open source, it will be better code, whether it is published or not. I remember writing code where I solved a problem in a way that I wasn’t proud and with the expectation of implementing a more elegant solution. Knowing my name would be publicly linked to a hack would have ensured that I went back and fixed.
If these ideas seem appealing, here are some ways to get start. Visit InnerSourceCommons.org where you can find a free 25 page book, developed by PayPal and O’Reilly. Here is a description of the book:
You’ll learn specific advantages of the InnerSource strategy, including:
-
Faster development: Programmers use unit tests, code coverage, and continuous integration to remove bugs at early stages
-
Complete documentation: Code is documented better, both in-code comments and less formally on discussion lists
-
Code reuse: Programmers across the organization understand the code and architecture of modules developed by other teams
-
Cross-team collaboration: Contributions by members outside of the team are frictionless and rarely have to be rewritten
-
Development with GitHub: GitHub maintains private repositories for in-house projects as well as public repositories for open source code
If the topics interest you, the Commons is where companies can share ideas and learn together. I have always believes in collaboration and sharing and this project seems like a great concept. While it is focused on coding, I am wondering how it can be applied in a broader way across enterprise IT. How many times have you heard “yes we have documentation but it is outdated so don’t use it” or struggled with changes or projects that cross domain boundaries. ITIL was one approach and I am wondering how InnerSource and ITIL can be merged together.
Let me know if InnerSource resonates with you as much as it does with me.
