Using open source methods for internal software projects
How innersourcing can create collaboration within organizations.
Pipe fittings (source: Torsten Bätge via Wikimedia Commons)
Much of the modern business world understands the benefits of using open source applications within their IT ecosystem, but not all businesses are willing or ready to offer their own internally-developed software as open source. There is, however, a way that businesses can apply open source development methodologies and philosophies to their software: innersourcing.
Whether you call it “innersource” or “internal collaborative development,” the basic idea is to build up communities of trusted contributors and collaborators around applications developed inside of a company, no matter which part of the business the collaborators belong to. For example, one department within a company might be working on tooling for managing Linux containers, and another department might use that code and want to contribute bug fixes or features to it.
Learn faster. Dig deeper. See farther.
I recently attended the InnerSource Commons Summit in London on behalf of Capital One, where I joined representatives from diverse companies and academic institutions to discuss and learn more about innersourcing. I wanted to see how others’ experience with it compared to the successes we’ve seen at Capital One.
The first thing I noted at the conference was that the adoption of innersourcing is growing and becoming more formalized inside of many organizations. The idea that better communication and greater transparency leads to stronger collaboration is fairly obvious, but many attendees at the conference expressed their surprise at just how much that collaboration can lead to a sense of community and to real meritocracy within and across their software development teams. Attendees also reported that employees were happier, more productive, and more likely to stay with the company longer when allowed to work on innersource and open-source projects.
Of course, like anything worthwhile, the road to innersource nirvana isn’t easy. Conference attendees discussed several challenges that organizations face, including getting appropriate support from upper management, recognizing contributions to innersourced projects, and how to measure success.
My top takeways from the conference were:
- Getting support (and resources!) from upper and middle management is absolutely vital, especially when you’re contributing to another team’s project.
- It’s important to build a culture that rewards cross-pollination and collaboration across team boundaries, and not just individual efforts. Are you getting rewarded for collaborating with other teams, or for taking the time to review code contributions from others?
- Project owners and project managers need to be comfortable with innersourcing and plan appropriately for cross-team collaboration, especially while working in an agile development model. Are you anticipating collaboration in your sprint planning sessions?
- You should find a small number of appropriate metrics for determining the health and success of an innersource project. It shouldn’t be as much about “lines of code” as it is “number of outside contributions” and “what percentage of outside contributions get accepted.”
It’s an exciting time to be involved in software development, and to see the benefits of innersourcing and agile development. If you’re interested in learning more, there are two great events at OSCON 2016 to help you get started. The first is an innersource tutorial led by Danese Cooper from PayPal. The second is the “InnerSource Overview,” a series of five different companies highlighting their adventures as they have sought to innersource their internal applications.
This post is a collaboration between Capital One and O’Reilly. See our statement of editorial independence.