Inner source is based on the idea of adopting open source processes to collaborate more effectively on proprietary software. The hope is that this will serve to minimize redundancy, improve reuse, encourage greater collaboration between teams, and leverage engineering talent from across the organisation.

There are some misconceptions about inner source. It does not mean outsourcing work from one team to a slightly less busy team. Neither does it mean that you are spared the rigors of planning or having to spend time on code management.

There can also be a degree of cargo cultism in play where teams adopt open source tools without making the organisational changes required to realise any genuine benefits. Inner source is more than just a matter of putting a project into GitHub and accepting pull requests. It's a development methodology that has far reaching effects around the way solutions are planned and delivered.

It's more of a cultural shift than a technical change. You need to establish culture of mutual respect that genuinely values collaborative and consensus-driven work. A sense of openness is required so decisions are discussed, decided, and documented in public. There should also be a sense of meritocracy, where merit is accrued through valuable contributions rather than job titles.

Pre-requisites

Not every organisation is going to be a fertile base for inner sourcing, and it helps if there's a natural tendency towards reuse and cross-team collaboration. This inevitably requires a sophisticated engineering culture based on a large pool of skilled engineers that have substantial experience of open source projects.

There also needs to be a clearly defined and shared vision across the teams. By this I mean that every team should have a clear idea of the systems they are building and the problems they need to solve. This helps to create demand for the kind of shared solutions that can arise from inner source projects.

A degree of standardisation around tooling is important as it can foster cross-team collaboration and capture the kind of passive documentation that builds up in pull requests, Slack channels, email conversations, and wiki comments. Ideally, it should be possible to index this information and make it searchable across information silos. This isn't easily achieved in corporate environments, but it would enable the kind of transparency that allows new contributors to find their feet on projects.

Drawbacks

Inner sourcing isn't always appropriate as some code bases don't lend themselves to this style of development. They may be too large or arcane to be accessible to external developers. An open source approach won't help you to deal with fundamental problems around the maintainability or security of code. There needs to be a sense of maturity and stability around a project before it can benefit from a community-driven approach.

These projects can also suffer from inconsistent participation. Not all open-source projects are equal in terms of popularity, and some may struggle to attract any contributions. On the other hand, too many contributors can confuse debate and bog down progress. A shared library is not just for Christmas and many fall into disrepair after an initial burst of enthusiasm. Others get distorted by a small number of enthusiast developers who flood the repository with their commits.

It's important to understand that this is not time-saving initiative. It will not spare you from the need to devote effort to design, develop, test, maintain, and enhance assets. The objective is to turn software development into a more transparent and organisation-wide collaborative activity as opposed to something that is happening in silos.

The burden of ownership

You can't crowdsource all the management overhead associated with a code base. Open-source projects still need ownership from either an individual or smaller team of maintainers. A successful project needs a coherent sense of vision, a carefully nurtured community, and people who are prepared to do a lot of spade work.

I know from personal experience that maintaining even a small open-source library can be very time-consuming. In practical terms it means reviewing incoming pull-requests, taking responsibility for the long-term health of the code base, defending the boundaries from unwanted scope creep, monitoring discussion, and ensuring that issues receive a reasonable response.

This can all be tricky to manage. The reality is that you will have to deal with pull requests that don't meet the project's most basic requirements. Some won't have any test coverage, while others will break existing tests. There will be enormous change sets that place an unfair burden on the code reviewer. Issues can also be a time sink as some will be more considered and sensible than others.

Open-source projects can become real battlegrounds. Differences of opinion can lead to unwelcome forking or prompt entire communities to abandon a project overnight. Managing this kind of behaviour can be particularly difficult once you factor in the internal politics that can bedevil engineering organisations.

This underlines the need for a more sophisticated and mature engineering culture. There needs to be a shift towards a more inclusive approach that accepts contributions from across the organisation. An open and communicative stance should become the default. Without this necessary cultural change, the management burden can quickly become quite onerous for maintainers.

Organisational challenges

Inner source is a development methodology that has far reaching effects around the way we plan and deliver solutions. The transparency and empowerment at the heart of inner source can often feel at odds with the hierarchical power structures inherent in corporate organisations.

You can get really lost in the reeds of some of the organisational issues. How do you manage prioritisation and planning when execution relies on an uncertain body of ephemeral contributors? How do you square an inner-sourced approach with the hard and fast demands of deadlines and project schedules? How do you encourage loosely affiliated contributors to work on the "right" features?

Team behaviours can be a barrier to adoption, and you need a very strong level of trust between teams. Some may struggle to overcome "not invented here syndrome" which tends to manifest in a natural suspicion of software they didn't write. Engineers might find they are not granted sufficient autonomy to work on projects managed outside of their team.

Care should also be taken over the mental health of engineers, who may feel pressured to work on projects outside of their normal team-based duties. This can lead to burnout as engineers struggle to maintain their desired level of inner source contributions on top of their regular day-jobs.

A key litmus test for an organisation's readiness for inner source is whether they have a track record for directly contributing to open source projects. This includes structuring engineer workloads to allow for project contributions outside of their regular work. This would suggest that the organisation has some of the culture of community-driven development baked into their DNA, making it a more likely candidate for inner source.

Filed under Agile, Development process and Strategy.