The success of open source inspires a growing number of organizations to adopt open source principles to build software internally. They recognize that open source projects are a productive way to deliver high quality code. Drawing inspiration from open source software development is not new. Companies like IBM, HP and Philips have explored this already in the early 2000s. Tim O’Reilly was the first to use the term “inner sourcing” in 2000 as a way “to use open source development techniques within the corporation”. Today Paypal, Bloomberg, Walmart, Scania and Zalando are examples of companies that advocate InnerSource. Paypal maintains the InnerSource Commons website and with O’Reilly they published Getting Started with InnerSource.
Organizations with a presence in open source often discover they are more successful maintaining their open source software than the software they build internally. They typically welcome contributions from the developer community and participants are primarily judged on their contributions. But what is more important is that open source software development addresses the need humans have to take ownership of their work, to explore, to create new things and to learn new skills.
A good way to understand the success of open source is to read Drive by Daniel H. Pink, a book about intrinsic motivation. According to Pink autonomy, mastery, and purpose are the three true elements that motivate us. In his inspiring book he argues that organizations that embed these elements perform better and their employees have a higher job satisfaction. To mirror the impact of open source software development, successfully adopting InnerSource requires a culture that promotes intrinsic motivation.
Share your work
The first step in adopting InnerSource is to bring all your developers onto a single platform. It increases visibility across teams, enables collaboration and allows teams to search, discover and reuse existing code rather than rewrite the same code over and over again.
Within the walls of the organization developers often work in silos. Imagine you are a member of a front-end team for an e-commerce site and you want to add a checkout method. You reach out to the payments team responsible for the task, but they let you know they are several sprints ahead with planning. Your feature request ends up on the backlog and you have to start chasing the product owner to get it prioritized for a future sprint.
On a shared platform you can familiarize yourself with the code, implement the new checkout method and open a pull request to propose the changes to the maintainers of the payments project. This allows teams to move faster. Rather than ending up on the backlog, the feature gets shipped. You might have to gently bump the maintainers to review and approve your contribution, but there is no need to spend weeks chasing the product owner. The next time someone implements a similar feature it will even go faster as the developer can learn from earlier contributions and related discussions.
Today you might find it hard to imagine people contributing to code that is maintained by other teams, but you’d be surprised. A good place to start is finding projects that are already used by several teams like a shared widget library, APIs or common utilities. Contributions can even come from non-developers. Support engineers can for example contribute fixes for bugs reported by customers.
Be aware that sharing your work comes with the need to fight technical debt. As lines of code grow overtime and get discovered and reused, it is important to keep the number of bad examples to a minimum.
It’s great when people start contributing to your projects, but how can you make sure the contributions align with the project goals and who is going to review all these code changes? In open source this work is done by the maintainers or committers of a project. Contributors generally become maintainers based on their merits. To become a maintainer for the Apple Swift project for example you need to have contributed “five non-trivial pull requests that were accepted without modifications”.
Many organizations that adopt InnerSource follow this example. They introduce the role of a maintainer or trusted committer to take responsibility for the review and approval of all contributions. Often maintainers are members of the core team, but not always. People who frequently contribute can also be granted commit access. Maintainers can rotate the job so that they can continue to be involved in other ways, like writing code.
Maintainers might have the final say on what gets merged into the master branch, but — like in open source — code reviews are public, allowing anyone within the organization to contribute ideas and suggestions. Some organizations pair maintainers with junior developers to do the initial code review. Reviewing code is a great way to increase your skills and to familiarize yourself with a project. With the feedback of a maintainer it becomes even more effective.
Another responsibility maintainers have is to guard the scope of the project. The README is a good place to share this information. It’s the first thing many people will read when they find a project. Apart from the purpose of the project, it should also include details on how to install and use the software. This makes it easier for developers to learn about the project.
It’s also strongly recommended to add a CONTRIBUTING file to every repository with guidelines on how people can report bugs and contribute code changes and how code is reviewed. Having a detailed CONTRIBUTING file can save maintainers a lot of work. If a contribution does not follow the guidelines, you can simply refer to the documentation. The GitHub Best Practices for Maintainers guide is a good place to learn more about documentation best practices.
Provide a constant feedback loop
Automation allows you to test the quality of your software whenever code changes are pushed to a branch. Apart from build and test execution, there are many other elements of code review that can be improved by tools including code quality standards, code duplication, code coverage or security vulnerabilities. When integrated with your workflow you can determine at any time whether the build and test runs were successful or not.
For maintainers it makes it easier to review and accept contributions. For contributors it provides a constant feedback loop. This way they will feel more confident to propose code changes.
Build a strong developer community
A benefit of InnerSource over open source is that it’s easier to build a strong developer community within the four walls of the organization as everyone shares the same overall goal and core values. Bringing everyone on a shared platform allows developers to take ownership of their work, share ideas and help each other to solve problems. However, this only works if people feel confident to speak openly. A good way to build trust is to organize recurring events for people with similar roles and skills. For example a weekly breakfast or lunch session where front-end developers or database experts from different teams can discuss relevant topics and share challenges they face. Monthly meet-ups that are open to anyone are also a great way to share knowledge, tools and best practices across the whole organization.
Build an open source presence
Many organizations that adopt open source principles internally also build a presence in open source. They share projects when they think there is a use for it in the open source community and when sharing it will not impact their competitive advantage or be in violation with any company regulations. Participation from the open source community can improve code quality and drive innovation. It can also help to reduce the maintenance costs. An open source presence is a great way to promote your work and engineering culture and that can help you to attract and retain talent. As the same open source development workflow is used internally, developers can be productive right after their new hire onboarding. A good way to get involved is to start with contributing to open source projects you use internally.
Hire a community leader
Adopting InnerSource and building a presence in open source can be pretty transformative. Hiring a community leader can help drive this initiative. This person can help to define the process to allow projects to move to open source. A community leader can work with legal to ensure the process complies with any regulatory requirements and with marketing to promote projects within the open source community. Another responsibility is supporting maintainers internal to the organization with following best practices, guarding the scope of projects and promoting them to the internal developer community. The community leader can also help with establishing InnerSource as an accepted practice within the organization by talking about it in public. If you talk about something in public, it can’t be ignored by your organization.
Let’s do this
InnerSource is a way to create a strong engineering culture that builds on the success of open source software development. It is based on a development workflow that enables collaboration and fosters the creation of high quality code through public code review and automation. It allows teams to always move fast as progress is never blocked.
Adopting InnerSource is not something that happens overnight as it has an impact across the organization. It requires a culture of trust where people can take ownership of their work and at the same time work together towards a shared goal.