Oscar Lobaton Salas – Building Bridges Scaling InnerSource #InnerSourceSummit2025

Oscar Lobaton Salas – Building Bridges: Scaling InnerSource #InnerSourceSummit2025 🔗 **Source:** [Oscar Lobaton Salas – Building Bridges: Scaling InnerSource #InnerSourceSummit2025](https://www.youtube.com/watch?v=Bxy4xZATIew) > [!note]+ Document Notes > tags: [innersource, enterprise-architecture, collaboration] > author: Oscar Lobaton Salas > source: InnerSource Commons > reference: https://www.youtube.com/watch?v=Bxy4xZATIew > date created: 2025-01-12 14:30 > > # 🏷️ Title: Oscar Lobaton Salas – Building Bridges: Scaling InnerSource #InnerSourceSummit2025 >  ## 🧰 Action Inbox - [H1] Establish operational independence framework — maintain company autonomy while enabling collaboration #governance - [H2] Implement technology standardization — GitHub stack, CI/CD, security tooling #infrastructure - [H3] Create repository generator with compliance — automated policy-compliant repositories #automation ## 🧭 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 Patterns](https://patterns.innersourcecommons.org/) - [GitHub Enterprise Documentation](https://docs.github.com/en/enterprise-cloud@latest) ## 📝 Summary - Crédito, Peru's largest financial holding with 7,000+ developers across 15 companies, successfully implemented InnerSource to eliminate duplicate work and enable cross-company collaboration - Four key enablers: operational independence, technology standardization (GitHub stack), C-level sponsorship, and cultural change from company-centric to group-centric mindset - Technical solution centers on Crédito acting as intermediary broker with dedicated InnerSource organization, repository generator, and automated workflows for cross-instance collaboration - Solved GitHub's private instance forking limitations through clone-based workflow with automated synchronization and customization capabilities - Bottom line: Large enterprise groups can scale InnerSource through centralized governance while maintaining subsidiary independence ## 📖 Main Content Crédito transformed from a fragmented group of 15 financial companies into a collaborative ecosystem using InnerSource patterns. The organization recognized that despite having over 7,000 developers, companies were duplicating work and creating isolated solutions for common problems. The implementation strategy focused on four critical enablers. Operational independence ensures each company maintains autonomy while participating in group collaboration. Technology standardization on GitHub Enterprise Cloud, GitHub Actions, and security tooling creates a unified platform. C-level sponsorship provides necessary resources and organizational support. Cultural transformation shifts mindset from company-centric to group-centric thinking. The technical architecture positions Crédito as a central broker facilitating collaboration between subsidiaries. Each company maintains its own GitHub instance while accessing shared resources through the central InnerSource organization. This addresses the challenge of cross-company collaboration without forcing complete integration. A sophisticated repository management system includes automated generators that create policy-compliant repositories with built-in security, CI/CD workflows, and governance files. The system supports two collaboration models: open projects where any trusted committer can approve pull requests, and project-specific models requiring designated team owner approval. The solution tackles GitHub's limitation around private instance forking through an innovative clone-based approach. Companies can automatically clone repositories, maintain synchronization with origins, and create customized forks while preserving the ability to receive upstream updates. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/Bxy4xZATIew?t=0) — [H1] Introduction and Context - Key idea: Crédito is Peru's largest financial holding with 7,000+ developers across 15 companies - Evidence: "We operate in about six countries and have 15 companies in the group with a strong technology potential" #### ⏱️ [02:15](https://youtu.be/Bxy4xZATIew?t=135) — [H2] Problem Identification - Key idea: Despite large developer community, companies had no collaboration and duplicated work - Evidence: "There was almost no collaborations between companies. We were duplicating work and creating different solutions for the same problems" #### ⏱️ [03:30](https://youtu.be/Bxy4xZATIew?t=210) — [H1] Four Key Enablers - Key idea: Four critical enablers enable InnerSource adoption while reducing conflicts - Evidence: "We identify four of these enablers... operational independence, technology standardization, executive sponsorship, and cultural change" #### ⏱️ [04:00](https://youtu.be/Bxy4xZATIew?t=240) — [H2] Operational Independence - Key idea: Companies must maintain autonomy to preserve innovation capability - Evidence: "Each company needs operational independence... preserve its ability to innovate its ability to choose its path" #### ⏱️ [05:15](https://youtu.be/Bxy4xZATIew?t=315) — [H2] Technology Standardization - Key idea: Unified technology stack essential for collaboration across companies - Evidence: "All companies use the same stack today we are almost 100% on GitHub... This standardization allow us to share and collaborate easier" #### ⏱️ [06:30](https://youtu.be/Bxy4xZATIew?t=390) — [H2] Executive Sponsorship - Key idea: C-level support crucial for demonstrating operational and economic benefits - Evidence: "Sea level support... leaders show the benefits of the operational and economic of inner source" #### ⏱️ [07:45](https://youtu.be/Bxy4xZATIew?t=465) — [H2] Cultural Change Challenges - Key idea: Most mature companies resist sharing due to company-centric mindset - Evidence: "The most mature companies... sharing wasn't easy... it feel like others will benefit from the work" #### ⏱️ [09:00](https://youtu.be/Bxy4xZATIew?t=540) — [H1] Technical Architecture Overview - Key idea: Focus on three main assets: people, code, and processes across companies - Evidence: "We focus in three main assets people that release hook interact with the system. The code is the primary technical assets and process" #### ⏱️ [10:30](https://youtu.be/Bxy4xZATIew?t=630) — [H1] Crédito as Central Broker - Key idea: Crédito acts as intermediary enabling multi-company collaboration - Evidence: "Credit come in the center... acting as an intermediary where the group companies can collaborate and exchange" #### ⏱️ [12:00](https://youtu.be/Bxy4xZATIew?t=720) — [H2] Team Structure and Governance - Key idea: Collaborator teams organized by company origin and domain knowledge - Evidence: "Collaborators who access a credit are trusted... Not all 7,000 developers are admitted for now only through those who start owing their capabilities" #### ⏱️ [14:15](https://youtu.be/Bxy4xZATIew?t=855) — [H2] Repository Properties and Models - Key idea: Two InnerSource models - open project and project-specific approval - Evidence: "Open project where an interest commit can approve P request... project specific model... exist a specific team that approves" #### ⏱️ [16:30](https://youtu.be/Bxy4xZATIew?t=990) — [H2] Repository Generator - Key idea: Self-service generator creates policy-compliant repositories from templates - Evidence: "Generator Create a policy compliance repositories from a template with a standard rhythm security contributing" #### ⏱️ [18:00](https://youtu.be/Bxy4xZATIew?t=1080) — [H2] Repository Elevation Process - Key idea: Automated workflow transforms private repositories to InnerSource projects - Evidence: "Repository that was pre-based is inner source project anyone contribute anyone can work with all rules" #### ⏱️ [20:45](https://youtu.be/Bxy4xZATIew?t=1245) — [H1] Cross-Instance Forking Solution - Key idea: GitHub doesn't support direct forks across private instances, solved with cloning - Evidence: "GitHub doesn't support direct force across private instances... create a clone" #### ⏱️ [23:30](https://youtu.be/Bxy4xZATIew?t=1410) — [H2] Synchronization Workflow - Key idea: Single workflow file maintains synchronization and handles conflicts - Evidence: "Single workflow file... runs in three ways manually schedule request opens... pull changes from repository to the clone" #### ⏱️ [25:00](https://youtu.be/Bxy4xZATIew?t=1500) — [H2] Customization Through Forking - Key idea: Companies create forks from clones to enable customization while maintaining sync - Evidence: "The fork can pull up from the clone without losing its customizations. This emulate across company fork" ## 📚 References - [InnerSource Commons Patterns](https://patterns.innersourcecommons.org/) - [GitHub Enterprise Cloud Multi-organization Management](https://docs.github.com/en/enterprise-cloud@latest/organizations) - [Crédito Group Corporate Information](https://www.credito.com.pe/) ## 🗣️ Paraphrase - Large financial holding company eliminated duplicate development work by implementing InnerSource across 15 subsidiary companies using central broker model - Four foundational elements enabled successful adoption: maintaining company autonomy, standardizing on unified technology platform, securing leadership support, and shifting from siloed to collaborative culture - Technical solution overcame GitHub's private instance limitations through automated cloning workflows that enable both synchronization and customization across company boundaries ## 📰 Newsletter **Scaling InnerSource Across Enterprise Holdings: Lessons from Peru's Largest Financial Group** Crédito's transformation from fragmented subsidiaries to collaborative ecosystem offers valuable lessons for large organizations considering InnerSource adoption. With over 7,000 developers across 15 companies, they successfully eliminated duplicate work while preserving operational independence. **Key Implementation Insights:** - **Centralized Broker Model**: Position one entity as collaboration hub rather than forcing direct company-to-company integration - **Technology Standardization**: Unified GitHub Enterprise platform essential for seamless collaboration - **Automated Compliance**: Repository generators ensure policy adherence while enabling self-service creation **Practical Applications:** Organizations can adapt this pattern by identifying natural collaboration brokers within their structure and implementing automated workflows for cross-boundary code sharing. **Technical Innovation:** The clone-based forking solution elegantly solves GitHub's private instance limitations, enabling both synchronization and customization across enterprise boundaries. Resources: [InnerSource Patterns](https://patterns.innersourcecommons.org/), [Enterprise GitHub Management](https://docs.github.com/en/enterprise-cloud@latest), [InnerSource Commons](https://innersourcecommons.org/) ## ✅ Action Items #### DevRel - Developer education: Create workshops on cross-company collaboration patterns and InnerSource adoption strategies - Developer experience: Document GitHub Enterprise multi-organization workflows and automated repository management - Community management: Establish InnerSource champion networks and contribution recognition programs #### OSPO - Policy & Governance: Develop InnerSource contribution policies and cross-subsidiary collaboration frameworks - Software Inventory: Implement automated discovery and cataloging of reusable internal components - Developer Support: Create self-service tools for repository generation and compliance automation - Community Engagement: Design incentive structures for cross-organizational knowledge sharing #### Community - Maintainers: Establish trusted committer programs and domain-specific governance models - Contributors: Create onboarding pathways for cross-company collaboration and skill development - Ecosystem: Develop metrics and KPIs for measuring collaboration effectiveness and duplicate work reduction #### WordPress - Core: Apply lessons to WordPress.org multi-project coordination and contributor governance - Community: Adapt broker model for connecting different WordPress community segments - Meta: Implement automated compliance tools for .org repository management and quality standards #### The WPCC - Programs: Design cross-organization collaboration frameworks for WordPress ecosystem participants - Projects: Create self-service tools for compliant project creation and governance automation #### FAIR - Technical independence: Develop patterns for maintaining project autonomy while enabling ecosystem collaboration - Governance artifacts: Create templates for multi-stakeholder governance and decision-making processes ## 🧪 Hypotheses - Organizations with centralized broker entities can achieve higher InnerSource adoption rates than those attempting direct peer-to-peer collaboration models - Technology platform standardization is a necessary prerequisite for successful large-scale InnerSource implementation across subsidiary organizations - Automated compliance and repository generation tools reduce friction and increase adoption rates for internal collaboration platforms - Companies that maintain operational independence while participating in group collaboration show higher long-term engagement than those with forced integration ### 📊 Methodology - Survey enterprise organizations implementing InnerSource to compare broker vs. peer-to-peer collaboration models and measure adoption rates, contribution frequency, and long-term sustainability - Analyze correlation between technology platform diversity and collaboration success metrics across multi-subsidiary organizations - A/B test automated vs. manual repository setup processes measuring time-to-first-contribution and compliance adherence rates ### ❓ Questions - How can organizations identify the optimal entity to serve as collaboration broker when multiple candidates exist within corporate structure? - What specific governance patterns work best for balancing subsidiary autonomy with group-level collaboration requirements? - How do organizations measure and demonstrate ROI from reduced duplicate work and increased cross-company collaboration? ### 🔮 Future Research - Comparative analysis of different InnerSource broker models across various industry sectors and organizational structures - Development of automated metrics for detecting and quantifying duplicate work elimination in large enterprise settings - Investigation of cultural transformation patterns and change management strategies for shifting from company-centric to collaborative mindsets ### 💡 Implications - Practice: Large organizations need structured broker models rather than ad-hoc collaboration approaches for successful InnerSource scaling - Policy: Legal and compliance frameworks must accommodate cross-subsidiary code sharing while maintaining operational independence - Security: Automated compliance tools become critical infrastructure for maintaining security standards across collaborative boundaries - Education: Developer training programs must include cross-organizational collaboration skills and InnerSource pattern knowledge - Funding: Budget models need mechanisms for shared investment in collaborative infrastructure and common tooling platforms ### 🧠 Learning Styles Assessment Reading level estimate: 12th grade (technical business content with specialized vocabulary) #### 👀 Visual learners - Present: Organizational diagrams showing broker model and company relationships - Improve: Technical architecture diagrams, workflow visualizations, GitHub organization structure charts #### 🔊 Aural learners - Present: Conference presentation with speaker narration and explanations - Improve: Podcast-style case study discussion, recorded implementation walkthroughs #### 🗣️ Verbal learners - Present: Clear definitions of InnerSource patterns, technical terminology, and process explanations - Improve: Glossary of enterprise collaboration terms, comparison with open source analogies #### 🧩 Kinesthetic learners - Present: Step-by-step repository creation and elevation processes - Improve: Hands-on GitHub Enterprise lab exercises, implementation checklists, sandbox environments #### 🧠 Logical learners - Present: Clear problem-solution framework, numbered enablers, structured implementation phases - Improve: Decision trees for model selection, ROI calculation frameworks, metrics dashboards #### 🧑‍🤝‍🧑 Social learners - Present: Community presentation format, collaborative ecosystem focus - Improve: Implementation team workshops, cross-company collaboration exercises, champion networks #### 🧘‍♀️ Solitary learners - Present: Self-service tooling emphasis, individual contributor pathways - Improve: Self-assessment rubrics, independent study guides, personal reflection prompts #### 🌿 Naturalistic learners - Present: Ecosystem metaphors, organic collaboration growth patterns - Improve: Organizational evolution analogies, sustainable collaboration practices ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading hierarchy, structured presentation format - Improve: Alt text for organizational diagrams, descriptive link text, proper heading levels #### Keyboard navigation - Present: Standard video player controls and navigation - Improve: Transcript navigation, searchable content, keyboard shortcuts #### Contrast and readability - Present: Clear slide presentation with adequate contrast - Improve: High-contrast --- ## Full Transcript [00:06] I am from I work as a tcopes architect [00:09] cror I'm also a research collaborator I [00:11] am the ambassador [00:13] um maybe the most important thing that [00:17] why I am talking today is that I am the [00:20] person who has lead the technical [00:22] um [00:24] technical development technical adoption [00:26] of inner source at credit um I am [00:28] looking for this uh for this talk is [00:31] about the technical path we build as [00:33] support or in strategy throughout uh the [00:36] talk. Um I would like to show you which [00:40] inner source patterns we implemented uh [00:43] which is the problem which is the [00:45] challenges that we having during this [00:47] process. During the presentations I will [00:49] see or you will see in the top right of [00:53] the corner of the slides the inner [00:55] source patterns that we implemented [00:56] during the all the slides probably uh we [01:00] have many in the source patterns I will [01:02] try to explain a little quickly for time [01:05] but I hope this presentation will useful [01:08] for all people so let's start with the [01:11] context similar like a well pro we we [01:13] can start with the with the context and [01:16] the first question that probably you are [01:19] thinking is what is credit? Credit is uh [01:22] the or is the largest financial holding [01:25] in Peru. We operate in [01:28] about the six countries and have 15 [01:32] companies in the group with a strong [01:33] technology potential. Uh across them we [01:36] have more than 7,000 developers or [01:39] contributors in in the companies. But uh [01:43] some time ago we noticed that even [01:46] though we are a big group, we have a [01:48] strong tech community but we're [01:53] there was almost no collaborations [01:55] between companies. We were duplicating [01:57] work and creating different solutions [01:59] for the same problems. Um I heard the [02:03] previous talk is just coming about that [02:06] there are it's a it's crucial to [02:09] understand that there are many duplicate [02:12] assets many duplicate source code it's [02:14] not good in terms of economical [02:16] efficiency. So all of this landscape is [02:20] was or was the problem for credit we [02:23] decide to build a collaborate ecosystem. [02:26] We knew the goal but not the patent at [02:29] that time. So in this point like group [02:33] like company we took inner source both [02:36] theory and practice to build a highway [02:39] connecting companies and changing the [02:42] landscape. [02:43] I would like to highlight the problem [02:45] and the talk try to show how we solve [02:49] this problem to connecting different [02:51] companies. Before the diving into [02:54] technical adoption, let me share the [02:56] enablers the the ones we use to [02:59] implement inner source while reducing [03:02] conflicts, reducing problems and ensure [03:05] that all [03:08] companies can contribute um can exchange [03:13] informations [03:15] and in simple words we identify four of [03:19] these enablers. Let me start with the [03:24] operational independence. Yeah, although [03:26] we want a strong clo a strong close [03:31] uh very collaboration first one we need [03:34] to have to accept that each company [03:37] needs operational independence. Why? [03:40] Because the companies needs to preserve [03:43] its ability to innovate its ability to [03:47] uh choose its path and as group we [03:50] realize that it wasn't about connecting [03:52] everything. It's not about the okay we [03:54] manage all companies we manage all [03:57] process all mechanisms but about a [03:59] middle ground a meeting point where the [04:02] companies can share exchange and [04:05] collaborate. This is the the one [04:08] neighbor probably it sounds simple some [04:10] very basic but for us was important to [04:15] understand this neighbor with this [04:18] neighbor we can talk the second one [04:20] technology standardization collaboration [04:22] is difficult when [04:24] have different technologies different [04:26] platforms we so that all companies use [04:30] the same stack today we are almost 100% [04:33] on GitHub corporation culture we use [04:36] github action for CI/CD and most of the [04:38] companies is using a GitHub advanced [04:41] security like application security [04:44] testing. This standardization allow us [04:46] to share and collaborate easier. [04:49] Obviously because we have the same [04:51] stack, we have the same platform will be [04:53] very difficult. If one company have [04:56] GitLab, another company will have or has [05:00] GitHub, another one bit. It's very [05:03] complicated to maintain on [05:06] ecosystem. So this was crucial for us. [05:10] And the third one u it's about the [05:14] execute execute the sponsorship the key [05:16] neighbor is the sea level support [05:20] unfortunately our sea levels or leaders [05:24] show or s the benefits of the [05:27] operational and economic of inner source [05:30] for example operationally a stronger [05:32] development muscle um shore [05:37] collaborations [05:38] it's very Good. If you want to grow, if [05:43] you want to create new things and in the [05:47] economic point, reduce the [05:49] implementation time, reduce development [05:51] time, uh better manage your budgets [05:54] because you can use you can reduce you [05:57] can share information. It's more easy to [06:00] or it's easier to create uh new products [06:03] or h have [06:06] new solutions not from a scratch. [06:09] uh using uh another product. We're using [06:12] the bases that use another company. This [06:14] start as a small project. We need to [06:17] show a pilot to build a trusted [06:21] trust and demonstrate the results of [06:24] inner source. But all things was both [06:28] the sponsorship was great during the [06:30] process. Now this point [06:34] it's important to understand the last [06:36] one good change the future comes first [06:40] at pore this was difficult the most [06:43] mature company sharing was sharing [06:47] or how do you say that the most mature [06:49] companies usually are not agree or [06:52] agreement with the with the sharing [06:55] sharing wasn't easy and the bing wasn't [06:57] clear because the it feel like others [07:02] will benefit from the work. So there are [07:06] there were a lot of thinking and mindset [07:09] to company centric one. So we need to [07:14] work hard for webinars, sessions, [07:16] leaderships, conversations, execute [07:18] support obviously and by identifying [07:21] champions willing to collaborate to go [07:24] and collaborate mindset thinking of the [07:27] group not just a single company. [07:30] We create um exchange, we create a [07:34] mindset where we can [07:38] identify common requirements and in this [07:41] way continue with the work, continue [07:44] with the with the plan the inner source [07:47] adoptions. [07:48] These foreign neighbors allow us to to [07:50] begin our inner source adoption. I think [07:54] at this part it's it's or I will try to [07:57] show you which is the context which [07:59] things we need to access to implement [08:02] inner source and I would like to go [08:05] directly to the technical [08:06] implementations uh I will try to show in [08:11] like a overview that what things we [08:13] implemented how works the the exchange [08:17] of information because across the all [08:19] companies we focus in three main assets [08:21] people [08:23] that release hook interact with the [08:26] system. The code is the primary [08:28] technical assets and process. [08:31] As I mentioned before the mainly problem [08:34] is connect is sharing as well each [08:39] company has its own needs and road [08:42] because there is dependency. each [08:45] company have his own [08:49] GitHub. [08:51] Um this happens or [08:55] this was really difficult to manage [08:58] because each company um interact with [09:02] other but in one way or two ways but [09:04] usually it's pointtooint onetoone [09:07] interaction. There isn't no central [09:11] place for multi company collaboration. [09:14] This is the problem to have a mechanisms [09:17] to share and collaborate. And in this [09:19] way I would like to introduce [09:22] uh credit. I mentioned before credit [09:25] card is a group of companies but credit [09:28] is a company as well and in this context [09:32] the credit come in the the center or the [09:37] middle of the companies being a credit [09:39] as a 16 company acting as an [09:41] intermediary where the group come where [09:45] the group companies can collaborate and [09:47] exchange granting a compliant secure and [09:50] the scalable ecosystem with quality [09:52] process [09:58] uh for better understanding I I I think [10:01] it's it's the best way to understand how [10:04] this works we can look at the case that [10:06] consider the interaction between company [10:09] A in the group and company B which [10:12] represents credit acting as a broker [10:15] obviously company A could be C D F or [10:19] any letter any company it's only for the [10:22] representations [10:23] But in the example or in the case we [10:27] need to think a developer in company A [10:30] wants to access the source code in [10:33] company B. Each company A B C D or some [10:38] has own GitHub instance as I mentioned [10:40] before. The objective on this case is [10:44] show how we implement the workflow so [10:47] that company A can retrive source source [10:51] code from company B even if that code [10:55] was previously pushed by another company [10:57] it's possible another company can push [10:59] the code before and of course co company [11:02] A can collaborate with credit because [11:05] it's not only [11:08] one directions we we need to to ways I I [11:13] can retrieve and I need to collaborate. [11:15] So uh first one how does uh the inner [11:20] source ecosystem work inside credit this [11:22] company B let's start there [11:25] within [11:27] B github instance we have a dedicated [11:30] inner source organizations where the [11:32] governance is uh so I will begin with [11:36] teams uh we define uh first one the [11:40] collaborator teams whose members is [11:43] belong to two logical groups first the [11:46] company of origin. It's a logical [11:49] grouping but allow us to identify which [11:52] company is the contributor. Another [11:56] segregation is by domain of knowledge. A [11:58] functional vertical for permissions and [12:01] access is not just a developer. We have [12:04] um also architects, data scientists, AI [12:07] engineers etc. This le let us to know [12:12] which company the collaborator belongs [12:14] to and which domain they work in. In [12:17] addition, [12:18] uh collaborators who access a credit are [12:22] trusted by us from each company. Not all [12:27] 7,000 developers are admitted for now [12:30] only through those who start owing their [12:33] capabilities. Obviously [12:36] all developers can contribute inside of [12:40] his company inside of his instance and [12:44] send the changes uh through uh through [12:46] committer to organization the credit [12:49] card that is the inner source matrix. [12:53] We have two roles or two teams work that [12:56] inner source admin and project team [12:58] owners. Projecting owner is a logical [13:00] label to identify projects that require [13:03] or require a stronger change governance [13:06] or require more mechanisms in order to [13:08] approve the changes and inner source [13:10] admin is is key because inner source [13:13] admin ensure at the governance level [13:16] that each domain operates operates well. [13:20] Think of them as a dedicated community [13:22] leads responsible for applying the the [13:27] group's inner source practices [13:29] responsible for ensure the practice [13:31] ensure the the flow. This is the [13:34] objective inner source admin. [13:38] We continue with the properties. The [13:40] properties is like a taxi GitHub to [13:43] identify projects. We define a [13:45] technology like a stack to know which is [13:47] the technology. Then we categorize the [13:49] projects as documentations, automations [13:52] and libraries. We record the team owner [13:56] to know which is the team owner if it [13:59] exists. Not all projects require the [14:03] same openness. We define um two times of [14:07] model of inner source. The infresh proof [14:10] model is a open project where an [14:12] interest committ can approve P request. [14:14] It's totally similar open source are [14:16] open are anyone can contribute but in a [14:21] different way [14:24] u in the project specific model it's [14:27] open obviously anyone can contribute as [14:30] well but exist a specific team that [14:32] approves p request which team the [14:35] project team owner in this way we have [14:38] two [14:40] cases we have two ways to manage the [14:44] inner source model and we also store the [14:48] outdoor as a governance property to know [14:51] which company originate the project we [14:54] know that which company have the product [14:58] as part of the implementation we build [14:59] self services in order to support the [15:01] flexibility [15:03] uh we have a self services for variables [15:05] for access manager for generator [15:07] obviously we don't have enough time to [15:10] um to cover all of this But I would like [15:14] to double click about the repository [15:17] generator. It's part of the repository [15:19] management capacity generator. Create a [15:22] policy compliance repositories from a [15:25] template with a standard rhythm security [15:27] contributing a code to conduct all [15:29] repository BS with these files. Um it [15:32] includes the CI/CD [15:35] and code owner files to centerize the [15:38] releases and deployments with semantic [15:40] portioning and it's marked when a [15:43] project is released and reusable by [15:45] another companies. [15:48] Finally, it also includes our inner [15:51] source listens obviously is to address a [15:55] leg of concerns align with the pattern [15:58] that is on the screen that it's very [16:00] useful to maintain the property inside [16:03] of the group. Um we have a one more file [16:07] that I will mention in deep short way [16:11] but it's very important because it's [16:14] maintain the compliance and the con [16:16] system of the repository that is the [16:18] same repository. [16:22] Additionally repos come uh come with [16:26] build breakers. We have advanced [16:28] security configuration rule set approver [16:31] the version control model all practices [16:33] that develops can apply to ensure that [16:36] development will be secure and have the [16:40] enough quality [16:42] was implemented with this default and [16:45] sell services. Any any collaborator can [16:48] create a repositories align with our [16:50] strategy and in GitHub we enable that [16:53] also issues discussions and projects in [16:57] line with ensuring the price [16:58] transparency and keep piece is our [17:01] knowledge center knowledge center [17:05] it's like [snorts] [17:06] portal it's a documentation portal for [17:08] us we use [17:12] as a doc code um there you will find for [17:16] inner source or how inner source works [17:18] in credit or practices or objectives [17:21] principles and guiding principles inside [17:24] of this portal. [17:27] Also in the portal we are transparent [17:30] with the government governance how we [17:33] govern with the inner source ad means [17:35] which is the the flow all things that we [17:38] have inside of this portal is to show [17:42] the governance to show the guidelines is [17:44] totally transparent and it's important [17:46] to say that that this h [17:50] this portal is a inner project as well. [17:53] So anyone can contribute, anyone can can [17:56] make feedback, anyone can change [17:58] obviously with the approves [18:01] with approves of any or of a member or [18:04] inner source admin depends a lot of the [18:06] code owners. It also uh serves as an [18:09] inner source portal with a catalog that [18:11] helps teams discover projects to [18:13] contribute or reuse based on properties [18:16] mentioned in early. uh you can search [18:19] directly in the portal and you can find [18:21] the breaks if you want to find it. [18:27] No uh let me quickly walk you through [18:30] how repository becomes inner source at [18:32] carore. I I I remember in the previous [18:36] talks mentioned about it it's a big [18:38] problem to managing organizations. We [18:40] solve with this flow. First one it start [18:43] when a root collaborators create a new [18:45] repo using our generator. At this stage [18:48] the repo is still pre-bade private only [18:52] the creator and corporate members from [18:54] the same domain can see it. Next, the [18:58] collaborator uploads the source code and [19:01] requests a merge. Someone from credit [19:03] card in the same domain reviews the [19:06] approves and it or approve the project [19:10] it's ready for the elevation. What is [19:12] elevation [19:14] her the access manager steps? This not [19:18] only manage permissions or access but [19:20] also triggers elevation by opening an [19:22] issue for inner source admin. An inner [19:25] source admin check the elevation check [19:28] the issue. A inner source and me check [19:30] if the repository is according with the [19:33] standards with the practices and inner [19:35] source admin only need to be a click and [19:38] this repository will transform a inner [19:41] source project. So at that moment a [19:44] repository that was pre-based is inner [19:48] source project anyone contribute anyone [19:49] can work with all rules with all [19:52] governance that we create for that. [19:57] Okay. Uh so we seen what credit is how [20:02] we organize for management and [20:03] governance how rep was created and were [20:06] daily. Now is how do we how do we bring [20:09] source code to the companies. This is [20:12] the sharp process because it's part of [20:14] the process. Right now we have the [20:16] environment where the companies can [20:18] contribute can collaborate but right now [20:21] it's necessary to think how can I send [20:25] this source code to another company. The [20:28] sh process [20:30] is simple. We start with the corporate [20:32] enter ID um in our GitHub instance. [20:36] collaborators from each company join as [20:38] a guest and a collaborative ecosystem [20:41] that we we solve. We have three kinds of [20:45] projects for um sorry we have three kind [20:49] of assets that it's projects for [20:50] documentations [20:53] projects for automation scripts and code [20:56] libraries. These three assets are very [21:00] important to follow some guidelines. [21:05] All of these projects [21:08] maximize the efficiency. Perform keep [21:11] quality as high as possible because our [21:14] cross for all companies ensure the [21:17] assets are truly and reusable. It's very [21:20] quick and the most important thing is we [21:24] make sure that we release to inner is [21:28] not a business specific or a single [21:30] company service but a cross cutting at [21:33] the corporate level. So all products [21:35] needs to be reusable for the companies. [21:40] At that point we have many problems. Let [21:43] me introduce the first problem. How do [21:46] we fork across private instances? As you [21:49] know GitHub doesn't support direct force [21:51] across private instances. It's important [21:54] to mention that credit all companies use [21:55] the GitHub enterprise cloud in MMU. [22:01] Uh or alternative was simple. It's it's [22:05] create a clone. The clone can be used in [22:09] two ways. You can create manual create a [22:12] rep with the destination organization in [22:13] this case company A from the clone [22:17] sorry then clone from credit change the [22:20] role the origin and push it works it's [22:22] simple it's the normal way we also [22:25] implement the automate process that we [22:26] build a self server repository that [22:29] companies can take to can take uh the [22:33] first time obviously is manual but after [22:35] that with the name of the rep the [22:38] repository credit It automat [22:40] automatically creates the destination [22:43] repo clones pushes and apply rule sets [22:46] apply cast configuration to maintain the [22:48] security and quality of the repositories [22:51] with just [22:53] I mean in simple words with just the [22:55] name and one click teams brings the [22:58] inner source projects to the into their [23:01] company. It's a way to clone a [23:05] repository [23:07] and at that point we have a clone [23:10] repository in the company A. We have [23:14] another problem here. However, we face a [23:17] problem for collaboration. If I commit [23:20] in the song repository and the origin [23:23] hasn't changed the problem, I can send [23:26] the change check that there isn't any [23:29] conflict. But what happen if the origin [23:33] receive a change before my contribution? [23:36] When I push in the cl repository and try [23:39] to contribute [23:41] my push may fail due the conflicts [23:43] because we have different branches. [23:46] So is necessary or ideally the new comet [23:50] that have the origin or the root [23:52] repository are read first in my clone. [23:56] So I commit on top of it and with this [23:59] simple change all we check all we works [24:03] because I am I am maintaining a single [24:06] and linear history and obviously works [24:12] we solve and resume this point with a [24:14] single workflow file. I mentioned this [24:17] before when see the files that generate [24:21] repository create um single workflow is [24:25] very simple it's a workflow is a file [24:28] that runs in three ways manually [24:30] schedule request opens and the objective [24:33] is pull changes for from a region or [24:36] from repository to the cl with the [24:39] confix early we keep all companies [24:43] update if I have some changing in my [24:46] source code in the company. If a company [24:48] contribute in the inner source [24:50] organizations, all companies can receive [24:53] at the same time the changes of this of [24:58] this version. It's very useful to [25:00] maintain the security, the compliance uh [25:04] updating the projects and obviously make [25:06] the collaboration smoother. [25:09] The final problem that we face is that [25:13] the clone is impractical because each [25:15] company will want to customize. We want [25:17] to maintain the independence of the of [25:20] the code. Think about that. [25:23] If I am a company that wants to [25:27] create a solution, I am using a solution [25:30] of inner source, a solution across [25:32] collaborative solution. I need to [25:35] adequate. I need to customize. I need to [25:37] personalize. So this uh model where home [25:42] have all changes or receive all changes [25:44] from origin doesn't allow the [25:46] collaboration doesn't allow the [25:47] customations for that reason we need to [25:51] create a technical strategy is that the [25:53] origin of the repository we create a [25:55] fork this fork is from the clone for [25:59] customization so I can customize all [26:03] things in the fork all things in the in [26:06] the new repository the clone stay [26:08] synchronized. The fork can pull up from [26:11] the clone without losing its [26:13] customations. This emulate across [26:16] company fork. Uh we work this with [26:20] GitHub. It's the best way that we found [26:23] to create um a fork between different [26:28] enterprise. Um it's necessary to mention [26:31] that during all process we use um [26:34] communication channels. It's there are [26:36] many services but it's important to [26:39] maintain the communication. At the last [26:41] one I will do like to close the [26:44] presentation with this recommendations. [26:47] It's not conclusion it's more [26:48] recommendation because we are learning [26:50] continuously. Uh three the context as [26:53] enabler of the inner source adoption [26:55] execute support is crucial as the ascept [26:59] that keeps independencies of the [27:01] companies the things is part of the the [27:05] focus and mind and achieve common [27:07] requirements and community it's [27:10] important in our case in financial [27:13] identities the risk and legal concerns [27:15] are real it's very difficult to [27:17] understand for these team themes that uh [27:20] the idea of for example I can contribute [27:22] or share for free. It's necessary to to [27:25] talk to discuss and to work with them to [27:29] show how inner source how open source [27:31] how the collaborations makes value for [27:34] the company and the group. I strongly [27:36] recognize the contributors at the [27:39] beginning is important to [27:41] apply the price participant pattern to [27:44] motivate more active contributions and [27:46] finally rely in the inner source [27:49] patterns. I show many patterns during [27:51] this presentation. Let me show this [27:54] snapshot that all that are all patterns [27:57] that we use in the presentations. We we [28:00] expect that the list grow as we evolve [28:02] and mature but are very useful and are [28:05] very [28:07] precise in in in adoption and I suggest [28:12] you to review to apply and understand [28:15] very well each pattern. Finally thanks [28:20] uh though thanks for the for the time I [28:23] am speaking today but many people made [28:25] this stage possible or city my IT [28:28] manager Nvega my close colleague and [28:31] many other people that probably I will [28:33] need many slides to show how how many [28:38] people works in this project but I'm [28:41] happy to share today with the inner [28:43] source community about our experience [28:45] and show that there are but there is a [28:49] but there are many companies that use [28:51] inner source and inner source really [28:53] value for us. Thank you and I am happy [28:56] to take any question.