Mitsubishi Electric's InnerSource Community Journey Across Diverse Domains #InnerSourceSummit2025

Mitsubishi Electric's InnerSource Community Journey Across Diverse Domains #InnerSourceSummit2025 ![rw-book-cover](https://img.youtube.com/vi/102c9xEOpw8/maxresdefault.jpg) 🔗 **Source:** [Mitsubishi Electric's InnerSource Community Journey Across Diverse Domains #InnerSourceSummit2025](https://www.youtube.com/watch?v=102c9xEOpw8) > [!note]+ Document Notes > tags: [innersource, enterprise, conglomerate, ospo, collaboration] > author: InnerSource Commons > source: YouTube > reference: https://www.youtube.com/watch?v=102c9xEOpw8 > date created: 2025-01-10 10:30 > > # 🏷️ Title: Mitsubishi Electric's InnerSource Community Journey Across Diverse Domains >  ## 🧰 Action Inbox - [H1] Implement Inner Source Value Co-creation Model (IVCM) framework — 05:23 #strategy - [H2] Deploy Backstage portal for repository discovery — 18:45 #platform - [H3] Integrate GitHub Copilot for knowledge base querying — 26:15 #ai ## 🧭 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) - [Backstage](https://backstage.io) ## 📝 Summary - Mitsubishi Electric presents their enterprise-wide InnerSource transformation across diverse business domains - Why it matters: Demonstrates how conglomerates can break down silos through structured collaboration beyond just code sharing - Key stakeholders: Enterprise OSPOs, platform engineers, R&D leaders in large organizations - Risks and tradeoffs: Complex governance across domains vs. maintaining business unit autonomy - Bottom line takeaway: Knowledge sharing at challenge and approach levels creates value even without implementation sharing ## 📖 Main Content Mitsubishi Electric's Open Source Program Office (OSPO) developed the Inner Source Value Co-creation Model (IVCM) to address collaboration challenges unique to conglomerate companies. Unlike single-business companies where executives share common domain knowledge, conglomerates have deeper organizational silos due to diverse domains and autonomous business units. The IVCM framework recognizes three layers of collaboration value: challenge sharing (verbalizing common problems), approach sharing (exchanging solution methods), and implementation sharing (actual code/design assets). The model acknowledges that even when domains can't share implementations due to technical differences, significant value still emerges from challenge and approach sharing. To operationalize this model, they built technical infrastructure including a customized Backstage portal for repository discovery across 700+ GitHub engineers and integrated GitHub Copilot for AI-powered knowledge retrieval from aggregated repositories, issues, and documentation. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/102c9xEOpw8?t=0) — [H1] OSPO Introduction and Mission - Key idea: Dual role OSPO promotes both InnerSource community building and open source collaboration - Evidence: "Over 700 engineers on GitHub, over 1,400 members on Microsoft Teams" #### ⏱️ [02:30](https://youtu.be/102c9xEOpw8?t=150) — [H2] Growth Metrics and Cultural Adoption - Key idea: InnerSource participation showing exponential growth across diverse engineering domains - Evidence: "Projects such as Serendy platforms, robot platforms and factory automation controller project" #### ⏱️ [03:45](https://youtu.be/102c9xEOpw8?t=225) — [H1] Conglomerate Silo Challenge - Key idea: Organizational silos run deeper in conglomerates due to domain diversity and executive background differences - Evidence: "Executives and corporate staff come from diverse domains and often lack understanding of other domains" #### ⏱️ [05:23](https://youtu.be/102c9xEOpw8?t=323) — [H1] Inner Source Value Co-creation Model Framework - Key idea: Collaboration value exists across three layers even without reaching implementation sharing - Evidence: "Challenge sharing, approach sharing, and implementation sharing - each creates value" #### ⏱️ [07:15](https://youtu.be/102c9xEOpw8?t=435) — [H2] Knowledge Sharing as Primary Value - Key idea: InnerSource success should be measured by knowledge transfer, not just shared code adoption - Evidence: "Collaboration is not just about sharing code. It's about sharing knowledge" #### ⏱️ [09:30](https://youtu.be/102c9xEOpw8?t=570) — [H2] Domain Relationship Matrix - Key idea: Value creation potential depends on domain similarity and challenge type compatibility - Evidence: "When domains are closer, collaboration can create more value" #### ⏱️ [11:45](https://youtu.be/102c9xEOpw8?t=705) — [H3] Platform Requirements for IVCM - Key idea: Cross-domain knowledge access requires dedicated platforms beyond basic code repositories - Evidence: "We need a platform that allows people to access various knowledge across different domains" #### ⏱️ [14:20](https://youtu.be/102c9xEOpw8?t=860) — [H2] Stakeholder Pain Points Analysis - Key idea: Repository discoverability emerged as primary barrier to InnerSource adoption - Evidence: "An engineer in division A couldn't easily find relevant code from division B" #### ⏱️ [16:10](https://youtu.be/102c9xEOpw8?t=970) — [H3] Three-Phase Portal Evolution - Key idea: InnerSource portals mature through discovery, connection, and collaboration phases - Evidence: "Phase one is discovery, phase two is connection, phase three is collaboration" #### ⏱️ [18:45](https://youtu.be/102c9xEOpw8?t=1125) — [H2] Backstage Implementation Strategy - Key idea: Backstage extensibility enables incremental feature development for enterprise InnerSource - Evidence: "Plugin architecture means we can start with software catalog and add features incrementally" #### ⏱️ [21:30](https://youtu.be/102c9xEOpw8?t=1290) — [H3] Custom Entity Provider Solution - Key idea: Automated metadata generation enables portal adoption without requiring repository owners to add catalog files - Evidence: "Custom entity provider that generates the catalog automatically from our GitHub environment" #### ⏱️ [24:15](https://youtu.be/102c9xEOpw8?t=1455) — [H2] Current Deployment Status - Key idea: Phase one discovery portal now live with phase two team matching in development - Evidence: "Engineers can browse our catalog, see activity levels and find contacts across divisions" #### ⏱️ [26:15](https://youtu.be/102c9xEOpw8?t=1575) — [H2] AI-Powered Knowledge Integration - Key idea: GitHub Copilot integration transforms aggregated InnerSource content into queryable knowledge base - Evidence: "Natural language knowledge from GitHub repositories, commit logs, issues converted into markdown" #### ⏱️ [28:30](https://youtu.be/102c9xEOpw8?t=1710) — [H1] InnerSource Stack for Co-creation - Key idea: Complete platform combining IVCM framework, Backstage portal, and AI-powered knowledge access - Evidence: "Executives expect cut development lead time by half and create innovation through synergy" ## 📚 References - [InnerSource Patterns](https://patterns.innersourcecommons.org) - [Backstage Software Catalog](https://backstage.io/docs/features/software-catalog) - [GitHub Copilot Enterprise](https://github.com/features/copilot/enterprise) ## 🗣️ Paraphrase - Large conglomerates face unique InnerSource challenges due to deep organizational silos created by diverse business domains and executive backgrounds - Value from InnerSource collaboration can be realized through knowledge sharing at challenge and approach levels, even without shared code implementations - Technical platforms like customized Backstage portals and AI-powered knowledge bases enable cross-domain discovery and learning at enterprise scale ## 📰 Newsletter 🚀 **Enterprise InnerSource Beyond Code Sharing** Mitsubishi Electric's OSPO revealed their innovative approach to InnerSource in conglomerate companies at InnerSource Summit 2025. Their Inner Source Value Co-creation Model (IVCM) recognizes that knowledge sharing creates value even when teams can't share code implementations. **Key Innovation:** Three-layer collaboration framework measuring value from challenge sharing, approach sharing, and implementation sharing - acknowledging that meaningful collaboration can occur at any level. **Technical Implementation:** Custom Backstage portal with automated repository discovery plus GitHub Copilot integration for AI-powered knowledge querying across 700+ engineers. **Practical Benefit:** 50% development lead time reduction target through cross-domain knowledge access rather than forcing common platforms. **Resources:** [InnerSource Patterns](https://patterns.innersourcecommons.org/), [Backstage](https://backstage.io), [InnerSource Commons](https://innersourcecommons.org) ## ✅ Action Items #### OSPO - Strategic Alignment: Implement IVCM framework for measuring collaboration value beyond code sharing - Community Engagement: Design three-phase portal evolution (discovery, connection, collaboration) - Developer Support: Deploy repository discovery platforms with automated metadata generation - Software Inventory: Integrate AI-powered knowledge bases from aggregated repository content #### Community - Maintainers: Create cross-domain collaboration frameworks recognizing challenge and approach sharing value - Contributors: Develop stakeholder pain point analysis methodologies for enterprise InnerSource adoption - Ecosystem: Build platform integrations connecting InnerSource portals with AI-powered knowledge access ## 🧪 Hypotheses - Conglomerate companies require different InnerSource strategies than single-business companies due to deeper organizational silos - Knowledge sharing at challenge and approach levels creates measurable value even without implementation sharing - Automated repository discovery significantly increases InnerSource adoption rates in large enterprises - AI-powered knowledge bases transform static InnerSource repositories into interactive learning environments ### 📊 Methodology - Stakeholder analysis mapping pain points across engineers, project managers, OSPO, and management - Three-phase portal development measuring adoption metrics at discovery, connection, and collaboration stages - IVCM framework validation through cross-domain collaboration value measurement ### ❓ Questions - How can other conglomerates adapt the IVCM framework for their specific domain configurations? - What metrics best demonstrate InnerSource ROI beyond traditional code reuse measurements? - How does AI-powered knowledge retrieval change developer behavior in large-scale InnerSource environments? ### 🔮 Future Research - Comparative studies of InnerSource adoption patterns between single-business companies and conglomerates - Longitudinal analysis of knowledge sharing value measurement across different collaboration layers - Cross-industry validation of three-phase portal evolution model ### 💡 Implications - Practice: OSPOs should measure collaboration value across multiple layers, not just code sharing - Policy: Enterprise InnerSource governance must account for domain autonomy in conglomerate structures - Education: Platform engineering teams need training on stakeholder-driven portal development methodologies - Funding: InnerSource investment justification can include knowledge sharing value beyond implementation adoption ### 🧠 Learning Styles Assessment Reading level estimate: 12th grade #### 👀 Visual learners - Present: Domain relationship matrices, three-phase evolution diagrams, platform architecture visuals - Improve: Interactive collaboration value charts, stakeholder journey maps #### 🔊 Aural learners - Present: Conference presentation format with speaker explanations - Improve: Recorded case study walkthroughs, implementation decision narratives #### 🗣️ Verbal learners - Present: Clear framework definitions, business case explanations, technical terminology - Improve: Glossary of conglomerate-specific InnerSource terms, analogy-driven explanations #### 🧩 Kinesthetic learners - Present: Step-by-step portal implementation guide, hands-on Backstage customization - Improve: Interactive IVCM assessment tools, platform configuration workshops #### 🧠 Logical learners - Present: Systematic stakeholder analysis, phased development approach, measurable outcomes - Improve: Decision trees for collaboration layer assessment, ROI calculation frameworks #### 🧑‍🤝‍🧑 Social learners - Present: Community building strategies, cross-domain collaboration examples - Improve: Peer implementation sharing sessions, collaborative assessment rubrics #### 🧘‍♀️ Solitary learners - Present: Self-contained framework documentation, individual assessment tools - Improve: Personal InnerSource readiness checklists, independent study guides #### 🌿 Naturalistic learners - Present: Organizational ecosystem thinking, natural collaboration patterns - Improve: Biological collaboration analogies, ecosystem health metrics ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading hierarchy, descriptive framework labels - Improve: Alt text for collaboration matrices, ARIA labels for interactive elements #### Keyboard navigation - Present: Standard presentation navigation - Improve: Keyboard-accessible collaboration assessment tools, focus management #### Contrast and readability - Present: Professional presentation design with adequate contrast - Improve: High-contrast versions of technical diagrams, scalable text options #### Text resizing and reflow - Present: Responsive slide content - Improve: Flexible layout for complex framework diagrams, zoom-friendly visuals #### Media and captions - Present: Video presentation with transcript - Improve: Technical diagram audio descriptions, downloadable session notes #### Forms and interactions - Present: Basic presentation interaction - Improve: Accessible collaboration assessment forms, keyboard-friendly tools ### 🌍 DEIB Assessment #### Cultural breadth - Present: Japanese conglomerate perspective, global enterprise relevance - Improve: Multi-regional conglomerate case studies, cultural collaboration patterns #### Inclusive language - Present: Professional technical terminology, clear business language - Improve: Plain language alternatives for complex frameworks, cultural context notes #### Neurodiversity support - Present: Structured framework presentation, logical progression - Improve: Multiple information processing pathways, cognitive load considerations #### Representation - Present: Enterprise engineering perspectives, cross-domain collaboration - Improve: Diverse organizational role representation, varied industry examples #### Psychological safety - Present: Respectful professional presentation style - Improve: Change management sensitivity, organizational transformation support ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear framework derivation from stakeholder analysis and organizational constraints - Inductive strength: Pattern recognition from multiple enterprise collaboration examples - Causal reasoning: Well-supported connections between organizational structure and collaboration challenges - Analogical strength: Appropriate comparisons between single-business and conglomerate collaboration patterns #### Fallacies - Selection bias: Focus on successful implementation without discussing failure cases or limitations - False dichotomy: Presentation of IVCM as primary solution without exploring alternative approaches #### Tone of voice - Overall tone: Professional, systematic, and solution-oriented with clear business focus ### 🛡️ DARVO Analysis - Deny: No concerning denial patterns observed - Attack: No attacks on alternative approaches or critics - Reverse victim/offender: No victim/offender reversal detected - Emotional cues and rhetoric: Professional presentation style with appropriate enthusiasm for innovation ## 🎯 Conclusion Mitsubishi Electric's IVCM framework demonstrates that enterprise InnerSource success extends beyond code sharing to knowledge collaboration across organizational silos. Their three-layer value model (challenge, approach, implementation sharing) provides a practical framework for measuring and maximizing collaboration value in complex organizational structures. The combination of stakeholder-driven platform development using Backstage and AI-powered knowledge access through GitHub Copilot creates a comprehensive technical foundation for enterprise InnerSource transformation. This approach offers valuable insights for other large organizations seeking to break down silos and accelerate innovation through structured collaboration. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad ### [H1] IVCM framework recognizes collaboration value beyond code sharing > [!quote] Mitsubishi Electric's InnerSource Community Journey by InnerSource Commons via YouTube. Published 2025. Accessed 2025-01-10. > "Collaboration is not just about sharing code. It's about sharing knowledge." --- ## Full Transcript [00:06] So good morning everyone. I'm Shoe with [00:10] with my colleague Nogi Kazmanogi. We are [00:14] excited to share our journey today. Uh [00:16] our session title is from silos to [00:19] co-creation mitics inner source journey [00:22] across diverse domains. [00:26] Uh I've been with uh Mitsuk for many [00:30] years mainly working in software R&D [00:33] since this year I have been leading the [00:36] open source and insource program office [00:38] to promote open collaboration across the [00:41] company as this is our first years as an [00:46] OSO I've been speaking at some event and [00:50] today summit is one of the key highlight [00:53] Right. [00:56] Uh, [00:57] noi [clears throat] and I belong to the [00:59] different corporate group under [01:02] Mitsubishi Electric. Uh, he's in the [01:05] corporate island group. Our ospo is in [01:08] the corporate manufacturing engineering [01:11] group. Our KPI is reducing development [01:15] lead time. In the bottom right corner, [01:18] uh, you can see our OSO mascot at tuna. [01:22] uh tuna symbolize agility [01:25] and it is always moving forward and [01:28] never stopping. [01:33] So uh next I'd like to explain two roles [01:36] of our ospo. The first role is promoting [01:39] innerosource. Uh this means building a [01:43] internal community and gathering code [01:46] and knowledge know how into shared [01:49] repository uh shared repository to [01:51] attract developers. Uh we are creating a [01:55] modern development environment. The [01:58] second law is promoting open source. We [02:01] are working with community uh like uh [02:04] Linux foundation and enhancing engineer [02:07] skill through collaboration. Uh in [02:10] addition we also manage security and [02:13] risk across open source use company [02:17] company companywide. [02:20] Uh we promote inner source and open [02:22] source together because their mission [02:25] are synthetic with each other. Uh this [02:28] table shows scope inner source to open [02:31] source and objectives [02:34] uh individual to uh product and [02:36] corporate value. [02:38] uh we started from lower left step uh by [02:43] engaging with opensource community we [02:46] learned cocreation [02:48] knowhow then we moved to upper uh where [02:52] we launched our inner source community [02:55] to post an open co-creation culture and [03:00] enhance developer experience within the [03:02] company. Now we are transitioning [03:05] towards the upper right step uh where we [03:09] aim to create business synergies through [03:13] co-creation and reduce development lead [03:15] time by avoiding same work across [03:19] different domains. [03:23] In this next slide I'd like to show you [03:26] the growth of our innerource community. [03:30] It has grown to over 700 engineers on [03:34] GitHub, over 1,400 [03:38] members on Microsoft Teams. As you can [03:42] see, participation and growth growth [03:45] rate is rising [03:48] and these include projects such as [03:51] Serendy platforms, robot platforms and [03:55] factory automation controller project. [03:57] This momentum proves that inner source [04:01] is now becoming part of our company [04:04] culture. [04:08] Inner source is about breaking down [04:10] organizational silos. In congruent prep [04:14] companies, uh these silos tend to be [04:17] much deeper than in single business [04:20] companies. So why are silos so deep in [04:23] congruity? [04:26] Let's think about that for a moment. In [04:28] a single business company, some [04:30] executives and company staffs uh often [04:34] share common experience. [04:37] They understand the domain and as a [04:40] result decisions can be unified across [04:43] the company. This makes it easier to [04:46] promote companywide initiatives that go [04:50] beyond individual department. [04:53] However, in conglomerate like us, uh, [04:57] executives and corporate staff come from [04:59] diverse domains and often lack [05:03] understanding of other domains. As a [05:06] result, cross domain initiatives occur [05:10] only when domains are willing to [05:12] participate. [05:14] Silos in conglomerates are deep due to [05:19] complexity and domain autonomy. [05:26] In a conglomerate company, what is [05:29] fundamental barrier to fulfilling the [05:32] mission [05:34] of OSPO? [05:36] Executives expect cross domain synergy, [05:39] conglomerate premium and 50% shorter [05:43] development lead time. Some shared [05:46] common platforms succeed but adaption [05:51] remained very limited and several [05:54] initiatives stop midway. [05:57] Today many of these efforts are reminded [06:01] as failures [06:04] and that brings us to occur current [06:07] concern. If we not careful [06:10] uh innocence could face similar [06:12] situation and sharing code alone may not [06:16] be enough to create the full synergy. [06:18] Moreover, the memories of past troubles [06:21] make people feel negative about the new [06:25] initiatives. But we have to ask [06:27] ourselves [06:29] we were those failures truly failures. [06:36] I believe those efforts were not fails. [06:41] Uh they actually created value not [06:44] through a common platform, common [06:46] libraries uh but through discussions [06:49] that generated variable insights. [06:52] That is why we are now taking a new [06:55] approach to cross domain collaboration. [06:57] We now define the value of calculation [07:00] by how much knowledge is shared and used [07:04] across domains. A challenge sharing [07:07] clearly exist in many areas. For [07:09] example, reducing development lead time [07:13] with generative AI. Innosource goes [07:16] beyond code sharing challenge and [07:20] approach sharing are recognized as value [07:24] and connects insight openly across [07:27] domains. To make this possible, we rely [07:31] on open calculation platform like [07:34] GitHub. [07:35] and generate via tool such as GitHub [07:38] copilot that help individuals gain [07:41] knowledge easily. In short, [07:44] collaboration is not just about sharing [07:46] code. It's about sharing knowledge. [07:51] Let's think a bit more about knowledge [07:53] sharing. Here I would like to show one [07:56] simple diagram. On this diagram uh the [08:00] vertical axis [08:02] represents the level of value created [08:05] through sharing. We believe this value [08:09] grows as the knowledge become more [08:12] concrete. [08:14] On the other hand, the horizontal axis [08:16] shows the number of possible cases. Now [08:19] let's go through the three layer from [08:22] bottom to top. At the bottom layer is [08:26] challenge sharing. This mean sharing and [08:29] verbalizing common challenges. For [08:32] example, we want to shift from a [08:34] component sales business model to a [08:38] stock business model like subscription [08:40] model. Uh the next layer is approach [08:44] sharing. This means sharing ideas or [08:47] method to solve those challenges. For [08:50] example, to achieve that uh stock [08:53] business model using softwaredefined [08:56] technology to provide continuous value. [09:00] The top layer is implementation sharing. [09:03] This means sharing actually co actual [09:06] code or design assets for example [09:09] platform or protocols or software [09:12] updates that enable software defined. [09:16] Sharing implementations across domains [09:19] is often difficult. [09:21] So that's why even sharing challenges [09:25] and approaches can still create [09:28] significant value. [09:32] Now let's see how these layers work when [09:35] different domain collaborate. This model [09:38] is uh called the inner source value [09:42] calculation model or simply IB CM. uh in [09:46] the IBCM we recognize that when two [09:50] domain collaborate [09:52] uh there are limits to the value that [09:55] can be created across the layers. Here [09:58] is a conceptual diagram. This is a bad [10:02] bird bad view uh representation. [10:05] On the horizontal vertical axis uh and [10:09] uh horizontal and vertical axis we plot [10:12] different domains uh for example y1, y2, [10:16] x1, x2 represent specific business [10:19] domains such as energy, light, air [10:23] conditioning or factory automation. [10:28] Okay. [10:30] So in this diagram the relationship [10:33] between domains determines how much [10:36] value can be created. [10:38] For example domain y1 and y2 [10:43] y1 and x1 are too different. So even [10:48] challenge sharing cannot create value [10:52] between Y2 and X2 [10:56] uh challenge and approach sharing [10:58] building value and w without uh [11:02] implementation sharing and between Y2 [11:06] and X1 [11:09] value can be created through all three [11:12] uh sharing. [11:14] This means that when domains are closer, [11:17] collaboration can create more value. [11:20] This depends on the type of challenge. [11:23] In some cases, such as case one, uh the [11:26] value spreads widely even to the [11:29] information level. For example, an [11:32] internal tool that use uses uh [11:35] generative AI to automatically create a [11:38] meeting notes like that. Uh the key [11:41] message here is that even if [11:44] collaboration does not reach the [11:46] implementation layers, there is still [11:50] important value created through [11:53] challenge and approach sharing. By [11:56] recognizing this, we can see co-creation [11:59] in a wider way. The these e steps are [12:04] not unfinished but useful stages of [12:07] collaboration that drive innovation [12:10] across diverse domains. [12:15] Now let's take a look at this diagram [12:18] from the side view. Uh the horizontal [12:21] axis shows combination of domains and [12:24] vertical axis shows potential value. Uh [12:28] in the past we sometime judged success [12:31] only by implementation sharing even when [12:34] challenge and approach sharing had [12:37] already succeeded like in the case of [12:40] domain Y2 and X2 [12:44] uh the collaboration was labed as a [12:46] failure because the teams couldn't reach [12:50] the implementation layer but in the ICM [12:54] we take a different view we aim to [12:57] maximize and visualize the value created [13:00] even at the challenge and approach [13:04] layers. Implementation sharing creates [13:07] the highest value but the range of [13:11] applicable [13:12] uh domains is narrowest. [13:16] But in the IBCM we take a h sorry uh we [13:20] need a platform that allows people to [13:23] access various knowledge across [13:25] different domains. Our R&D division is [13:29] now developing uh this kind of platform. [13:33] Today as part of this initiative uh NOGI [13:36] will introduce a particular example our [13:40] effort to build a collaborative portal [13:43] that supports innerource access uh [13:46] across the enter company. [13:55] Thank you all. [13:57] Uh also outlined IVCM. From here I'll [14:01] share a practical journey with inasource [14:04] portal using backstage the technical [14:06] foundation for IVCM. [14:11] From here uh firstly uh let me introduce [14:15] myself. [14:17] I work on IT service operations focusing [14:21] on S sur and platform engineering. [14:24] Previously I developed autonomous [14:26] driving systems and those testing [14:28] environments [14:30] and I joined R&D division where I'm now [14:33] applying my experience to the platform [14:36] engineering. [14:39] Our R&D division partners with OPO from [14:43] a technical perspective. [14:45] While OPO uh focuses on program [14:49] management and governance and community [14:53] building, we concentrate on technical [14:55] enablement. [14:59] Feally we focuses on automation and [15:05] guarders and building infrastructure [15:08] that makes inner source frictionless for [15:10] engineers. So think of us as a platform [15:13] team for inner source. [15:18] Now let's move on to the main topic. [15:21] When we first began sharing code, we had [15:23] a challenge familiar to many large [15:25] enterprises. [15:27] Hundreds of sc hundreds of existing [15:29] innerosource repositories scattered [15:31] across divisions with no easy way to [15:34] discover them. [15:36] For instance, uh an engineer in division [15:40] A couldn't easily find relevant code [15:42] from division B. Project managers [15:45] couldn't attract contributors from other [15:47] teams and also uh couldn't demonstrate [15:53] uh the value being created from uh [15:56] across the organization. We had the [15:58] infrastructure GitHub enterprise [16:01] but we we lacked uh discoverability and [16:06] connection layer. [16:09] So we stepped back and analyzed our [16:12] stakeholders and their pain points. [16:15] Engineers including myself were wasting [16:18] hours searching for code that might [16:20] already uh exist somewhere and project [16:23] managers overseeing repositories [16:26] uh couldn't uh effectively showcase [16:30] their project to attract contributors [16:33] from other divisions. [16:36] OSPO needed concrete ways to measure and [16:39] demonstrate the inner source value to [16:42] leadership and management wanted to [16:45] achieve uh cross business synergy or [16:48] congarate premium uh through cross [16:51] divisional collaboration. [16:54] These pain points represented a [16:55] systematic gap that existing tools like [16:58] GitHub alone track and chimps couldn't [17:02] freely address. [17:04] Before [17:06] we designed our solution, we looked to [17:09] proven patterns, the inner source [17:11] committee provides inner source patterns [17:14] uh patterns like uh in inner sporter and [17:17] gig marketplace that directly address [17:20] these challenges. [17:23] And of course uh we studied uh [17:27] implementations. [17:28] Bandamo in Japan built backstage based [17:31] portal for multi repository management [17:34] and assess sharing. Airas migrated from [17:37] a simple portal to backstage for [17:39] extensibility. [17:41] These examples uh validated our [17:44] direction. We needed a portal and it [17:47] needed to be extensible. [17:53] Through our direct through our [17:55] stakeholder analysis and studies, we [17:58] realized that the inner source portter [18:01] evolves through three distinct phases [18:04] and this framework can be said to view [18:07] IBM from how perspective. [18:10] The phase one is discovery. This phase [18:13] focuses on cataloging all technical [18:15] assets, mapping skills and expertise and [18:18] find helping people find collaboration [18:20] opportunities. The core question is what [18:23] exists and who's working on it. [18:27] The second phase is connection. This [18:30] phase enables crossdivisional matching [18:32] forming project based teams what we call [18:35] gigus and spreading the inner source [18:39] mindset. The question becomes how do I [18:42] connect with the white people. [18:45] The final phase collaboration [18:48] uh provides project management to a [18:50] contribution visibility for incentives [18:53] and governance automation. The question [18:55] is how do we work together effectively? [18:59] We are currently focused on phase one [19:01] with phase two and three features in our [19:03] backlog. [19:07] Then we started uh with our proof of [19:09] concept using SAP's implementation which [19:12] also uh referenced the inasource [19:15] patterns. [19:17] This gave us two critical benefits. [19:20] First we could deploy quickly and [19:23] validate interest and second employees [19:26] without GitHub enterprise license could [19:29] s uh could s uh discover and explore our [19:33] repositories. [19:36] But as team engaged with it, they wanted [19:38] more a better search uh project health [19:41] indicators and conduct information. [19:44] While predate interest, we needed [19:47] something more extensible as expected. [19:53] This led us to Backstage, the internal [19:55] developer platform framework from [19:57] Spotify, now a CNCF project. We chose [20:00] backstage for three reasons. First [20:03] extensibility [20:05] uh it's plug-in architecture means we [20:07] can start with the uh software catalog [20:11] and add features incrementally. [20:13] Second is community. There is a thriving [20:16] ecosystem of fragments and the proven [20:18] track record in large enterprises [20:23] and third uh active development. [20:26] Backstage is frequently updated and well [20:28] maintained by the community. It's [20:30] relable and we'd love to contribute it. [20:34] Like us uh we recognized the backstage [20:38] extensibility was essential to uh [20:41] provide features we need for our [20:43] organization [20:49] to deliver phase one discovery and [20:51] enable IVCM. [20:54] We built a custom a customized back uh [20:58] software catalog backstage typically [21:01] expects repositories to have catalog [21:04] info. [21:06] But we had hundreds of existing [21:08] repositories owned by different teams [21:10] with no such files. Asking everyone to [21:13] add metadata immediately wasn't [21:15] realistic. So we built custom entity [21:18] provider that generates the catalog [21:20] automatically from our GitHub [21:22] environment. [21:24] This approach also let us add custom [21:27] properties m to our our organization [21:32] uh contact information [21:34] activity scores and uh project uh [21:37] business domain tags [21:41] and we customize front end to surface [21:44] these properties naturally [21:47] uh it's a software catalog tailored [21:49] specifically for Mitsubishi electrics in [21:51] assoc environment [21:53] Then we deployed a customized backstage [21:56] portal uh as a containerized application [22:01] on our AWS account. It's now accessible [22:04] to all employees and of course uh the [22:07] infrastructure and application code for [22:09] this portal are themselves in a source [22:12] within our GitHub. [22:16] So where are we today? Uh phase one [22:18] discovery is now live. Engineers can [22:21] browse uh our catalog uh see activity [22:25] levels and find contacts across [22:28] divisions. We are currently uh gathering [22:31] feedback [22:32] and planning phase two features uh team [22:35] matching and project recruitment boards [22:37] and phase three uh which focuses on [22:40] collaboration remains in our backlog. [22:46] So from a technical perspective, we [22:48] built a customized backstage portal that [22:51] makes inner source discoverable and [22:53] accessible across Mitsubishi electric. [22:56] It this is a a technical foundation for [22:59] IVCM. [23:01] So uh I'll hand it back to for summary. [23:04] Thank you. Back to you. [23:08] Okay. Now I'd like to show how we [23:11] generative AI to make Inosource [23:14] knowledge easier to access. Uh in our [23:17] insource platform we collect not only [23:20] source code but also natural language [23:22] knowledge uh from many GitHub enterprise [23:25] repositories commit logs uh issues and [23:29] pull requests. uh these are converted [23:32] into markdown and stored in one [23:36] aggregated repository uh which is set as [23:39] a lag target inside GitHub compiler [23:43] spaces. As a result, developers can now [23:46] interact freely with GitHub copilot [23:49] chat. Uh in short this system turns out [23:53] in a source into a living knowledge base [23:56] uh where information flows seamlessly [24:00] between [24:02] uh people code and AI. Uh here is a [24:05] sample uh simple s simple example. Uh a [24:09] developer might ask is knowledge related [24:12] to line toing technology for mobile [24:16] robots uh being shared within the [24:18] inosour environment. [24:20] Uh coparot immediately identified the [24:23] light right repositories and summarize [24:28] it contents. [24:30] Even with hundreds of project engineers [24:33] can now find useful knowledge in seconds [24:37] without extra effort. This is how [24:40] generative AI transform insource into [24:42] interactive knowledge ecosystem like [24:45] this. [24:48] Next let's see how all these pieces [24:51] connect or what we call the inour stack [24:54] for calculation. Uh the executives [24:58] expects cut the development lead time by [25:01] half and create innovation through [25:04] synergy across diverse domains to [25:07] achieve the above goals. Uh the concept [25:11] of IBCM is essential as concrete actions [25:15] to realize IBCM. It is necessary to [25:19] build inner source platform and [25:21] communities. The INSOS portal is one of [25:24] the Inosource platforms and realize IBSM [25:29] uh through three phases. In addition, [25:32] the platform provides functions that [25:35] promote knowledge sharing by leveraging [25:38] generative AI. Now let's move to the [25:41] conclusion. Today we introduce the inner [25:44] source value calculation model in uh [25:47] conglomeratic company. Co-creation [25:49] should go beyond implementation sharing. [25:53] Uh it must also include challenge and [25:56] approach sharing. We believe this idea [25:58] also applies to uh single business [26:01] companies. Uh going forward we will [26:04] continue to maximize and visualize the [26:07] value of all three layers aiming for 50% [26:12] reduction in development lead time. I [26:14] look forward to learning from the many [26:16] sessions and discussion throughout this [26:19] summit and to exploring uh together how [26:24] we can shape the future of cocreation. [26:27] Thank you. [26:29] [applause]  [[3. Resources/Readwise/Full Document Contents/Articles/Mitsubishi Electric's InnerSource Community Journey Across Diverse Domains #InnerSourceSummit2025|Full Document Contents]] ## Document Notes --- tags: #innersource #enterprise #conglomerate #ospo #collaboration author: InnerSource Commons source: YouTube reference: https://www.youtube.com/watch?v=102c9xEOpw8 date created: 2025-01-10 10:30 --- # 🏷️ Title: Mitsubishi Electric's InnerSource Community Journey Across Diverse Domains ## 🧰 Action Inbox - [H1] Implement Inner Source Value Co-creation Model (IVCM) framework — 05:23 #strategy - [H2] Deploy Backstage portal for repository discovery — 18:45 #platform - [H3] Integrate GitHub Copilot for knowledge base querying — 26:15 #ai ## 🧭 Table of Contents - [[#📝 Summary]] - [[#📖 Main Content]] - [[#🗒️ Notes]] - [[#📚 References]] - [[#🗣️ Paraphrase]] - [[#📰 Newsletter]] - [[#✅ Action Items]] - [[#🧪 Hypotheses]] - [[#📊 Methodology]] - [[#❓ Questions]] - [[#🔮 Future Research]] - [[#💡 Implications]] - [[#🧠 Learning Styles Assessment]] - [[#📊 Accessibility Assessment]] - [[#🌍 DEIB Assessment]] - [[#✅ Logical Validity]] - [[#🛡️ DARVO Analysis]] - [[#🎯 Conclusion]] ### 🔗 References - [InnerSource Commons](https://innersourcecommons.org) - [Backstage](https://backstage.io) ## 📝 Summary - Mitsubishi Electric presents their enterprise-wide InnerSource transformation across diverse business domains - Why it matters: Demonstrates how conglomerates can break down silos through structured collaboration beyond just code sharing - Key stakeholders: Enterprise OSPOs, platform engineers, R&D leaders in large organizations - Risks and tradeoffs: Complex governance across domains vs. maintaining business unit autonomy - Bottom line takeaway: Knowledge sharing at challenge and approach levels creates value even without implementation sharing ## 📖 Main Content Mitsubishi Electric's Open Source Program Office (OSPO) developed the Inner Source Value Co-creation Model (IVCM) to address collaboration challenges unique to conglomerate companies. Unlike single-business companies where executives share common domain knowledge, conglomerates have deeper organizational silos due to diverse domains and autonomous business units. The IVCM framework recognizes three layers of collaboration value: challenge sharing (verbalizing common problems), approach sharing (exchanging solution methods), and implementation sharing (actual code/design assets). The model acknowledges that even when domains can't share implementations due to technical differences, significant value still emerges from challenge and approach sharing. To operationalize this model, they built technical infrastructure including a customized Backstage portal for repository discovery across 700+ GitHub engineers and integrated GitHub Copilot for AI-powered knowledge retrieval from aggregated repositories, issues, and documentation. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/102c9xEOpw8?t=0) — [H1] OSPO Introduction and Mission - Key idea: Dual role OSPO promotes both InnerSource community building and open source collaboration - Evidence: "Over 700 engineers on GitHub, over 1,400 members on Microsoft Teams" #### ⏱️ [02:30](https://youtu.be/102c9xEOpw8?t=150) — [H2] Growth Metrics and Cultural Adoption - Key idea: InnerSource participation showing exponential growth across diverse engineering domains - Evidence: "Projects such as Serendy platforms, robot platforms and factory automation controller project" #### ⏱️ [03:45](https://youtu.be/102c9xEOpw8?t=225) — [H1] Conglomerate Silo Challenge - Key idea: Organizational silos run deeper in conglomerates due to domain diversity and executive background differences - Evidence: "Executives and corporate staff come from diverse domains and often lack understanding of other domains" #### ⏱️ [05:23](https://youtu.be/102c9xEOpw8?t=323) — [H1] Inner Source Value Co-creation Model Framework - Key idea: Collaboration value exists across three layers even without reaching implementation sharing - Evidence: "Challenge sharing, approach sharing, and implementation sharing - each creates value" #### ⏱️ [07:15](https://youtu.be/102c9xEOpw8?t=435) — [H2] Knowledge Sharing as Primary Value - Key idea: InnerSource success should be measured by knowledge transfer, not just shared code adoption - Evidence: "Collaboration is not just about sharing code. It's about sharing knowledge" #### ⏱️ [09:30](https://youtu.be/102c9xEOpw8?t=570) — [H2] Domain Relationship Matrix - Key idea: Value creation potential depends on domain similarity and challenge type compatibility - Evidence: "When domains are closer, collaboration can create more value" #### ⏱️ [11:45](https://youtu.be/102c9xEOpw8?t=705) — [H3] Platform Requirements for IVCM - Key idea: Cross-domain knowledge access requires dedicated platforms beyond basic code repositories - Evidence: "We need a platform that allows people to access various knowledge across different domains" #### ⏱️ [14:20](https://youtu.be/102c9xEOpw8?t=860) — [H2] Stakeholder Pain Points Analysis - Key idea: Repository discoverability emerged as primary barrier to InnerSource adoption - Evidence: "An engineer in division A couldn't easily find relevant code from division B" #### ⏱️ [16:10](https://youtu.be/102c9xEOpw8?t=970) — [H3] Three-Phase Portal Evolution - Key idea: InnerSource portals mature through discovery, connection, and collaboration phases - Evidence: "Phase one is discovery, phase two is connection, phase three is collaboration" #### ⏱️ [18:45](https://youtu.be/102c9xEOpw8?t=1125) — [H2] Backstage Implementation Strategy - Key idea: Backstage extensibility enables incremental feature development for enterprise InnerSource - Evidence: "Plugin architecture means we can start with software catalog and add features incrementally" #### ⏱️ [21:30](https://youtu.be/102c9xEOpw8?t=1290) — [H3] Custom Entity Provider Solution - Key idea: Automated metadata generation enables portal adoption without requiring repository owners to add catalog files - Evidence: "Custom entity provider that generates the catalog automatically from our GitHub environment" #### ⏱️ [24:15](https://youtu.be/102c9xEOpw8?t=1455) — [H2] Current Deployment Status - Key idea: Phase one discovery portal now live with phase two team matching in development - Evidence: "Engineers can browse our catalog, see activity levels and find contacts across divisions" #### ⏱️ [26:15](https://youtu.be/102c9xEOpw8?t=1575) — [H2] AI-Powered Knowledge Integration - Key idea: GitHub Copilot integration transforms aggregated InnerSource content into queryable knowledge base - Evidence: "Natural language knowledge from GitHub repositories, commit logs, issues converted into markdown" #### ⏱️ [28:30](https://youtu.be/102c9xEOpw8?t=1710) — [H1] InnerSource Stack for Co-creation - Key idea: Complete platform combining IVCM framework, Backstage portal, and AI-powered knowledge access - Evidence: "Executives expect cut development lead time by half and create innovation through synergy" ## 📚 References - [InnerSource Patterns](https://patterns.innersourcecommons.org) - [Backstage Software Catalog](https://backstage.io/docs/features/software-catalog) - [GitHub Copilot Enterprise](https://github.com/features/copilot/enterprise) ## 🗣️ Paraphrase - Large conglomerates face unique InnerSource challenges due to deep organizational silos created by diverse business domains and executive backgrounds - Value from InnerSource collaboration can be realized through knowledge sharing at challenge and approach levels, even without shared code implementations - Technical platforms like customized Backstage portals and AI-powered knowledge bases enable cross-domain discovery and learning at enterprise scale ## 📰 Newsletter 🚀 **Enterprise InnerSource Beyond Code Sharing** Mitsubishi Electric's OSPO revealed their innovative approach to InnerSource in conglomerate companies at InnerSource Summit 2025. Their Inner Source Value Co-creation Model (IVCM) recognizes that knowledge sharing creates value even when teams can't share code implementations. **Key Innovation:** Three-layer collaboration framework measuring value from challenge sharing, approach sharing, and implementation sharing - acknowledging that meaningful collaboration can occur at any level. **Technical Implementation:** Custom Backstage portal with automated repository discovery plus GitHub Copilot integration for AI-powered knowledge querying across 700+ engineers. **Practical Benefit:** 50% development lead time reduction target through cross-domain knowledge access rather than forcing common platforms. **Resources:** [InnerSource Patterns](https://patterns.innersourcecommons.org/), [Backstage](https://backstage.io), [InnerSource Commons](https://innersourcecommons.org) ## ✅ Action Items #### OSPO - Strategic Alignment: Implement IVCM framework for measuring collaboration value beyond code sharing - Community Engagement: Design three-phase portal evolution (discovery, connection, collaboration) - Developer Support: Deploy repository discovery platforms with automated metadata generation - Software Inventory: Integrate AI-powered knowledge bases from aggregated repository content #### Community - Maintainers: Create cross-domain collaboration frameworks recognizing challenge and approach sharing value - Contributors: Develop stakeholder pain point analysis methodologies for enterprise InnerSource adoption - Ecosystem: Build platform integrations connecting InnerSource portals with AI-powered knowledge access ## 🧪 Hypotheses - Conglomerate companies require different InnerSource strategies than single-business companies due to deeper organizational silos - Knowledge sharing at challenge and approach levels creates measurable value even without implementation sharing - Automated repository discovery significantly increases InnerSource adoption rates in large enterprises - AI-powered knowledge bases transform static InnerSource repositories into interactive learning environments ### 📊 Methodology - Stakeholder analysis mapping pain points across engineers, project managers, OSPO, and management - Three-phase portal development measuring adoption metrics at discovery, connection, and collaboration stages - IVCM framework validation through cross-domain collaboration value measurement ### ❓ Questions - How can other conglomerates adapt the IVCM framework for their specific domain configurations? - What metrics best demonstrate InnerSource ROI beyond traditional code reuse measurements? - How does AI-powered knowledge retrieval change developer behavior in large-scale InnerSource environments? ### 🔮 Future Research - Comparative studies of InnerSource adoption patterns between single-business companies and conglomerates - Longitudinal analysis of knowledge sharing value measurement across different collaboration layers - Cross-industry validation of three-phase portal evolution model ### 💡 Implications - Practice: OSPOs should measure collaboration value across multiple layers, not just code sharing - Policy: Enterprise InnerSource governance must account for domain autonomy in conglomerate structures - Education: Platform engineering teams need training on stakeholder-driven portal development methodologies - Funding: InnerSource investment justification can include knowledge sharing value beyond implementation adoption ### 🧠 Learning Styles Assessment Reading level estimate: 12th grade #### 👀 Visual learners - Present: Domain relationship matrices, three-phase evolution diagrams, platform architecture visuals - Improve: Interactive collaboration value charts, stakeholder journey maps #### 🔊 Aural learners - Present: Conference presentation format with speaker explanations - Improve: Recorded case study walkthroughs, implementation decision narratives #### 🗣️ Verbal learners - Present: Clear framework definitions, business case explanations, technical terminology - Improve: Glossary of conglomerate-specific InnerSource terms, analogy-driven explanations #### 🧩 Kinesthetic learners - Present: Step-by-step portal implementation guide, hands-on Backstage customization - Improve: Interactive IVCM assessment tools, platform configuration workshops #### 🧠 Logical learners - Present: Systematic stakeholder analysis, phased development approach, measurable outcomes - Improve: Decision trees for collaboration layer assessment, ROI calculation frameworks #### 🧑‍🤝‍🧑 Social learners - Present: Community building strategies, cross-domain collaboration examples - Improve: Peer implementation sharing sessions, collaborative assessment rubrics #### 🧘‍♀️ Solitary learners - Present: Self-contained framework documentation, individual assessment tools - Improve: Personal InnerSource readiness checklists, independent study guides #### 🌿 Naturalistic learners - Present: Organizational ecosystem thinking, natural collaboration patterns - Improve: Biological collaboration analogies, ecosystem health metrics ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading hierarchy, descriptive framework labels - Improve: Alt text for collaboration matrices, ARIA labels for interactive elements #### Keyboard navigation - Present: Standard presentation navigation - Improve: Keyboard-accessible collaboration assessment tools, focus management #### Contrast and readability - Present: Professional presentation design with adequate contrast - Improve: High-contrast versions of technical diagrams, scalable text options #### Text resizing and reflow - Present: Responsive slide content - Improve: Flexible layout for complex framework diagrams, zoom-friendly visuals #### Media and captions - Present: Video presentation with transcript - Improve: Technical diagram audio descriptions, downloadable session notes #### Forms and interactions - Present: Basic presentation interaction - Improve: Accessible collaboration assessment forms, keyboard-friendly tools ### 🌍 DEIB Assessment #### Cultural breadth - Present: Japanese conglomerate perspective, global enterprise relevance - Improve: Multi-regional conglomerate case studies, cultural collaboration patterns #### Inclusive language - Present: Professional technical terminology, clear business language - Improve: Plain language alternatives for complex frameworks, cultural context notes #### Neurodiversity support - Present: Structured framework presentation, logical progression - Improve: Multiple information processing pathways, cognitive load considerations #### Representation - Present: Enterprise engineering perspectives, cross-domain collaboration - Improve: Diverse organizational role representation, varied industry examples #### Psychological safety - Present: Respectful professional presentation style - Improve: Change management sensitivity, organizational transformation support ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear framework derivation from stakeholder analysis and organizational constraints - Inductive strength: Pattern recognition from multiple enterprise collaboration examples - Causal reasoning: Well-supported connections between organizational structure and collaboration challenges - Analogical strength: Appropriate comparisons between single-business and conglomerate collaboration patterns #### Fallacies - Selection bias: Focus on successful implementation without discussing failure cases or limitations - False dichotomy: Presentation of IVCM as primary solution without exploring alternative approaches #### Tone of voice - Overall tone: Professional, systematic, and solution-oriented with clear business focus ### 🛡️ DARVO Analysis - Deny: No concerning denial patterns observed - Attack: No attacks on alternative approaches or critics - Reverse victim/offender: No victim/offender reversal detected - Emotional cues and rhetoric: Professional presentation style with appropriate enthusiasm for innovation ## 🎯 Conclusion Mitsubishi Electric's IVCM framework demonstrates that enterprise InnerSource success extends beyond code sharing to knowledge collaboration across organizational silos. Their three-layer value model (challenge, approach, implementation sharing) provides a practical framework for measuring and maximizing collaboration value in complex organizational structures. The combination of stakeholder-driven platform development using Backstage and AI-powered knowledge access through GitHub Copilot creates a comprehensive technical foundation for enterprise InnerSource transformation. This approach offers valuable insights for other large organizations seeking to break down silos and accelerate innovation through structured collaboration. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad ### [H1] IVCM framework recognizes collaboration value beyond code sharing > [!quote] Mitsubishi Electric's InnerSource Community Journey by InnerSource Commons via YouTube. Published 2025. Accessed 2025-01-10. > "Collaboration is not just about sharing code. It's about sharing knowledge." --- ## Full Transcript [00:06] So good morning everyone. I'm Shoe with [00:10] with my colleague Nogi Kazmanogi. We are [00:14] excited to share our journey today. Uh [00:16] our session title is from silos to [00:19] co-creation mitics inner source journey [00:22] across diverse domains. [00:26] Uh I've been with uh Mitsuk for many [00:30] years mainly working in software R&D [00:33] since this year I have been leading the [00:36] open source and insource program office [00:38] to promote open collaboration across the [00:41] company as this is our first years as an [00:46] OSO I've been speaking at some event and [00:50] today summit is one of the key highlight [00:53] Right. [00:56] Uh, [00:57] noi [clears throat] and I belong to the [00:59] different corporate group under [01:02] Mitsubishi Electric. Uh, he's in the [01:05] corporate island group. Our ospo is in [01:08] the corporate manufacturing engineering [01:11] group. Our KPI is reducing development [01:15] lead time. In the bottom right corner, [01:18] uh, you can see our OSO mascot at tuna. [01:22] uh tuna symbolize agility [01:25] and it is always moving forward and [01:28] never stopping. [01:33] So uh next I'd like to explain two roles [01:36] of our ospo. The first role is promoting [01:39] innerosource. Uh this means building a [01:43] internal community and gathering code [01:46] and knowledge know how into shared [01:49] repository uh shared repository to [01:51] attract developers. Uh we are creating a [01:55] modern development environment. The [01:58] second law is promoting open source. We [02:01] are working with community uh like uh [02:04] Linux foundation and enhancing engineer [02:07] skill through collaboration. Uh in [02:10] addition we also manage security and [02:13] risk across open source use company [02:17] company companywide. [02:20] Uh we promote inner source and open [02:22] source together because their mission [02:25] are synthetic with each other. Uh this [02:28] table shows scope inner source to open [02:31] source and objectives [02:34] uh individual to uh product and [02:36] corporate value. [02:38] uh we started from lower left step uh by [02:43] engaging with opensource community we [02:46] learned cocreation [02:48] knowhow then we moved to upper uh where [02:52] we launched our inner source community [02:55] to post an open co-creation culture and [03:00] enhance developer experience within the [03:02] company. Now we are transitioning [03:05] towards the upper right step uh where we [03:09] aim to create business synergies through [03:13] co-creation and reduce development lead [03:15] time by avoiding same work across [03:19] different domains. [03:23] In this next slide I'd like to show you [03:26] the growth of our innerource community. [03:30] It has grown to over 700 engineers on [03:34] GitHub, over 1,400 [03:38] members on Microsoft Teams. As you can [03:42] see, participation and growth growth [03:45] rate is rising [03:48] and these include projects such as [03:51] Serendy platforms, robot platforms and [03:55] factory automation controller project. [03:57] This momentum proves that inner source [04:01] is now becoming part of our company [04:04] culture. [04:08] Inner source is about breaking down [04:10] organizational silos. In congruent prep [04:14] companies, uh these silos tend to be [04:17] much deeper than in single business [04:20] companies. So why are silos so deep in [04:23] congruity? [04:26] Let's think about that for a moment. In [04:28] a single business company, some [04:30] executives and company staffs uh often [04:34] share common experience. [04:37] They understand the domain and as a [04:40] result decisions can be unified across [04:43] the company. This makes it easier to [04:46] promote companywide initiatives that go [04:50] beyond individual department. [04:53] However, in conglomerate like us, uh, [04:57] executives and corporate staff come from [04:59] diverse domains and often lack [05:03] understanding of other domains. As a [05:06] result, cross domain initiatives occur [05:10] only when domains are willing to [05:12] participate. [05:14] Silos in conglomerates are deep due to [05:19] complexity and domain autonomy. [05:26] In a conglomerate company, what is [05:29] fundamental barrier to fulfilling the [05:32] mission [05:34] of OSPO? [05:36] Executives expect cross domain synergy, [05:39] conglomerate premium and 50% shorter [05:43] development lead time. Some shared [05:46] common platforms succeed but adaption [05:51] remained very limited and several [05:54] initiatives stop midway. [05:57] Today many of these efforts are reminded [06:01] as failures [06:04] and that brings us to occur current [06:07] concern. If we not careful [06:10] uh innocence could face similar [06:12] situation and sharing code alone may not [06:16] be enough to create the full synergy. [06:18] Moreover, the memories of past troubles [06:21] make people feel negative about the new [06:25] initiatives. But we have to ask [06:27] ourselves [06:29] we were those failures truly failures. [06:36] I believe those efforts were not fails. [06:41] Uh they actually created value not [06:44] through a common platform, common [06:46] libraries uh but through discussions [06:49] that generated variable insights. [06:52] That is why we are now taking a new [06:55] approach to cross domain collaboration. [06:57] We now define the value of calculation [07:00] by how much knowledge is shared and used [07:04] across domains. A challenge sharing [07:07] clearly exist in many areas. For [07:09] example, reducing development lead time [07:13] with generative AI. Innosource goes [07:16] beyond code sharing challenge and [07:20] approach sharing are recognized as value [07:24] and connects insight openly across [07:27] domains. To make this possible, we rely [07:31] on open calculation platform like [07:34] GitHub. [07:35] and generate via tool such as GitHub [07:38] copilot that help individuals gain [07:41] knowledge easily. In short, [07:44] collaboration is not just about sharing [07:46] code. It's about sharing knowledge. [07:51] Let's think a bit more about knowledge [07:53] sharing. Here I would like to show one [07:56] simple diagram. On this diagram uh the [08:00] vertical axis [08:02] represents the level of value created [08:05] through sharing. We believe this value [08:09] grows as the knowledge become more [08:12] concrete. [08:14] On the other hand, the horizontal axis [08:16] shows the number of possible cases. Now [08:19] let's go through the three layer from [08:22] bottom to top. At the bottom layer is [08:26] challenge sharing. This mean sharing and [08:29] verbalizing common challenges. For [08:32] example, we want to shift from a [08:34] component sales business model to a [08:38] stock business model like subscription [08:40] model. Uh the next layer is approach [08:44] sharing. This means sharing ideas or [08:47] method to solve those challenges. For [08:50] example, to achieve that uh stock [08:53] business model using softwaredefined [08:56] technology to provide continuous value. [09:00] The top layer is implementation sharing. [09:03] This means sharing actually co actual [09:06] code or design assets for example [09:09] platform or protocols or software [09:12] updates that enable software defined. [09:16] Sharing implementations across domains [09:19] is often difficult. [09:21] So that's why even sharing challenges [09:25] and approaches can still create [09:28] significant value. [09:32] Now let's see how these layers work when [09:35] different domain collaborate. This model [09:38] is uh called the inner source value [09:42] calculation model or simply IB CM. uh in [09:46] the IBCM we recognize that when two [09:50] domain collaborate [09:52] uh there are limits to the value that [09:55] can be created across the layers. Here [09:58] is a conceptual diagram. This is a bad [10:02] bird bad view uh representation. [10:05] On the horizontal vertical axis uh and [10:09] uh horizontal and vertical axis we plot [10:12] different domains uh for example y1, y2, [10:16] x1, x2 represent specific business [10:19] domains such as energy, light, air [10:23] conditioning or factory automation. [10:28] Okay. [10:30] So in this diagram the relationship [10:33] between domains determines how much [10:36] value can be created. [10:38] For example domain y1 and y2 [10:43] y1 and x1 are too different. So even [10:48] challenge sharing cannot create value [10:52] between Y2 and X2 [10:56] uh challenge and approach sharing [10:58] building value and w without uh [11:02] implementation sharing and between Y2 [11:06] and X1 [11:09] value can be created through all three [11:12] uh sharing. [11:14] This means that when domains are closer, [11:17] collaboration can create more value. [11:20] This depends on the type of challenge. [11:23] In some cases, such as case one, uh the [11:26] value spreads widely even to the [11:29] information level. For example, an [11:32] internal tool that use uses uh [11:35] generative AI to automatically create a [11:38] meeting notes like that. Uh the key [11:41] message here is that even if [11:44] collaboration does not reach the [11:46] implementation layers, there is still [11:50] important value created through [11:53] challenge and approach sharing. By [11:56] recognizing this, we can see co-creation [11:59] in a wider way. The these e steps are [12:04] not unfinished but useful stages of [12:07] collaboration that drive innovation [12:10] across diverse domains. [12:15] Now let's take a look at this diagram [12:18] from the side view. Uh the horizontal [12:21] axis shows combination of domains and [12:24] vertical axis shows potential value. Uh [12:28] in the past we sometime judged success [12:31] only by implementation sharing even when [12:34] challenge and approach sharing had [12:37] already succeeded like in the case of [12:40] domain Y2 and X2 [12:44] uh the collaboration was labed as a [12:46] failure because the teams couldn't reach [12:50] the implementation layer but in the ICM [12:54] we take a different view we aim to [12:57] maximize and visualize the value created [13:00] even at the challenge and approach [13:04] layers. Implementation sharing creates [13:07] the highest value but the range of [13:11] applicable [13:12] uh domains is narrowest. [13:16] But in the IBCM we take a h sorry uh we [13:20] need a platform that allows people to [13:23] access various knowledge across [13:25] different domains. Our R&D division is [13:29] now developing uh this kind of platform. [13:33] Today as part of this initiative uh NOGI [13:36] will introduce a particular example our [13:40] effort to build a collaborative portal [13:43] that supports innerource access uh [13:46] across the enter company. [13:55] Thank you all. [13:57] Uh also outlined IVCM. From here I'll [14:01] share a practical journey with inasource [14:04] portal using backstage the technical [14:06] foundation for IVCM. [14:11] From here uh firstly uh let me introduce [14:15] myself. [14:17] I work on IT service operations focusing [14:21] on S sur and platform engineering. [14:24] Previously I developed autonomous [14:26] driving systems and those testing [14:28] environments [14:30] and I joined R&D division where I'm now [14:33] applying my experience to the platform [14:36] engineering. [14:39] Our R&D division partners with OPO from [14:43] a technical perspective. [14:45] While OPO uh focuses on program [14:49] management and governance and community [14:53] building, we concentrate on technical [14:55] enablement. [14:59] Feally we focuses on automation and [15:05] guarders and building infrastructure [15:08] that makes inner source frictionless for [15:10] engineers. So think of us as a platform [15:13] team for inner source. [15:18] Now let's move on to the main topic. [15:21] When we first began sharing code, we had [15:23] a challenge familiar to many large [15:25] enterprises. [15:27] Hundreds of sc hundreds of existing [15:29] innerosource repositories scattered [15:31] across divisions with no easy way to [15:34] discover them. [15:36] For instance, uh an engineer in division [15:40] A couldn't easily find relevant code [15:42] from division B. Project managers [15:45] couldn't attract contributors from other [15:47] teams and also uh couldn't demonstrate [15:53] uh the value being created from uh [15:56] across the organization. We had the [15:58] infrastructure GitHub enterprise [16:01] but we we lacked uh discoverability and [16:06] connection layer. [16:09] So we stepped back and analyzed our [16:12] stakeholders and their pain points. [16:15] Engineers including myself were wasting [16:18] hours searching for code that might [16:20] already uh exist somewhere and project [16:23] managers overseeing repositories [16:26] uh couldn't uh effectively showcase [16:30] their project to attract contributors [16:33] from other divisions. [16:36] OSPO needed concrete ways to measure and [16:39] demonstrate the inner source value to [16:42] leadership and management wanted to [16:45] achieve uh cross business synergy or [16:48] congarate premium uh through cross [16:51] divisional collaboration. [16:54] These pain points represented a [16:55] systematic gap that existing tools like [16:58] GitHub alone track and chimps couldn't [17:02] freely address. [17:04] Before [17:06] we designed our solution, we looked to [17:09] proven patterns, the inner source [17:11] committee provides inner source patterns [17:14] uh patterns like uh in inner sporter and [17:17] gig marketplace that directly address [17:20] these challenges. [17:23] And of course uh we studied uh [17:27] implementations. [17:28] Bandamo in Japan built backstage based [17:31] portal for multi repository management [17:34] and assess sharing. Airas migrated from [17:37] a simple portal to backstage for [17:39] extensibility. [17:41] These examples uh validated our [17:44] direction. We needed a portal and it [17:47] needed to be extensible. [17:53] Through our direct through our [17:55] stakeholder analysis and studies, we [17:58] realized that the inner source portter [18:01] evolves through three distinct phases [18:04] and this framework can be said to view [18:07] IBM from how perspective. [18:10] The phase one is discovery. This phase [18:13] focuses on cataloging all technical [18:15] assets, mapping skills and expertise and [18:18] find helping people find collaboration [18:20] opportunities. The core question is what [18:23] exists and who's working on it. [18:27] The second phase is connection. This [18:30] phase enables crossdivisional matching [18:32] forming project based teams what we call [18:35] gigus and spreading the inner source [18:39] mindset. The question becomes how do I [18:42] connect with the white people. [18:45] The final phase collaboration [18:48] uh provides project management to a [18:50] contribution visibility for incentives [18:53] and governance automation. The question [18:55] is how do we work together effectively? [18:59] We are currently focused on phase one [19:01] with phase two and three features in our [19:03] backlog. [19:07] Then we started uh with our proof of [19:09] concept using SAP's implementation which [19:12] also uh referenced the inasource [19:15] patterns. [19:17] This gave us two critical benefits. [19:20] First we could deploy quickly and [19:23] validate interest and second employees [19:26] without GitHub enterprise license could [19:29] s uh could s uh discover and explore our [19:33] repositories. [19:36] But as team engaged with it, they wanted [19:38] more a better search uh project health [19:41] indicators and conduct information. [19:44] While predate interest, we needed [19:47] something more extensible as expected. [19:53] This led us to Backstage, the internal [19:55] developer platform framework from [19:57] Spotify, now a CNCF project. We chose [20:00] backstage for three reasons. First [20:03] extensibility [20:05] uh it's plug-in architecture means we [20:07] can start with the uh software catalog [20:11] and add features incrementally. [20:13] Second is community. There is a thriving [20:16] ecosystem of fragments and the proven [20:18] track record in large enterprises [20:23] and third uh active development. [20:26] Backstage is frequently updated and well [20:28] maintained by the community. It's [20:30] relable and we'd love to contribute it. [20:34] Like us uh we recognized the backstage [20:38] extensibility was essential to uh [20:41] provide features we need for our [20:43] organization [20:49] to deliver phase one discovery and [20:51] enable IVCM. [20:54] We built a custom a customized back uh [20:58] software catalog backstage typically [21:01] expects repositories to have catalog [21:04] info. [21:06] But we had hundreds of existing [21:08] repositories owned by different teams [21:10] with no such files. Asking everyone to [21:13] add metadata immediately wasn't [21:15] realistic. So we built custom entity [21:18] provider that generates the catalog [21:20] automatically from our GitHub [21:22] environment. [21:24] This approach also let us add custom [21:27] properties m to our our organization [21:32] uh contact information [21:34] activity scores and uh project uh [21:37] business domain tags [21:41] and we customize front end to surface [21:44] these properties naturally [21:47] uh it's a software catalog tailored [21:49] specifically for Mitsubishi electrics in [21:51] assoc environment [21:53] Then we deployed a customized backstage [21:56] portal uh as a containerized application [22:01] on our AWS account. It's now accessible [22:04] to all employees and of course uh the [22:07] infrastructure and application code for [22:09] this portal are themselves in a source [22:12] within our GitHub. [22:16] So where are we today? Uh phase one [22:18] discovery is now live. Engineers can [22:21] browse uh our catalog uh see activity [22:25] levels and find contacts across [22:28] divisions. We are currently uh gathering [22:31] feedback [22:32] and planning phase two features uh team [22:35] matching and project recruitment boards [22:37] and phase three uh which focuses on [22:40] collaboration remains in our backlog. [22:46] So from a technical perspective, we [22:48] built a customized backstage portal that [22:51] makes inner source discoverable and [22:53] accessible across Mitsubishi electric. [22:56] It this is a a technical foundation for [22:59] IVCM. [23:01] So uh I'll hand it back to for summary. [23:04] Thank you. Back to you. [23:08] Okay. Now I'd like to show how we [23:11] generative AI to make Inosource [23:14] knowledge easier to access. Uh in our [23:17] insource platform we collect not only [23:20] source code but also natural language [23:22] knowledge uh from many GitHub enterprise [23:25] repositories commit logs uh issues and [23:29] pull requests. uh these are converted [23:32] into markdown and stored in one [23:36] aggregated repository uh which is set as [23:39] a lag target inside GitHub compiler [23:43] spaces. As a result, developers can now [23:46] interact freely with GitHub copilot [23:49] chat. Uh in short this system turns out [23:53] in a source into a living knowledge base [23:56] uh where information flows seamlessly [24:00] between [24:02] uh people code and AI. Uh here is a [24:05] sample uh simple s simple example. Uh a [24:09] developer might ask is knowledge related [24:12] to line toing technology for mobile [24:16] robots uh being shared within the [24:18] inosour environment. [24:20] Uh coparot immediately identified the [24:23] light right repositories and summarize [24:28] it contents. [24:30] Even with hundreds of project engineers [24:33] can now find useful knowledge in seconds [24:37] without extra effort. This is how [24:40] generative AI transform insource into [24:42] interactive knowledge ecosystem like [24:45] this. [24:48] Next let's see how all these pieces [24:51] connect or what we call the inour stack [24:54] for calculation. Uh the executives [24:58] expects cut the development lead time by [25:01] half and create innovation through [25:04] synergy across diverse domains to [25:07] achieve the above goals. Uh the concept [25:11] of IBCM is essential as concrete actions [25:15] to realize IBCM. It is necessary to [25:19] build inner source platform and [25:21] communities. The INSOS portal is one of [25:24] the Inosource platforms and realize IBSM [25:29] uh through three phases. In addition, [25:32] the platform provides functions that [25:35] promote knowledge sharing by leveraging [25:38] generative AI. Now let's move to the [25:41] conclusion. Today we introduce the inner [25:44] source value calculation model in uh [25:47] conglomeratic company. Co-creation [25:49] should go beyond implementation sharing. [25:53] Uh it must also include challenge and [25:56] approach sharing. We believe this idea [25:58] also applies to uh single business [26:01] companies. Uh going forward we will [26:04] continue to maximize and visualize the [26:07] value of all three layers aiming for 50% [26:12] reduction in development lead time. I [26:14] look forward to learning from the many [26:16] sessions and discussion throughout this [26:19] summit and to exploring uh together how [26:24] we can shape the future of cocreation. [26:27] Thank you. [26:29] [applause] ## Highlights - So uh next I'd like to explain two roles of our ospo. The first role is promoting innerosource. Uh this means building a internal community and gathering code and knowledge know how into shared repository uh shared repository to attract developers. Uh we are creating a modern development environment. The second law is promoting open source. We ([View Highlight](https://read.readwise.io/read/01kchj7nt88fakrqdy668rgqpw)) - Tags: 👻 ai highlighted - I believe those efforts were not fails. Uh they actually created value not through a common platform, common libraries uh but through discussions that generated variable insights. That is why we are now taking a new approach to cross domain collaboration. We now define the value of calculation ([View Highlight](https://read.readwise.io/read/01kchj7nthmr1zrxvr8vp3tv5a)) - Tags: 👻 ai highlighted - example, we want to shift from a component sales business model to a stock business model like subscription model. Uh the next layer is approach sharing. This means sharing ideas or method to solve those challenges. For example, to achieve that uh stock business model using softwaredefined technology to provide continuous value. ([View Highlight](https://read.readwise.io/read/01kchj7nvdp1v9xpjp7syf78w5)) - Tags: 👻 ai highlighted - guarders and building infrastructure that makes inner source frictionless for engineers. So think of us as a platform team for inner source. Now let's move on to the main topic. When we first began sharing code, we had a challenge familiar to many large enterprises. Hundreds of sc hundreds of existing innerosource repositories scattered ([View Highlight](https://read.readwise.io/read/01kchj7nwcbq1c8w4tc9bqzbt6)) - Tags: 👻 ai highlighted