Practice : InnerSource Development

Purpose and Strategic Importance

InnerSource Development applies open source principles within an organisation. It encourages internal teams to share, collaborate, and contribute across boundaries - fostering transparency, reuse, and innovation.

By treating internal projects as discoverable and contributable assets, InnerSource breaks down silos, improves code quality, and accelerates development by leveraging internal expertise. It empowers teams to solve problems collaboratively and responsibly.

Description of the Practice

  • Internal projects are developed in a transparent, open, and collaborative manner.
  • Teams document contribution guidelines, review practices, and project roadmaps.
  • Contributions are welcomed from other teams, with maintainers guiding and reviewing.
  • Discoverability is key - using searchable repositories, tags, and internal documentation hubs.
  • Popularised by large-scale engineering organisations (e.g. PayPal, Microsoft, Bloomberg).

How to Practise It (Playbook)

1. Getting Started

  • Identify candidate projects that could benefit from broader contributions.
  • Publish the code in an accessible internal repository with clear README and contributing guide.
  • Set expectations for issue triage, PR reviews, and communication norms.
  • Start with a champion or sponsor team to lead adoption and maintain quality.

2. Scaling and Maturing

  • Create an internal portal or catalogue of InnerSource projects.
  • Use tags to indicate readiness for contribution (e.g. “good first issue”, “help wanted”).
  • Standardise InnerSource documentation templates and maintainership models.
  • Recognise contributors across teams and support cross-functional collaboration.
  • Embed InnerSource goals into platform, API, and shared tooling strategies.

3. Team Behaviours to Encourage

  • Embrace openness and responsiveness - feedback loops should be clear and timely.
  • Treat other teams as customers and co-creators.
  • Review contributions with the same care and empathy as open source communities.
  • Share learnings, decisions, and roadmaps openly.

4. Watch Out For…

  • Gatekeeping or slow review processes that discourage contribution.
  • Poor documentation that makes it hard for others to engage.
  • Ownership confusion - clarify who maintains what and how decisions are made.
  • Burnout in teams overwhelmed by unmanaged community requests.

5. Signals of Success

  • Contributions come from a diverse set of internal teams.
  • Useful modules, components, and patterns are reused across domains.
  • Engineers feel empowered to improve shared tooling and platforms.
  • InnerSource becomes a default mindset for shared assets.
  • Organisational velocity improves through reuse, transparency, and trust.