How do internal open source program offices help organizations capture and share knowledge across software teams?

Host: Welcome to A.I.S. Insights — powered by Living Knowledge. I’m Anna Ivy Summers.

Expert: And I’m Alex Ian Sutherland. Today we are looking at a study presented at the 2026 International Conference on Information Systems, titled "Beyond Shared Code: The Role of InnerSource Program Offices in Organizational Knowledge Production." The study is authored by Clare Dillon, Lorraine Morgan, and Daniel Izquierdo-Cortázar.

Host: The study examines InnerSource—the practice of applying open source software development methods inside an organization—and specifically explores how InnerSource Program Offices, or ISPOs, help create and sustain organizational knowledge.

Expert: That addresses a persistent operational problem in software development. Much of what an organization knows about its technical systems remains tacit. Architecture rationale, rejected alternatives, and operational context are rarely written down. When engineers switch projects or leave the firm, that knowledge departs with them, leading other teams to duplicate effort.

Host: While InnerSource aims to fix this by making internal projects open and readable across the firm, how did the authors investigate the actual mechanisms at play?

Expert: They applied a qualitative, exploratory design grounded in Activity Theory and the concept of knotworking. Their evidence comes from five sources: interviews with ISPO practitioners across ten organizations in North America and Europe, group interviews with members of Microsoft’s DevOps Dojo, the published Dojo case study, data from an online survey of one hundred and nineteen practitioners, and community materials from the InnerSource Commons.

Host: What were the main findings that emerged from that data?

Expert: First, InnerSource activity is directed toward a dual object: shared code and shared organizational knowledge. The asynchronous practices required for cross-team contributions—such as written contribution guidelines, issue discussions, and pull request reviews—naturally convert tacit context into explicit, searchable assets.

Host: But the authors note that maintaining this collaborative work across boundaries is fragile. Why is that?

Expert: Because cross-boundary collaboration happens through what the study terms "knots"—transient, episodic encounters where actors from separate teams briefly align around a specific pull request or issue. Once the contribution is merged, the knot dissolves and engineers return to their primary delivery tasks. Nothing in an individual team's routine guarantees another knot will form.

Host: In addition, there appears to be a disconnect between leadership and practitioners regarding the value of InnerSource.

Expert: Yes, the study identifies a structural contradiction. Executive leadership typically justifies InnerSource based on efficiency metrics like code reuse and reduced duplication. However, practitioners participate primarily for learning, relationship-building, and personal growth. When delivery schedules become tight, activities like mentoring external contributors and documenting rationale are often treated as discretionary overhead and deprioritized.

Host: That is where the InnerSource Program Office enters the picture. How do these offices address that friction?

Expert: The authors developed a typology of four ISPO roles based on Activity Theory. First is "creating coherence," standardizing tooling, templates, and guidance so artifacts remain legible across teams. Second is "connecting," building internal communities and cross-team visibility so engineers know where to contribute. Third is "translating," reframing rules between developer practices and corporate functions like legal, security, and executive management. Fourth is "advising," providing coaching and project support within specific teams.

Host: How can business and technology leaders apply these insights in practice?

Expert: First, leaders should measure learning and knowledge outcomes alongside code reuse. Tracking captured context, contributor progression, and skill acquisition makes InnerSource defensible during budget discussions. Second, organizations should design support for transient collaboration rather than assuming permanent team structures. This includes lightweight onboarding and near-peer mentorship models to avoid overburdening senior maintainers. Finally, organizations need to resource ISPOs deliberately as knowledge infrastructure, rather than treating their coordination effort as invisible labor.

Host: InnerSource produces lasting organizational knowledge, but sustaining it requires intentional coordination across boundaries. Alex, thank you for sharing these insights.

Expert: You are welcome, Anna.

Host: And thank you to our listeners. Join us next time on A.I.S. Insights — powered by Living Knowledge.