Choosing to use inner source for your product should be a deliberate and conscious decision based on its benefits. Flutter is a group of independent divisions so from a group perspective there are three high-level patterns for product development:

1. Independent : designed, built/bought and operated independently within a division by their teams with no cross-divisional collaboration.
2. Delegated : designed, built/bought and operated by one division on behalf of all other divisions.
3. Inner Source : designed and built collaboratively by several divisions, with each division operating their own deployment.

Comparing these approaches from the perspective of a division:

	Independent	Delegated	Inner Source
Predictability	Velocity and priorities fully controlled.	Projects depend on an external prioritisation process with other divisions.	Velocity and priorities controlled, but intent must be agreed with other divisions and cycle time expectation adjusted.
Efficiency	Start from scratch. Need to implement all features.	All features are implemented by another division, just need to use.	Need to implement specific priorities and deployment, get most features from other divisions.
Quality	Aligned with our standards, and can trade-off quality for velocity as desired.	Aligned with another division's standards and treated as a service dependency.	Aligned with cross-divisionally agreed standards, limited ability to trade-off quality for velocity.
Stability	Operational concerns fully controlled.	Must be managed as an external service dependency.	Operational concerns fully controlled.

Examples

Independent development is the default choice, and is optimum when:

• expected efficiency gain of re-use across divisions is low (e.g. front-end web or app interfaces).
• capability is important but not complex enough to justify cross-divisional collaboration (e.g. content management).
• cost of change from existing divisional capability is too great to consider alternatives (e.g. data services)

Delegated development is optimum when:

• capability is required but not strategically important (e.g. identity management, HR system).
• the commercial value of a capability is primarily realised in a single division (e.g. PokerStars).
• 3rd party integrations, dependencies or relationships are optimised by centralised management (e.g. casino games).

Inner Source development is optimum when:

• high complexity makes the value of re-use high, and capability is strategically important for many divisions (e.g. betting platform).
• divisional priorities for a capability are naturally complementary (e.g. sports modelling – where US, UK, Australia and International all prioritise different sports).
• cross-divisional consensus is necessary for an effective capability (e.g. inter-divisional network).

Inner Source Pyramid

Inner source at Flutter is described as a pyramid with various stages. This reflects the reality that there is no single inner source operating model – it depends on the capability needs & teams. Similarly, Independent and Delegated patterns are families of operating models and the boundaries between the development patterns are blurred.

• Readable Source on the Inner Source Pyramid can be Independent or Delegated capabilities that value development transparency (e.g. for community learning) or plan to accept contributions in future.
• Any Inner Source capability can be copied (“forked”) and changed into a new Independent capability to accelerate start-up.
• Guest Contribution capabilities are owned by a divisional host team, and if contribution stops over time can become Delegated.
• Some Inner Source capabilities that accept cross-divisional contribution still Delegate to a single division for a single managed deployment.

Both the inner source pyramid and the 3 development patterns are a simplification: but they provide a powerful language with which to discuss, inform and make decisions about the best way forward within the group for a specific capability.