Scaling Internal Collaboration with Open Source Operating Models #InnerSourceSummit2025

Scaling Internal Collaboration with Open Source Operating Models #InnerSourceSummit2025 🔗 **Source:** [Scaling Internal Collaboration with Open Source Operating Models #InnerSourceSummit2025](https://www.youtube.com/watch?v=ggF3fIT5lh8) > [!note]+ Document Notes > tags: [innersource, collaboration, developer-experience] > author: InnerSource Summit > source: YouTube > reference: https://www.youtube.com/watch?v=ggF3fIT5lh8 > date created: 2025-01-12 19:30 > > # 🏷️ Title: Scaling Internal Collaboration with Open Source Operating Models >  ## 🧰 Action Inbox - [H1] Audit current projects for clear maintainer documentation — eliminate ownership ambiguity #governance - [H2] Establish review timeline SLAs and communicate expectations — reduce PR frustration #process - [H3] Implement project discovery system to prevent duplicated work — increase reuse metrics #visibility ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [InnerSource Commons](https://innersourcecommons.org/) - [Open Source Program Office](https://todogroup.org/) ## 📝 Summary - **What happened**: Developer advocate presents framework for scaling internal collaboration using open source operating models at InnerSource Summit Berlin - **Why it matters**: Organizations face duplicated work, unclear ownership, slow reviews, and limited visibility across teams - **Key stakeholders**: Engineering teams, solution engineers, OSPOs, and technical leadership - **Risks and tradeoffs**: Requires organizational commitment to process change and cultural shift from isolated to collaborative work - **Bottom line**: Apply proven open source practices internally through structured contribution paths, governance, and organization-wide principles ## 📖 Main Content The presentation addresses common collaboration challenges in software development that plague both internal teams and open source projects: unclear ownership, slow review cycles, duplicated work, and limited project visibility. The speaker uses examples from their payment company experience, noting how solution engineers across 27 global offices often build identical integration examples independently. **Core Framework Components:** 1. **Contribution Path Design**: Clear guidelines, heavy documentation, automation, and continuous improvement 2. **Governance Structure**: Clear maintainers, sustainability planning, decision records, and review timelines 3. **Scaling Principles**: Compliance (consistent structure), collaboration (discovery before building), and communication (transparent change management) The maturity model progresses from isolated work through emerging awareness, structured adoption, to full cultural transformation where collaboration becomes default behavior. **Measurement Strategy**: Track onboarding time, review turnaround, cross-team contributions, and reuse rates to demonstrate impact and secure leadership buy-in. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/ggF3fIT5lh8?t=0) — [H1] Introduction and speaker background - Key idea: Developer advocate at payment company with OSPO experience and community organizing background - Evidence: "Seven years in software development, open source advocate, past community organizer" #### ⏱️ [02:15](https://youtu.be/ggF3fIT5lh8?t=135) — [H2] Solution engineer duplication problem - Key idea: Global teams unknowingly build identical integration examples for similar customer use cases - Evidence: "At Adyen we have about 27 offices globally, probably amounts to several duplicated projects in laptops of solution engineers" #### ⏱️ [03:45](https://youtu.be/ggF3fIT5lh8?t=225) — [H2] Internal service integration frustrations - Key idea: Engineers struggle with undocumented internal services and unclear ownership - Evidence: "Find it very hard to know who owns the service, no documentation on how to integrate with LDAP APIs" #### ⏱️ [05:30](https://youtu.be/ggF3fIT5lh8?t=330) — [H1] Four common collaboration challenges - Key idea: Unclear ownership, slow reviews, duplicated work, and limited visibility plague internal development - Evidence: "Seven days before PR gets merged, can be so frustrating for engineers" #### ⏱️ [07:15](https://youtu.be/ggF3fIT5lh8?t=435) — [H2] Unstructured inner source still creates problems - Key idea: Simply making repositories internally visible doesn't solve collaboration issues without organization - Evidence: "Fragmented efforts, teams still build in silos, projects built in silos even if collaborating" #### ⏱️ [08:45](https://youtu.be/ggF3fIT5lh8?t=525) — [H1] Open source communities already solved these problems - Key idea: Standard open source practices provide proven models for internal collaboration - Evidence: "Open source community has solved this problem a while back, very standard community" #### ⏱️ [10:00](https://youtu.be/ggF3fIT5lh8?t=600) — [H1] Designing predictable contribution paths - Key idea: Clear guidelines, documentation, automation, and continuous improvement enable smooth contributions - Evidence: "Good policies look like they don't exist because everyone already understands them" #### ⏱️ [12:30](https://youtu.be/ggF3fIT5lh8?t=750) — [H2] Documentation requirements for every project - Key idea: Every internal project needs comprehensive documentation beyond basic README files - Evidence: "Several markdown files explaining architecture, contribution process, security structure implementation" #### ⏱️ [13:45](https://youtu.be/ggF3fIT5lh8?t=825) — [H2] Automation over manual processes - Key idea: Automate code quality, security checks, and compliance rather than manual reviews - Evidence: "Shouldn't have scenario where somebody physically checks code compliance, should be automated process" #### ⏱️ [15:15](https://youtu.be/ggF3fIT5lh8?t=915) — [H1] Governance through clear maintainers - Key idea: Document ownership clearly and plan for maintainer succession to prevent abandoned projects - Evidence: "Project should not die when owners leave, always someone else to reach out to" #### ⏱️ [16:30](https://youtu.be/ggF3fIT5lh8?t=990) — [H2] Decision records and review timelines - Key idea: Document all architectural decisions and set clear expectations for review cycles - Evidence: "From experience reviewing projects, you should tell users how long they wait before PR merged" #### ⏱️ [18:00](https://youtu.be/ggF3fIT5lh8?t=1080) — [H1] Three scaling principles from OSPO - Key idea: Compliance, collaboration, and communication enable organization-wide adoption - Evidence: "Make collaboration a principle so team members look at other projects before reinventing wheel" #### ⏱️ [20:00](https://youtu.be/ggF3fIT5lh8?t=1200) — [H2] Inner source maturity levels - Key idea: Organizations progress from isolated work through emerging adoption to cultural transformation - Evidence: "Goal should be getting from wherever you are to inner source culture where collaboration becomes default" #### ⏱️ [21:30](https://youtu.be/ggF3fIT5lh8?t=1290) — [H1] Measuring developer experience impact - Key idea: Track onboarding time, review turnaround, cross-team contributions, and reuse rates - Evidence: "How long does it take developer to pick up API and integrate? Measure before and after" #### ⏱️ [23:00](https://youtu.be/ggF3fIT5lh8?t=1380) — [H1] Key takeaways and starting point - Key idea: Design predictable paths, build lightweight governance, apply shared principles, and measure impact - Evidence: "Start from where you are and have vision to be inner source driven culture" ## 📚 References - [InnerSource Commons](https://innersourcecommons.org/) - [TODO Group OSPO Guide](https://todogroup.org/) - [Backstage Software Catalog](https://backstage.io/) ## 🗣️ Paraphrase - Organizations waste resources when teams unknowingly duplicate work across regions and departments due to poor project visibility and discovery mechanisms - Internal development suffers from the same collaboration problems as poorly managed open source projects: unclear ownership, slow feedback cycles, and fragmented efforts - Applying proven open source governance models internally—clear contribution paths, documented ownership, automated processes—transforms isolated work into collaborative culture ## 📰 Newsletter **Transform Internal Collaboration with Open Source Practices** Tired of teams building the same solutions in isolation? A compelling presentation from InnerSource Summit Berlin shows how to scale collaboration using proven open source operating models. The key insight: internal development faces identical challenges to poorly managed open source projects—unclear ownership, slow reviews, duplicated work, and limited visibility. The solution isn't just making repositories internally visible, but applying structured open source practices. **Three-Part Framework:** - **Contribution Paths**: Clear guidelines, comprehensive documentation, automated checks - **Governance**: Documented maintainers, decision records, review timelines - **Scaling Principles**: Organization-wide compliance, collaboration-first culture, transparent communication Track success through onboarding time, review turnaround, cross-team contributions, and reuse rates to demonstrate impact to leadership. Ready to move from building in silos to collaborative culture? Start where you are and apply these time-tested open source practices internally. Resources: [InnerSource Commons](https://innersourcecommons.org/), [OSPO Guide](https://todogroup.org/), [Backstage](https://backstage.io/) ## ✅ Action Items #### DevRel - Developer experience: Audit internal project documentation gaps, create contribution path templates - Education: Design workshops on inner source best practices, establish office hours for collaboration questions - Developer marketing: Create case studies showcasing successful cross-team collaborations and reuse metrics - Community management: Set up internal forums for project discovery, moderate cross-team collaboration discussions #### OSPO - Policy & Governance: Develop internal project compliance standards, create maintainer succession templates - Software Inventory: Implement project discovery platform, track cross-team dependencies and reuse rates - Developer Support: Provide inner source tooling training, create automated compliance checking tools - Strategic Alignment: Establish KPIs for collaboration culture, measure onboarding time and review turnaround improvements #### Community - Maintainers: Create ownership documentation standards, establish review timeline SLAs and succession planning - Contributors: Design onboarding paths for cross-team contributions, implement first-issue programs for internal projects - Ecosystem: Build project discovery mechanisms, coordinate cross-team integration standards #### WordPress - Core: Apply inner source principles to core contribution workflows, improve maintainer succession planning - Documentation: Audit DevHub and HelpHub for ownership clarity, establish review timeline expectations - Community: Create inner source best practices guides for meetup organizers and WordCamp contributors - Meta: Implement project discovery features on .org infrastructure, track cross-team collaboration metrics #### The WPCC - Programs: Design inner source fellowship programs, provide microgrants for cross-organization collaboration tools - Projects: Run governance clinics teaching inner source principles, fund documentation sprints for internal projects #### FAIR - Technical independence: Ensure inner source practices don't create vendor lock-in, maintain metadata portability - Governance artifacts: Create inner source policy templates, establish operator agreements for shared internal infrastructure ## 🧪 Hypotheses - Teams with clear maintainer documentation and review timelines will show measurably faster onboarding times compared to projects with unclear ownership - Organizations implementing automated compliance checking will see increased cross-team contribution rates within six months - Project discovery platforms will reduce duplicated work by 40% when combined with collaboration-first cultural principles - Inner source maturity progression correlates with improved developer satisfaction scores and reduced time-to-market metrics ### 📊 Methodology - Study design: Compare onboarding times, review turnaround, and cross-team contributions before/after inner source implementation across multiple organizations - Data sources: Git analytics, developer surveys, project metadata, and collaboration platform metrics - Experiments: A/B test different governance models and measure impact on reuse rates and developer experience ### ❓ Questions - How do we balance governance overhead with development velocity in fast-moving organizations? - What specific automation tools most effectively reduce manual review burden while maintaining code quality? - How can organizations measure and incentivize cultural transformation toward collaboration-first mindsets? ### 🔮 Future Research - Long-term impact studies on inner source adoption across different organizational sizes and cultures - Integration patterns between inner source practices and existing DevOps toolchains and CI/CD pipelines - Cross-industry comparison of inner source maturity models and their effectiveness in different business contexts ### 💡 Implications - **Practice**: Teams need structured approaches to transition from ad-hoc sharing to systematic inner source practices - **Policy**: Organizations require governance frameworks that enable rather than restrict internal collaboration - **Education**: Developer education must include collaboration skills and open source practices, not just technical implementation - **Funding**: Budget allocation should account for tooling, process development, and cultural change management in inner source initiatives ### 🧠 Learning Styles Assessment Reading level estimate: Flesch-Kincaid Grade Level 12 #### 👀 Visual learners - Present: Maturity level diagram, organizational structure examples - Improve: Process flow diagrams, before/after collaboration visualizations, governance structure charts #### 🔊 Aural learners - Present: Conference presentation format with clear verbal explanations - Improve: Audio summary of key frameworks, podcast-style discussion of implementation challenges #### 🗣️ Verbal learners - Present: Clear definitions of inner source terms, analogies to open source practices - Improve: Storytelling around transformation examples, comparison frameworks between traditional and inner source approaches #### 🧩 Kinesthetic learners - Present: Step-by-step implementation guidance, actionable takeaways - Improve: Hands-on workshops for governance setup, interactive maturity assessment tools, practical templates #### 🧠 Logical learners - Present: Structured three-part framework, clear progression through maturity levels - Improve: Decision trees for governance choices, metrics dashboards, cause-effect diagrams for collaboration challenges #### 🧑‍🤝‍🧑 Social learners - Present: Conference context with community discussion, cross-team collaboration examples - Improve: Peer learning cohorts for inner source adoption, community forums for sharing implementation experiences #### 🧘‍♀️ Solitary learners - Present: Self-assessment opportunities through maturity model, individual reflection prompts - Improve: Personal transformation workbooks, self-paced learning paths, private journaling exercises #### 🌿 Naturalistic learners - Present: Organizational ecosystem thinking, cultural transformation analogies - Improve: Systems thinking approach to collaboration, environmental impact of reduced duplicated work ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure in presentation slides, logical content flow - Improve: Alt text for diagrams, ARIA labels for interactive elements, descriptive link text #### Keyboard navigation - Present: Standard presentation navigation, logical tab order - Improve: Skip links for long content sections, keyboard shortcuts for framework navigation #### Contrast and readability - Present: Standard presentation contrast ratios - Improve: High-contrast mode options, adjustable text sizes for detailed framework content #### Text resizing and reflow - Present: Responsive design considerations - Improve: Text reflow at 200% zoom without horizontal scrolling, scalable diagram elements #### Media and captions - Present: Video presentation format - Improve: Complete transcript, audio descriptions for visual framework elements, downloadable materials #### Forms and interactions - Present: Basic interaction elements - Improve: Clear form labels for assessment tools, error handling for implementation checklists ### 🌍 DEIB Assessment #### Cultural breadth - Present: Global organization examples (27 offices), multi-region collaboration challenges - Improve: Diverse industry case studies, cultural considerations for governance models #### Inclusive language - Present: Gender-neutral technical terms, clear jargon definitions - Improve: Plain language alternatives for technical concepts, avoid culture-specific idioms #### Neurodiversity support - Present: Structured presentation format, clear section divisions - Improve --- ## Full Transcript [00:06] Hello everyone. Um, welcome to [00:10] Inosource Berlin and uh, today I'll be [00:13] speaking on scaling internal [00:16] collaboration with opensource operating [00:18] models. [00:20] Sorry, I think I got the clicker. [00:24] Yeah. [00:28] All [00:29] right. [00:38] Okay. All right. So, a little about me. [00:41] Um, [00:47] so I'm IODG. Um, I'm a developer [00:49] advocate at Ajin. um to endeavor and [00:53] open source program office and uh seven [00:57] years in software software development. [00:59] I've been an open source advocate for a [01:01] while and uh past community organizer at [01:04] uh KCD Amsterdam and also Google [01:07] developer groups uh WordPress meetups um [01:11] Polygon [01:13] and also I'm a proud proud dad of a [01:15] seven month old. [01:18] Yeah. So we're going to start uh quickly [01:22] by looking at the the common challenges [01:25] collaboration challenges in software [01:27] development. [01:28] Um so I'll start by maybe giving an [01:31] example. [01:33] How many of us here work as a solution [01:35] engineer or consultants? [01:38] A solution engineer. [01:40] Yeah. How many of us here are [01:42] developers? [01:45] Okay. Yeah. So um the first scenario a [01:49] sol solution engineer is attached to a [01:52] company to help them on board to the [01:54] platform. uh I work for a payment [01:56] company so I'll say to to help them [01:58] integrate their checkout or integrate [02:00] their payments but um so every customer [02:04] have different use case or sometimes [02:07] have similar use case in those uh in [02:11] those um collaboration the solution [02:14] engineer probably have to build [02:16] um an integration example for that [02:19] customer to show how their platform [02:22] works. [02:24] Now the customer gets gets on boarded [02:28] fine that's that's that's a success. So [02:30] im imagine the same um the same role [02:35] solution engineer for the same company [02:38] in another region [02:40] building the same type of application [02:42] for for similar use cases. Now multiply [02:46] this across several regions. At Adian we [02:49] have about 27 offices globally. [02:54] So this will probably amount to several [02:58] duplicated projects similar projects in [03:01] that lives in the laptop of of the [03:03] solution engineer. [03:06] Second scenario before I move to the [03:08] challenges [03:10] we're all engineers here and we probably [03:13] assigned to build several projects [03:14] internally. So imagine you were assigned [03:17] to build um an internal internal duty [03:21] roster that shows due uh duty time of of [03:26] um team team members and you have to [03:29] integrate with an internal service [03:31] probably like that helps you get the [03:34] LDAP of all your team members to display [03:37] on that page. You go to the you first of [03:40] all find it very hard to know who even [03:42] owns the service. You look around [03:44] internally, there is no documentation [03:46] anywhere to on how to integrate with the [03:48] LDAP service or even how to um integrate [03:51] with the APIs. You go to the [03:54] documentation page, nothing to write [03:56] home about, no ownership, no one to [03:59] reach out to. Okay, working with you [04:02] successfully integrate with the LDAP. Uh [04:05] and you found a bug, you opened a pull [04:08] request, it took seven days before it [04:11] gets merged. Now as an engineer this can [04:14] be so frustrating and [04:17] leading us to like [04:20] the common collaboration challenges in [04:22] software engineering. And the first one [04:24] is unclear ownership. [04:27] You see you land on the repo, you land [04:30] on a service but you're not sure who [04:32] wants the repo. You're not sure who to [04:34] reach out to. That's one challenge. Then [04:37] we have slow review. Of course, [04:41] most of us here have gone through the [04:42] same experience even working with open [04:45] source projects. [04:47] I've contributed to some open source [04:50] projects. Um, and probably took two two [04:54] years before I get the response from the [04:56] maintainer. So, it's a very it's a big [04:58] challenge in not just in open source but [05:01] also internally as well. You get MR open [05:04] for a while and no one to look at it or [05:06] it's taking a while to get it merged. [05:08] This can be frustrating. [05:11] We also have duplicated work. So imagine [05:14] the case of the solution engineer that [05:16] has you know that is building that [05:18] integration with the merchant but yeah [05:21] ends up building the same type of [05:23] integration over and over again because [05:26] there is no inventory. There's no [05:28] visibility on what projects even exist [05:31] or what has already been done by someone [05:33] else that you can build on top. And [05:36] these are the challenges not not unique [05:39] to inner source but also open source as [05:41] well. The last one is limited [05:44] visibility. [05:47] Lack of visibility to what is available, [05:50] lack of inventory of projects that have [05:54] been done. It would definitely make um [05:58] my life easy if I could just look at a [06:02] look at an inventory or maybe uh a back [06:05] backstage integration and see different [06:08] projects different owners and I'm able [06:10] to pick and get started with one project [06:13] build on top of it help merchants on [06:15] board or help customers on board even [06:18] faster [06:20] now like open source um inner source [06:23] starts with the intention to share and [06:25] collaborate. But yeah, when this is done [06:31] in an unstructured way, then it still [06:34] leads to the same problem. You have, you [06:37] know, fragmented efforts, teams still [06:40] build in silo. Even if you're [06:42] collaborating, you still have projects [06:45] that are built in silos. If you have a [06:48] good project with good documentation [06:50] without visibility, it's still the same [06:53] uh still the same problem because first [06:55] of all it needs to be discovered by [06:57] other teammates before you can uh before [06:59] they can even know how good the [07:01] documentation or how they can interact [07:03] with the with the service. [07:07] Now this is how [07:09] unstructured inner source looks like. [07:12] different files, different projects. [07:15] Although it's inner source, open source [07:18] internally, everybody can see it, but [07:21] still is still very unstructured and not [07:23] organized. [07:25] Now, we're going to look at open source. [07:28] Open source has open source community [07:30] has solved this problem a while back. If [07:33] you look at the very standard opensource [07:35] community, this problem is this is not a [07:38] problem because it's been solved [07:40] already. So, We're going to look at how [07:43] we can design and scale collaboration [07:47] using opensource models that are already [07:49] available. So of course because inner [07:52] source inner source is simply applying [07:55] opensource practices internally. So [07:58] we're going to look into that and with a [08:00] goal of moving from building in silos [08:04] practicing innerosource in silos to [08:07] inner source culture [08:11] let's look at the contribution part [08:13] which [08:15] I think is the first step [08:17] looking at how to um design a well um [08:22] predictable contribution path for uh for [08:25] the internet teams and the first part is [08:28] writing clear guidelines, writing clear [08:30] policies. Policies are not just about [08:34] um restricting access or restricting um [08:37] or designing roadblocks. [08:40] In fact, good policies, great policies, [08:44] great policies looks like they don't [08:45] exist because everyone already [08:47] understands them. If you have a policy [08:51] and your engineers still have to ask how [08:54] do we deploy, how do we then probably [08:56] you don't have a good policy. A good [08:58] policy should be understandable and very [09:02] predictable. [09:04] We have the documentation aspect. [09:08] Every projects make it um make it a [09:12] policy that every project should have [09:14] the proper documentation. [09:18] good readadme not just readme but how to [09:21] use it. If you go to a very standard [09:24] open source project you see several [09:26] markdown files explaining different [09:28] things about the projects including the [09:30] architecture of the project including [09:32] how to contribute including how you know [09:36] how the security uh structure of the [09:38] project is is is implemented. So be [09:42] heavy on documentation. [09:45] Making sure every project that lives in [09:47] your internal repo is well document is [09:49] well documented. [09:52] Now the third one is automation. [09:55] Now they are very we are several [09:58] organization that still have so many [10:00] manual process. [10:03] Try to automate things that can be [10:06] automated. [10:07] For instance, [10:09] once the contribution is is open, once a [10:12] MR is open, there should be a no is an [10:16] automation in place to check the [10:18] contribution to make sure not just the [10:21] not just it's been um to make sure it's [10:24] um it's properly done. You set up an [10:27] automation to check um the the code [10:30] itself, the code quality, to check the [10:33] security. So those should be automated [10:35] not just in open source but also also [10:37] internally. [10:39] You shouldn't have a scenario where [10:41] where somebody or somewhere has to come [10:44] and physically check or you know check [10:47] the code to see if it's if it's [10:49] compliant or not. This should be an [10:51] automated process and the next steps [10:54] should be like okay this is done we have [10:56] this report it's fully compliant then [10:59] let's merge then of course continuously [11:03] improve this process as we evolve there [11:07] will be [11:09] better and better ways to do automation [11:11] there will be better and better ways to [11:12] do documentation [11:14] continuously improve your process you [11:17] shouldn't have for instance a [11:19] documentation system that has been there [11:21] for 20 years. [11:24] Try to improve, try to advance to the uh [11:28] latest and better way of doing [11:30] documentation. [11:33] We have you know cases in my company we [11:36] have like documentation of se internal [11:39] documentation of several pages and this [11:42] documentation is built with a very old [11:44] stack PHP [11:46] and but yeah the good thing is that [11:50] we're looking into upgrading that that [11:53] documentation stack or even using a [11:56] third party to make sure the [11:57] documentation process is very very u [12:00] simple and updating the documentation is [12:02] very very um very straightforward. [12:05] So continuous improvement is very [12:08] important in the contribution part. [12:10] Now the next part which is also taken [12:14] from open source is governance. [12:19] Have clear maintainers. [12:21] Every project should have clear [12:23] documentation of who owns what, who owns [12:26] what service. If you if you have a [12:28] project that's that has you know uh that [12:31] has that is consuming other services [12:35] design a clear maintenal graph that [12:38] shows who owns what service and who to [12:41] reach out to in in you know and how to [12:44] reach out to them. We have several cases [12:47] of um [12:50] maintainers leaving the organization [12:53] and the project dies. [12:56] That shouldn't be the case. Declare, you [12:58] know, design the maintainer graphs uh [13:01] maintainer structure so as to enable [13:04] sustainability of the projects. A [13:07] project should not die when the owners [13:09] go. Let's make sure it's properly um [13:14] structured in a way that once anyone [13:17] leaves there is also there's always [13:19] someone else to reach out to and there [13:21] was also there is always a continuous [13:24] process for the projects so it doesn't [13:26] become an abandoned project. This also [13:28] affects open source. We see open source [13:31] projects that the maintainers probably [13:33] decide to stop maintaining the project [13:36] and the project dies. That shouldn't be [13:39] the case for your internal project. [13:43] Then we have decision record. [13:46] Make sure every decision you take for [13:49] your project is properly recorded. [13:53] In in my company we call it any decision [13:55] record. In most company they call it [13:58] architectural decision record. Make sure [14:02] the service that people rely on, [14:05] make sure it has decision records, [14:09] you don't just um [14:12] change the APIs or change how it's [14:14] implemented. Everything should be [14:16] properly recorded so that anyone [14:18] depending on the project knows the [14:20] timeline of the project, knows the the [14:23] road map of the projects. Then review [14:25] timeline. Make sure you have review [14:29] timelines. So you set an expectation [14:34] from your experience reviewing the code. [14:36] From from your experience reviewing the [14:38] project and approving PR, you should be [14:40] able to tell this on average this is how [14:42] long you could you could wait before [14:44] your your project your PR is merged. [14:47] Make this known to the user as well. [14:51] Now now that we have the governance in [14:54] place, we have the contribution path. [14:57] Let's look at how we can scale it in the [14:59] organization. [15:01] So we have three principles we can [15:02] borrow from the open source opensource [15:04] program office. In some companies you [15:06] already have a a standard open source [15:09] program office. While in some companies, [15:11] okay, you still your practice inner [15:12] source without an open source program [15:14] office. Fine. But these three principles [15:16] still stands with or without open source [15:19] program office. And this is compliance. [15:21] Compliance here is not just about it's [15:22] not about um license. Compliance is [15:26] making sure [15:28] um every project internally follows the [15:31] same structure. So it's not just a team [15:33] effort. It becomes an organizationwide [15:36] effort. So make it a program internally [15:39] that every project is compliant and [15:42] communicate this properly. And also [15:45] collaboration. Make collaboration one of [15:47] your principles. [15:49] So that team members know that by [15:52] default [15:53] they should look at other project. They [15:55] should look at what is is what's what's [15:57] in existence before reinventing the [16:00] wheel. There's always some project there [16:03] somebody has built that has solved the [16:05] same issue that you want to build. Let [16:08] there be a way to collaborate. Let there [16:10] be a way to discover this. And most some [16:12] companies do this by you know building a [16:15] very structured metadata platforms in [16:18] backstage or platforms that are used [16:20] internally. Then also communication is [16:23] very important [16:26] making it a principle to always um [16:29] communicate your changes. So this ties [16:32] down to what we looked at in the uh [16:34] decision record. So these three [16:36] principles helps you to also scale um [16:40] your inner source your collaboration [16:42] internally. [16:45] We look at uh the let's quickly look at [16:48] the inner source maturity level in case [16:49] you're trying to know okay where am I as [16:51] a company where am I as an organization [16:53] and how are these opensource operating [16:55] models moving the collaboration from [16:57] isolated to cultural [16:59] we look at this [17:02] now this is adapted from the inner [17:04] source commons [17:06] the first of course stage is where [17:08] everything is isolated that is where we [17:10] have zero inner source culture where we [17:12] have zero collaboration culture then we [17:14] have the emerging you already know that [17:16] there's inner source you're already u [17:18] somebody in your team already suggested [17:20] okay let's practice inner source and [17:22] probably one or two repos have been made [17:24] open to everyone documentation are being [17:27] worked on this is the adoption phase [17:29] then we have the structured phase where [17:32] one or two teams are practicing [17:34] innerosource [17:36] very well and they have they you know [17:40] they have a a good example of how what [17:43] an inner practice should look like. Then [17:46] of course the fourth one is when [17:49] Innosource is scaled across your [17:52] organization. Innosource becomes a [17:55] culture. Collaboration becomes a [17:57] culture. By default, engineers look at [18:00] ways to collaborate more in the [18:02] organization. [18:03] So your goal should be from getting from [18:06] wherever you are in this stage to the [18:09] inner source culture. [18:13] How do we measure impact [18:15] on deep devx? [18:18] You know, we talk about inner source and [18:20] if we want to probably tell the [18:23] leadership, let's do innerosource, but [18:25] how do we measure impact? How do you [18:27] know these collaboration efforts are [18:28] working? [18:32] One of them is onboarding time. [18:35] If you look at a project, how long will [18:37] it take a developer to pick up that [18:39] service or pick up that project or pick [18:41] up that API and interact with the API or [18:44] integrate with the API. How long does it [18:46] take? You measure before and after. This [18:49] should show some metrics that your inner [18:51] source is working. Then review [18:53] turnaround. How long does it take for [18:55] PRs to get merged? [18:59] Then we have cross team contributions. [19:03] How many contributions in your projects [19:05] are coming in in projects are coming [19:07] from other teams. [19:09] So this is also another uh metrics and [19:12] also reuse rates. How many um part of a [19:17] project is reused or is part of another [19:22] service. [19:24] Look at all the projects and look at how [19:27] many pieces are they and how many are [19:29] coming from different projects. How many [19:30] are coming from different teams. [19:33] I believe this should increase when [19:35] inner sauceource or this should change [19:37] when innerource is prop is practiced [19:39] properly [19:42] then yeah let's look at the quick [19:44] takeaways of this talk and one of them [19:47] is design predictable [19:49] predictable parts contribution parts [19:52] build lightweight governance that builds [19:54] trust apply orwide shared principles for [19:58] consistency and flow and of course [20:00] measure the impact always measure the [20:03] impact because this is where you're able [20:05] to convince leadership that what you're [20:08] doing is working. [20:11] Where do you start? Start from where you [20:13] are and have the vision to be an [20:18] innocriven [20:20] culture. [20:23] Thank you.  ## 📺 Video ![](https://www.youtube.com/watch?v=ggF3fIT5lh8) --- # 📝 Full Notes (Deep-Read Analysis) # 🏷️ Title: Scaling Internal Collaboration with Open Source Operating Models ## 🧰 Action Inbox - [H1] Audit current projects for clear maintainer documentation — eliminate ownership ambiguity #governance - [H2] Establish review timeline SLAs and communicate expectations — reduce PR frustration #process - [H3] Implement project discovery system to prevent duplicated work — increase reuse metrics #visibility ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [InnerSource Commons](https://innersourcecommons.org/) - [Open Source Program Office](https://todogroup.org/) ## 📝 Summary - **What happened**: Developer advocate presents framework for scaling internal collaboration using open source operating models at InnerSource Summit Berlin - **Why it matters**: Organizations face duplicated work, unclear ownership, slow reviews, and limited visibility across teams - **Key stakeholders**: Engineering teams, solution engineers, OSPOs, and technical leadership - **Risks and tradeoffs**: Requires organizational commitment to process change and cultural shift from isolated to collaborative work - **Bottom line**: Apply proven open source practices internally through structured contribution paths, governance, and organization-wide principles ## 📖 Main Content The presentation addresses common collaboration challenges in software development that plague both internal teams and open source projects: unclear ownership, slow review cycles, duplicated work, and limited project visibility. The speaker uses examples from their payment company experience, noting how solution engineers across 27 global offices often build identical integration examples independently. **Core Framework Components:** 1. **Contribution Path Design**: Clear guidelines, heavy documentation, automation, and continuous improvement 2. **Governance Structure**: Clear maintainers, sustainability planning, decision records, and review timelines 3. **Scaling Principles**: Compliance (consistent structure), collaboration (discovery before building), and communication (transparent change management) The maturity model progresses from isolated work through emerging awareness, structured adoption, to full cultural transformation where collaboration becomes default behavior. **Measurement Strategy**: Track onboarding time, review turnaround, cross-team contributions, and reuse rates to demonstrate impact and secure leadership buy-in. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/ggF3fIT5lh8?t=0) — [H1] Introduction and speaker background - Key idea: Developer advocate at payment company with OSPO experience and community organizing background - Evidence: "Seven years in software development, open source advocate, past community organizer" #### ⏱️ [02:15](https://youtu.be/ggF3fIT5lh8?t=135) — [H2] Solution engineer duplication problem - Key idea: Global teams unknowingly build identical integration examples for similar customer use cases - Evidence: "At Adyen we have about 27 offices globally, probably amounts to several duplicated projects in laptops of solution engineers" #### ⏱️ [03:45](https://youtu.be/ggF3fIT5lh8?t=225) — [H2] Internal service integration frustrations - Key idea: Engineers struggle with undocumented internal services and unclear ownership - Evidence: "Find it very hard to know who owns the service, no documentation on how to integrate with LDAP APIs" #### ⏱️ [05:30](https://youtu.be/ggF3fIT5lh8?t=330) — [H1] Four common collaboration challenges - Key idea: Unclear ownership, slow reviews, duplicated work, and limited visibility plague internal development - Evidence: "Seven days before PR gets merged, can be so frustrating for engineers" #### ⏱️ [07:15](https://youtu.be/ggF3fIT5lh8?t=435) — [H2] Unstructured inner source still creates problems - Key idea: Simply making repositories internally visible doesn't solve collaboration issues without organization - Evidence: "Fragmented efforts, teams still build in silos, projects built in silos even if collaborating" #### ⏱️ [08:45](https://youtu.be/ggF3fIT5lh8?t=525) — [H1] Open source communities already solved these problems - Key idea: Standard open source practices provide proven models for internal collaboration - Evidence: "Open source community has solved this problem a while back, very standard community" #### ⏱️ [10:00](https://youtu.be/ggF3fIT5lh8?t=600) — [H1] Designing predictable contribution paths - Key idea: Clear guidelines, documentation, automation, and continuous improvement enable smooth contributions - Evidence: "Good policies look like they don't exist because everyone already understands them" #### ⏱️ [12:30](https://youtu.be/ggF3fIT5lh8?t=750) — [H2] Documentation requirements for every project - Key idea: Every internal project needs comprehensive documentation beyond basic README files - Evidence: "Several markdown files explaining architecture, contribution process, security structure implementation" #### ⏱️ [13:45](https://youtu.be/ggF3fIT5lh8?t=825) — [H2] Automation over manual processes - Key idea: Automate code quality, security checks, and compliance rather than manual reviews - Evidence: "Shouldn't have scenario where somebody physically checks code compliance, should be automated process" #### ⏱️ [15:15](https://youtu.be/ggF3fIT5lh8?t=915) — [H1] Governance through clear maintainers - Key idea: Document ownership clearly and plan for maintainer succession to prevent abandoned projects - Evidence: "Project should not die when owners leave, always someone else to reach out to" #### ⏱️ [16:30](https://youtu.be/ggF3fIT5lh8?t=990) — [H2] Decision records and review timelines - Key idea: Document all architectural decisions and set clear expectations for review cycles - Evidence: "From experience reviewing projects, you should tell users how long they wait before PR merged" #### ⏱️ [18:00](https://youtu.be/ggF3fIT5lh8?t=1080) — [H1] Three scaling principles from OSPO - Key idea: Compliance, collaboration, and communication enable organization-wide adoption - Evidence: "Make collaboration a principle so team members look at other projects before reinventing wheel" #### ⏱️ [20:00](https://youtu.be/ggF3fIT5lh8?t=1200) — [H2] Inner source maturity levels - Key idea: Organizations progress from isolated work through emerging adoption to cultural transformation - Evidence: "Goal should be getting from wherever you are to inner source culture where collaboration becomes default" #### ⏱️ [21:30](https://youtu.be/ggF3fIT5lh8?t=1290) — [H1] Measuring developer experience impact - Key idea: Track onboarding time, review turnaround, cross-team contributions, and reuse rates - Evidence: "How long does it take developer to pick up API and integrate? Measure before and after" #### ⏱️ [23:00](https://youtu.be/ggF3fIT5lh8?t=1380) — [H1] Key takeaways and starting point - Key idea: Design predictable paths, build lightweight governance, apply shared principles, and measure impact - Evidence: "Start from where you are and have vision to be inner source driven culture" ## 📚 References - [InnerSource Commons](https://innersourcecommons.org/) - [TODO Group OSPO Guide](https://todogroup.org/) - [Backstage Software Catalog](https://backstage.io/) ## 🗣️ Paraphrase - Organizations waste resources when teams unknowingly duplicate work across regions and departments due to poor project visibility and discovery mechanisms - Internal development suffers from the same collaboration problems as poorly managed open source projects: unclear ownership, slow feedback cycles, and fragmented efforts - Applying proven open source governance models internally—clear contribution paths, documented ownership, automated processes—transforms isolated work into collaborative culture ## 📰 Newsletter **Transform Internal Collaboration with Open Source Practices** Tired of teams building the same solutions in isolation? A compelling presentation from InnerSource Summit Berlin shows how to scale collaboration using proven open source operating models. The key insight: internal development faces identical challenges to poorly managed open source projects—unclear ownership, slow reviews, duplicated work, and limited visibility. The solution isn't just making repositories internally visible, but applying structured open source practices. **Three-Part Framework:** - **Contribution Paths**: Clear guidelines, comprehensive documentation, automated checks - **Governance**: Documented maintainers, decision records, review timelines - **Scaling Principles**: Organization-wide compliance, collaboration-first culture, transparent communication Track success through onboarding time, review turnaround, cross-team contributions, and reuse rates to demonstrate impact to leadership. Ready to move from building in silos to collaborative culture? Start where you are and apply these time-tested open source practices internally. Resources: [InnerSource Commons](https://innersourcecommons.org/), [OSPO Guide](https://todogroup.org/), [Backstage](https://backstage.io/) ## ✅ Action Items #### DevRel - Developer experience: Audit internal project documentation gaps, create contribution path templates - Education: Design workshops on inner source best practices, establish office hours for collaboration questions - Developer marketing: Create case studies showcasing successful cross-team collaborations and reuse metrics - Community management: Set up internal forums for project discovery, moderate cross-team collaboration discussions #### OSPO - Policy & Governance: Develop internal project compliance standards, create maintainer succession templates - Software Inventory: Implement project discovery platform, track cross-team dependencies and reuse rates - Developer Support: Provide inner source tooling training, create automated compliance checking tools - Strategic Alignment: Establish KPIs for collaboration culture, measure onboarding time and review turnaround improvements #### Community - Maintainers: Create ownership documentation standards, establish review timeline SLAs and succession planning - Contributors: Design onboarding paths for cross-team contributions, implement first-issue programs for internal projects - Ecosystem: Build project discovery mechanisms, coordinate cross-team integration standards #### WordPress - Core: Apply inner source principles to core contribution workflows, improve maintainer succession planning - Documentation: Audit DevHub and HelpHub for ownership clarity, establish review timeline expectations - Community: Create inner source best practices guides for meetup organizers and WordCamp contributors - Meta: Implement project discovery features on .org infrastructure, track cross-team collaboration metrics #### The WPCC - Programs: Design inner source fellowship programs, provide microgrants for cross-organization collaboration tools - Projects: Run governance clinics teaching inner source principles, fund documentation sprints for internal projects #### FAIR - Technical independence: Ensure inner source practices don't create vendor lock-in, maintain metadata portability - Governance artifacts: Create inner source policy templates, establish operator agreements for shared internal infrastructure ## 🧪 Hypotheses - Teams with clear maintainer documentation and review timelines will show measurably faster onboarding times compared to projects with unclear ownership - Organizations implementing automated compliance checking will see increased cross-team contribution rates within six months - Project discovery platforms will reduce duplicated work by 40% when combined with collaboration-first cultural principles - Inner source maturity progression correlates with improved developer satisfaction scores and reduced time-to-market metrics ### 📊 Methodology - Study design: Compare onboarding times, review turnaround, and cross-team contributions before/after inner source implementation across multiple organizations - Data sources: Git analytics, developer surveys, project metadata, and collaboration platform metrics - Experiments: A/B test different governance models and measure impact on reuse rates and developer experience ### ❓ Questions - How do we balance governance overhead with development velocity in fast-moving organizations? - What specific automation tools most effectively reduce manual review burden while maintaining code quality? - How can organizations measure and incentivize cultural transformation toward collaboration-first mindsets? ### 🔮 Future Research - Long-term impact studies on inner source adoption across different organizational sizes and cultures - Integration patterns between inner source practices and existing DevOps toolchains and CI/CD pipelines - Cross-industry comparison of inner source maturity models and their effectiveness in different business contexts ### 💡 Implications - **Practice**: Teams need structured approaches to transition from ad-hoc sharing to systematic inner source practices - **Policy**: Organizations require governance frameworks that enable rather than restrict internal collaboration - **Education**: Developer education must include collaboration skills and open source practices, not just technical implementation - **Funding**: Budget allocation should account for tooling, process development, and cultural change management in inner source initiatives ### 🧠 Learning Styles Assessment Reading level estimate: Flesch-Kincaid Grade Level 12 #### 👀 Visual learners - Present: Maturity level diagram, organizational structure examples - Improve: Process flow diagrams, before/after collaboration visualizations, governance structure charts #### 🔊 Aural learners - Present: Conference presentation format with clear verbal explanations - Improve: Audio summary of key frameworks, podcast-style discussion of implementation challenges #### 🗣️ Verbal learners - Present: Clear definitions of inner source terms, analogies to open source practices - Improve: Storytelling around transformation examples, comparison frameworks between traditional and inner source approaches #### 🧩 Kinesthetic learners - Present: Step-by-step implementation guidance, actionable takeaways - Improve: Hands-on workshops for governance setup, interactive maturity assessment tools, practical templates #### 🧠 Logical learners - Present: Structured three-part framework, clear progression through maturity levels - Improve: Decision trees for governance choices, metrics dashboards, cause-effect diagrams for collaboration challenges #### 🧑‍🤝‍🧑 Social learners - Present: Conference context with community discussion, cross-team collaboration examples - Improve: Peer learning cohorts for inner source adoption, community forums for sharing implementation experiences #### 🧘‍♀️ Solitary learners - Present: Self-assessment opportunities through maturity model, individual reflection prompts - Improve: Personal transformation workbooks, self-paced learning paths, private journaling exercises #### 🌿 Naturalistic learners - Present: Organizational ecosystem thinking, cultural transformation analogies - Improve: Systems thinking approach to collaboration, environmental impact of reduced duplicated work ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure in presentation slides, logical content flow - Improve: Alt text for diagrams, ARIA labels for interactive elements, descriptive link text #### Keyboard navigation - Present: Standard presentation navigation, logical tab order - Improve: Skip links for long content sections, keyboard shortcuts for framework navigation #### Contrast and readability - Present: Standard presentation contrast ratios - Improve: High-contrast mode options, adjustable text sizes for detailed framework content #### Text resizing and reflow - Present: Responsive design considerations - Improve: Text reflow at 200% zoom without horizontal scrolling, scalable diagram elements #### Media and captions - Present: Video presentation format - Improve: Complete transcript, audio descriptions for visual framework elements, downloadable materials #### Forms and interactions - Present: Basic interaction elements - Improve: Clear form labels for assessment tools, error handling for implementation checklists ### 🌍 DEIB Assessment #### Cultural breadth - Present: Global organization examples (27 offices), multi-region collaboration challenges - Improve: Diverse industry case studies, cultural considerations for governance models #### Inclusive language - Present: Gender-neutral technical terms, clear jargon definitions - Improve: Plain language alternatives for technical concepts, avoid culture-specific idioms #### Neurodiversity support - Present: Structured presentation format, clear section divisions - Improve --- # 📄 Full Transcript *Auto-generated from YouTube captions · timestamps roughly every 30 seconds · [watch on YouTube](https://www.youtube.com/watch?v=ggF3fIT5lh8)* **[00:06]** Hello everyone. Um, welcome to Inosource Berlin and uh, today I'll be speaking on scaling internal collaboration with opensource operating models. Sorry, I think I got the clicker. Yeah. All right. **[00:38]** Okay. All right. So, a little about me. Um, so I'm IODG. Um, I'm a developer advocate at Ajin. um to endeavor and open source program office and uh seven years in software software development. I've been an open source advocate for a while and uh past community organizer at uh KCD Amsterdam and also Google developer groups uh WordPress meetups um **[01:11]** Polygon and also I'm a proud proud dad of a seven month old. Yeah. So we're going to start uh quickly by looking at the the common challenges collaboration challenges in software development. Um so I'll start by maybe giving an example. How many of us here work as a solution engineer or consultants? A solution engineer. Yeah. How many of us here are **[01:42]** developers? Okay. Yeah. So um the first scenario a sol solution engineer is attached to a company to help them on board to the platform. uh I work for a payment company so I'll say to to help them integrate their checkout or integrate their payments but um so every customer have different use case or sometimes have similar use case in those uh in those um collaboration the solution **[02:14]** engineer probably have to build um an integration example for that customer to show how their platform works. Now the customer gets gets on boarded fine that's that's that's a success. So im imagine the same um the same role solution engineer for the same company in another region building the same type of application for for similar use cases. Now multiply **[02:46]** this across several regions. At Adian we have about 27 offices globally. So this will probably amount to several duplicated projects similar projects in that lives in the laptop of of the solution engineer. Second scenario before I move to the challenges we're all engineers here and we probably assigned to build several projects internally. So imagine you were assigned **[03:17]** to build um an internal internal duty roster that shows due uh duty time of of um team team members and you have to integrate with an internal service probably like that helps you get the LDAP of all your team members to display on that page. You go to the you first of all find it very hard to know who even owns the service. You look around internally, there is no documentation anywhere to on how to integrate with the **[03:48]** LDAP service or even how to um integrate with the APIs. You go to the documentation page, nothing to write home about, no ownership, no one to reach out to. Okay, working with you successfully integrate with the LDAP. Uh and you found a bug, you opened a pull request, it took seven days before it gets merged. Now as an engineer this can be so frustrating and leading us to like **[04:20]** the common collaboration challenges in software engineering. And the first one is unclear ownership. You see you land on the repo, you land on a service but you're not sure who wants the repo. You're not sure who to reach out to. That's one challenge. Then we have slow review. Of course, most of us here have gone through the same experience even working with open source projects. I've contributed to some open source projects. Um, and probably took two two **[04:54]** years before I get the response from the maintainer. So, it's a very it's a big challenge in not just in open source but also internally as well. You get MR open for a while and no one to look at it or it's taking a while to get it merged. This can be frustrating. We also have duplicated work. So imagine the case of the solution engineer that has you know that is building that integration with the merchant but yeah ends up building the same type of integration over and over again because **[05:26]** there is no inventory. There's no visibility on what projects even exist or what has already been done by someone else that you can build on top. And these are the challenges not not unique to inner source but also open source as well. The last one is limited visibility. Lack of visibility to what is available, lack of inventory of projects that have been done. It would definitely make um **[05:58]** my life easy if I could just look at a look at an inventory or maybe uh a back backstage integration and see different projects different owners and I'm able to pick and get started with one project build on top of it help merchants on board or help customers on board even faster now like open source um inner source starts with the intention to share and collaborate. But yeah, when this is done **[06:31]** in an unstructured way, then it still leads to the same problem. You have, you know, fragmented efforts, teams still build in silo. Even if you're collaborating, you still have projects that are built in silos. If you have a good project with good documentation without visibility, it's still the same uh still the same problem because first of all it needs to be discovered by other teammates before you can uh before they can even know how good the **[07:01]** documentation or how they can interact with the with the service. Now this is how unstructured inner source looks like. different files, different projects. Although it's inner source, open source internally, everybody can see it, but still is still very unstructured and not organized. Now, we're going to look at open source. Open source has open source community has solved this problem a while back. If **[07:33]** you look at the very standard opensource community, this problem is this is not a problem because it's been solved already. So, We're going to look at how we can design and scale collaboration using opensource models that are already available. So of course because inner source inner source is simply applying opensource practices internally. So we're going to look into that and with a goal of moving from building in silos **[08:04]** practicing innerosource in silos to inner source culture let's look at the contribution part which I think is the first step looking at how to um design a well um predictable contribution path for uh for the internet teams and the first part is writing clear guidelines, writing clear policies. Policies are not just about **[08:34]** um restricting access or restricting um or designing roadblocks. In fact, good policies, great policies, great policies looks like they don't exist because everyone already understands them. If you have a policy and your engineers still have to ask how do we deploy, how do we then probably you don't have a good policy. A good policy should be understandable and very predictable. **[09:04]** We have the documentation aspect. Every projects make it um make it a policy that every project should have the proper documentation. good readadme not just readme but how to use it. If you go to a very standard open source project you see several markdown files explaining different things about the projects including the architecture of the project including how to contribute including how you know **[09:36]** how the security uh structure of the project is is is implemented. So be heavy on documentation. Making sure every project that lives in your internal repo is well document is well documented. Now the third one is automation. Now they are very we are several organization that still have so many manual process. Try to automate things that can be automated. **[10:07]** For instance, once the contribution is is open, once a MR is open, there should be a no is an automation in place to check the contribution to make sure not just the not just it's been um to make sure it's um it's properly done. You set up an automation to check um the the code itself, the code quality, to check the security. So those should be automated not just in open source but also also internally. **[10:39]** You shouldn't have a scenario where where somebody or somewhere has to come and physically check or you know check the code to see if it's if it's compliant or not. This should be an automated process and the next steps should be like okay this is done we have this report it's fully compliant then let's merge then of course continuously improve this process as we evolve there will be better and better ways to do automation **[11:11]** there will be better and better ways to do documentation continuously improve your process you shouldn't have for instance a documentation system that has been there for 20 years. Try to improve, try to advance to the uh latest and better way of doing documentation. We have you know cases in my company we have like documentation of se internal documentation of several pages and this **[11:42]** documentation is built with a very old stack PHP and but yeah the good thing is that we're looking into upgrading that that documentation stack or even using a third party to make sure the documentation process is very very u simple and updating the documentation is very very um very straightforward. So continuous improvement is very important in the contribution part. Now the next part which is also taken **[12:14]** from open source is governance. Have clear maintainers. Every project should have clear documentation of who owns what, who owns what service. If you if you have a project that's that has you know uh that has that is consuming other services design a clear maintenal graph that shows who owns what service and who to reach out to in in you know and how to **[12:44]** reach out to them. We have several cases of um maintainers leaving the organization and the project dies. That shouldn't be the case. Declare, you know, design the maintainer graphs uh maintainer structure so as to enable sustainability of the projects. A project should not die when the owners go. Let's make sure it's properly um structured in a way that once anyone **[13:17]** leaves there is also there's always someone else to reach out to and there was also there is always a continuous process for the projects so it doesn't become an abandoned project. This also affects open source. We see open source projects that the maintainers probably decide to stop maintaining the project and the project dies. That shouldn't be the case for your internal project. Then we have decision record. Make sure every decision you take for **[13:49]** your project is properly recorded. In in my company we call it any decision record. In most company they call it architectural decision record. Make sure the service that people rely on, make sure it has decision records, you don't just um change the APIs or change how it's implemented. Everything should be properly recorded so that anyone depending on the project knows the **[14:20]** timeline of the project, knows the the road map of the projects. Then review timeline. Make sure you have review timelines. So you set an expectation from your experience reviewing the code. From from your experience reviewing the project and approving PR, you should be able to tell this on average this is how long you could you could wait before your your project your PR is merged. Make this known to the user as well. **[14:51]** Now now that we have the governance in place, we have the contribution path. Let's look at how we can scale it in the organization. So we have three principles we can borrow from the open source opensource program office. In some companies you already have a a standard open source program office. While in some companies, okay, you still your practice inner source without an open source program office. Fine. But these three principles still stands with or without open source program office. And this is compliance. Compliance here is not just about it's **[15:22]** not about um license. Compliance is making sure um every project internally follows the same structure. So it's not just a team effort. It becomes an organizationwide effort. So make it a program internally that every project is compliant and communicate this properly. And also collaboration. Make collaboration one of your principles. So that team members know that by default **[15:53]** they should look at other project. They should look at what is is what's what's in existence before reinventing the wheel. There's always some project there somebody has built that has solved the same issue that you want to build. Let there be a way to collaborate. Let there be a way to discover this. And most some companies do this by you know building a very structured metadata platforms in backstage or platforms that are used internally. Then also communication is very important **[16:26]** making it a principle to always um communicate your changes. So this ties down to what we looked at in the uh decision record. So these three principles helps you to also scale um your inner source your collaboration internally. We look at uh the let's quickly look at the inner source maturity level in case you're trying to know okay where am I as a company where am I as an organization and how are these opensource operating models moving the collaboration from **[16:57]** isolated to cultural we look at this now this is adapted from the inner source commons the first of course stage is where everything is isolated that is where we have zero inner source culture where we have zero collaboration culture then we have the emerging you already know that there's inner source you're already u somebody in your team already suggested okay let's practice inner source and probably one or two repos have been made open to everyone documentation are being worked on this is the adoption phase **[17:29]** then we have the structured phase where one or two teams are practicing innerosource very well and they have they you know they have a a good example of how what an inner practice should look like. Then of course the fourth one is when Innosource is scaled across your organization. Innosource becomes a culture. Collaboration becomes a culture. By default, engineers look at **[18:00]** ways to collaborate more in the organization. So your goal should be from getting from wherever you are in this stage to the inner source culture. How do we measure impact on deep devx? You know, we talk about inner source and if we want to probably tell the leadership, let's do innerosource, but how do we measure impact? How do you know these collaboration efforts are working? **[18:32]** One of them is onboarding time. If you look at a project, how long will it take a developer to pick up that service or pick up that project or pick up that API and interact with the API or integrate with the API. How long does it take? You measure before and after. This should show some metrics that your inner source is working. Then review turnaround. How long does it take for PRs to get merged? Then we have cross team contributions. **[19:03]** How many contributions in your projects are coming in in projects are coming from other teams. So this is also another uh metrics and also reuse rates. How many um part of a project is reused or is part of another service. Look at all the projects and look at how many pieces are they and how many are coming from different projects. How many are coming from different teams. **[19:33]** I believe this should increase when inner sauceource or this should change when innerource is prop is practiced properly then yeah let's look at the quick takeaways of this talk and one of them is design predictable predictable parts contribution parts build lightweight governance that builds trust apply orwide shared principles for consistency and flow and of course measure the impact always measure the impact because this is where you're able **[20:05]** to convince leadership that what you're doing is working. Where do you start? Start from where you are and have the vision to be an innocriven culture. Thank you.