Inner source describes a range of practices so at Flutter we define 3 named inner source stages in the Inner Source Pyramid to help us discuss and agree operating models more precisely:

These stages are visually represented as a pyramid because:

1. Each stage builds upon the foundation of the one below and is not possible without it.
2. It reflects the volume of services at each stage with only a few requiring stage 3 “maintainers in multiple teams”.

Higher stages in the pyramid are more complex, which is only justified if the circumstances require it (e.g. a high volume of contribution and/or teams involved). Each inner source capability therefore has an optimum position in the pyramid, and a higher stage does not mean “better” – it just means “more complex”.

Stage 0 · Closed Source

This is the typical status of a high performing delivery team before their inner source journey begins. A single engineering team are responsible for maintaining a service, and all changes to the service are implemented by this team. The service may be shared with other teams via API or build artefacts for local deployment, but only the owning team have access to source code and CI pipeline.

Stage 1 · Readable Source

The first step towards the transparency required for inner source to work. A single “maintaining” team are responsible for developing the service and operate their own deployment, with all changes to the service implemented by this maintaining team. However, other teams may also be deploying and using the service or including parts of it in their own services – possible because the host team granted read access to user stories, source code, test suites, CI pipeline and build artifacts to all Flutter engineers.

Stage 2 · Guest Contribution

The maintaining team retain full accountability for the service development and encourage and review ‘guest’ contributions from other teams who need to change it for their own deployments or projects. If the maintaining team decide the guest contribution is of sufficient quality it will be accepted and the maintaining team will take forward responsibility for it, otherwise the contribution may be rejected or re-worked.

Stage 3 · Maintainers in Multiple Teams

Multiple teams need to make regular changes to the service and must all align and agree. For consensus to be fast at least one person in every regularly contributing team must be an expert “maintainer” with dedicated time to work outside their own team. These maintainers act together as a virtual team to triage, review and approve the contributions from their own and other teams.