InnerSource
Open-source collaboration practices applied inside an organisation.
6 to work through
-
intermediate
An organisation adopts an innersource model so teams can contribute to each other's services. It mostly does not happen. What conditions does innersource require?
2 min answer -
intermediate
An organisation has published an innersource contribution guide, opened every internal repository, and added a company goal for cross-team contributions. Six months in there have been eleven contributions across 200 repositories. Review the programme.
3 min answer -
intermediate
An organisation wants shared internal libraries and services to be improvable by any team. What conditions make innersource work, and when does it fail?
2 min answer -
intermediate
An organisation wants shared internal libraries maintained collaboratively across teams. What must be true for innersource to work, and when does it fail?
2 min answer -
intermediate
Team A is blocked for three weeks waiting on a small change from Team B. What are the options and what does each cost?
2 min answer -
advanced
You maintain an internal library used by 60 teams. Your team of five also owns two products. Two teams have each opened a pull request adding something you do not want in the library - one a caching layer with its own configuration surface, the other a second serialisation format. Both teams are blocked on the outcome and both say innersource means they can contribute. Walk me through how you run this.
3 min answer
2 terms in this topic
InnerSource
Applying open-source collaboration practices inside an organisation, so teams can contribute to code they do not own instead of waiting for it.
practiceInnerSource Contribution Contract
The published statement of what a shared internal component accepts what it refuses and how fast it will answer - which makes a maintainer's "no" fas…
Neighbouring topics
Enterprise Architecture
General material on architecture at portfolio and estate scale.
EA Domains
Business, application, data and technology architecture as viewpoints.
Application Architecture
The application estate as a designed portfolio rather than an accumulation.
Technology Architecture
Platforms, runtimes and infrastructure standards across the estate.
Capability Maps in EA
The stable frame for hanging investment, ownership and health off.
Application Portfolio Management
Inventory, ownership, cost and health for every application.
Application Rationalisation
Retire, consolidate, replatform — and why retirement is under-applied.
Technology Standards
Guidance that teams follow because it helps, not because it is mandated.
Technology Radar
Adopt, trial, assess and hold — with movement, dates and owners.
Reference Architectures
Pre-approved templates for recurring solution shapes.
Architecture Governance
Preventive, automated controls rather than review meetings.
Architecture Review Boards
Thresholds, early engagement and a real route to accept deviation.
Enterprise Integration
Estate-wide integration strategy, standards and shared infrastructure.
TOGAF
The ADM as a checklist, tailored rather than followed literally.
EA Frameworks
Zachman, FEAF and others — vocabulary rather than method.
Architecture Roadmaps
Sequencing change across an estate with dependencies and funding.
Paved Roads
Making the supported path the easiest path, with a way to leave it.
Platform Teams
Reducing other teams' cognitive load, measured by adoption.
EA Metrics
Measuring whether architecture work changed anything.