Pull Requests Welcome™

Christian Emmer

Feb 15, 2020 · 5 min read

Developers like to complain. We'll complain about lack of documentation, lack of tests, choice of framework, choice of linter settings, and so on. My response to it? Pull requests welcome.

"Pull requests welcome," or the concept of innersourcing, is: what if we maintained software within our organizations like open source projects, without necessarily open sourcing them. That means opening up projects to any number of contributors, so long as their changes pass published quality requirements and adhere to clear contribution guidelines.

Benefits of innersourcing

The first benefit is you end up with higher quality software. More developers bring more perspectives, but more importantly they bring more hours that can be spent on the project. Cutting corners in development is a necessary cost of time restriction, but being open to contributions from others enables paying down that tech debt faster.

It increases code reuse. For projects that were previously closed to other teams, innersourcing those projects opens them up to be used either directly or as references for other projects.

Innersourcing breaks down silos and opens knowledge sharing. Silos can breed territorial behavior and an "us vs. them" mentality, so breaking down those silos enables healthier collaboration.

More eyes on the software means more eyes that can catch bugs or security issues earlier. It's well-known the earlier an issue is discovered the cheaper it is to fix.

Private software stays private. Innersourcing is not open sourcing, all trade secrets and sensitive information stays behind your firewall.

If your organization is interested in starting to open source projects or becoming a major contributor to some, introducing innersourcing would be great practice.

Requirements for innersourcing

The innersource project's code, documentation, and tools must be available to all developers in your organization. This is essential for new contributors to succeed.

Every contributor who is trying to add value to the innersource project must be welcome. Open collaboration invites more contributions, as long as those contributors feel welcomed. This very well might require a culture shift in your team if they're not used to collaborating openly with other teams in your organization.

Contributions to an innersource project must be evaluated on their merit. Not all new contributions will pass the maintainers' quality requirements, but they all must be evaluated fairly.

Communication around an innersource project and decisions made about it must be transparent. Ideally this communication and decision-making process can happen in a way that can be archived in completeness for future contributors. The idea isn't to cause "death by a committee," but rather to allow any party with a stake or interest in the project to participate.

The project must have maintainers or coordinators, and those people must hold code reviews. Having a stable set of people with deep expertise helps ensure consistency, quality, and direction for the project. Having code reviews and encouraging frequent releases causes feedback earlier in the development cycle.

Is innersourcing right for your organization?

Innersourcing may not be right for all organizations. Innersource projects need clear vision, maintainers need experience with working collaboratively, developers need strong communication tools and behaviors, and leaders need to support all of it.

That last part is crucial, leaders must support the culture shift, or it has no hope of succeeding. This means leaders need to provide developers enough autonomy to contribute to projects outside of their team's domain. Not all organizations are willing to provide that level of autonomy, and some for good reasons, so innersourcing may be a bad choice for them.

Not all projects are right for innersourcing. Some projects may be sensitive enough they can't be shared more widely or need to be worked on in silos, but the great part of innersourcing is it doesn't have to be applied to every project, and it doesn't need to be applied widely to start.

How to get started

The first existing project your organization tries innersourcing with doesn't need to be code, it could be a set of schema definitions, documentation, best practices, or examples of frameworks used within your organization. Emphasis on existing - it's not a good idea to use a greenfield project that might lack clear direction. Any kind of project that is kept under version control is eligible for innersourcing.

Start with something small, it's probably not a good idea to start with your legacy monolith that doesn't have updated documentation or high test coverage. Pick a project that has a smaller footprint, decent testing and documentation, and would be easier to agree on and add contribution guidelines to.

Pick a project that has a variety of stakeholders. If the project only benefits one group of people there will likely be limited interest in contributing to it.