Yoshitake Kobayashi – Driving InnerSource Way in the Enterprise #InnerSourceSummit2025

Yoshitake Kobayashi – Driving InnerSource Way in the Enterprise #InnerSourceSummit2025 🔗 **Source:** [Yoshitake Kobayashi – Driving InnerSource Way in the Enterprise #InnerSourceSummit2025](https://www.youtube.com/watch?v=-V9bjHmzikk) > [!note]+ Document Notes > tags: [innersource, enterprise, japanese-companies] > author: Yoshitake Kobayashi > source: InnerSource Commons > reference: https://www.youtube.com/watch?v=-V9bjHmzikk > date created: 2025-01-03 12:30 > > # 🏷️ Title: Driving InnerSource Way in the Enterprise >  ## 🧰 Action Inbox - [H1] Define "who is it for" before opening any artifacts — establish clear beneficiaries #innersource - [H2] Start small but open — begin with 2 teams collaboration rather than company-wide #strategy - [H3] Allocate time for documentation using existing exhibition or presentation budgets #management ## 🧭 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) - [InnerSource Learning Path](https://innersourcecommons.org/learn/) ## 📝 Summary - Yoshitake Kobayashi from Toshiba presents practical approaches for implementing InnerSource in traditional enterprise environments - Key insight: "InnerSource Way" focuses on how and why to implement, not just what InnerSource is - Four case studies demonstrate successful InnerSource adoption: Linux distributions, midterm planning, technology catalogs, and grassroots tools - Major risks include lack of clear processes, slow internal response times, and assuming openness automatically creates collaboration - Bottom line: Start small with clear beneficiaries, make processes transparent, and focus on solving common problems ## 📖 Main Content Kobayashi defines "InnerSource Way" as a practical mindset focusing on solving business and technical challenges through open collaboration, distinct from traditional InnerSource definitions that emphasize what it is rather than how to implement it. The presentation addresses common misconceptions about InnerSource implementation, particularly in traditional Japanese enterprises. Key misunderstandings include believing everything must be open, treating InnerSource as an end goal rather than a means, limiting scope to source code only, requiring massive company-wide communities from the start, and assuming contributions will come automatically once artifacts are opened. The speaker presents four detailed case studies from Toshiba demonstrating successful InnerSource adoption across different scenarios, each highlighting specific challenges and solutions for enterprise implementation. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/-V9bjHmzikk?t=0) — [H1] Introduction and motivation for InnerSource - Key idea: Traditional Japanese companies struggle with internal collaboration despite similar challenges - Evidence: "Even they have similar issues, similar challenges, they don't work together" #### ⏱️ [02:30](https://youtu.be/-V9bjHmzikk?t=150) — [H2] Defining InnerSource principles and common misunderstandings - Key idea: InnerSource requires designed openness with clear beneficiaries, not blanket transparency - Evidence: "Openness should be designed based on whose benefit, otherwise nothing happens" #### ⏱️ [05:45](https://youtu.be/-V9bjHmzikk?t=345) — [H3] InnerSource Way framework introduction - Key idea: Focus on practical mindset and approach rather than theoretical principles - Evidence: "InnerSource focusing on what, but InnerSource Way focus on how and why we do it" #### ⏱️ [07:20](https://youtu.be/-V9bjHmzikk?t=440) — [H2] Case study 1: Linux distribution platform - Key idea: Opening internal Linux distribution solved multiple business unit needs and transfer pricing issues - Evidence: "Once we open that, they also created their own products... and they also able to give us feedback" #### ⏱️ [10:15](https://youtu.be/-V9bjHmzikk?t=615) — [H3] Case study 2: Midterm planning transparency - Key idea: Opening strategic planning improved feedback but revealed process gaps - Evidence: "Many feedback from business unit... but internal response was very slow, sometimes over a week" #### ⏱️ [13:00](https://youtu.be/-V9bjHmzikk?t=780) — [H2] Case study 3: Technology catalog development - Key idea: Using markdown and pull requests created maintainable technology documentation - Evidence: "Users sometimes find issues... they ask 'this link is broken,' that makes improvement" #### ⏱️ [15:30](https://youtu.be/-V9bjHmzikk?t=930) — [H3] Case study 4: Grassroots presentation tool - Key idea: Open development during creation builds community and prevents duplicate work - Evidence: "Someone says 'you make this one, I maybe create similar stuff three years ago'" #### ⏱️ [17:45](https://youtu.be/-V9bjHmzikk?t=1065) — [H1] InnerSource Way playbook framework - Key idea: Seven-step framework starting with defining beneficiaries and opening incrementally - Evidence: "First thing is define who is it for, second thing start small but open" #### ⏱️ [19:20](https://youtu.be/-V9bjHmzikk?t=1160) — [H2] Metrics and measurement importance - Key idea: Tracking metrics essential for convincing management and securing budget - Evidence: "You need to track metrics to explain or to convince your boss" #### ⏱️ [20:40](https://youtu.be/-V9bjHmzikk?t=1240) — [H3] InnerSource adoption strategy in Japan - Key idea: Creating external examples helps break internal resistance to change - Evidence: "If Mitsubishi Electric now doing InnerSource... I should say why we don't use InnerSource" #### ⏱️ [22:15](https://youtu.be/-V9bjHmzikk?t=1335) — [H2] Role-based actions for different organizational levels - Key idea: Each organizational level has specific actions to drive InnerSource adoption - Evidence: "If you're a manager, connect teams and share same problems" #### ⏱️ [23:30](https://youtu.be/-V9bjHmzikk?t=1410) — [H3] Call to action for InnerSource Way adoption - Key idea: Start small, focus on creating value beyond individual teams - Evidence: "Take one step with InnerSource Way... create value beyond your team" ## 📚 References - [InnerSource Commons Foundation](https://innersourcecommons.org/) - [InnerSource Patterns](https://patterns.innersourcecommons.org/) - [InnerSource Learning Path](https://innersourcecommons.org/learn/) - [Marp Presentation Tool](https://marp.app/) ## 🗣️ Paraphrase - InnerSource Way emphasizes practical implementation strategies over theoretical principles, focusing on solving real business problems through designed openness rather than blanket transparency - Successful enterprise InnerSource adoption requires starting small with clear beneficiaries, establishing transparent processes, and measuring outcomes to demonstrate value to management - Common implementation failures stem from misunderstanding InnerSource as automatic collaboration rather than structured community building with clear roles and response expectations ## 📰 Newsletter 🚀 **InnerSource Implementation in Traditional Enterprises** Yoshitake Kobayashi from Toshiba shared practical insights on implementing InnerSource in traditional Japanese enterprises, offering a refreshing "InnerSource Way" framework that focuses on how and why rather than what. **Key Learning**: Start small with clear beneficiaries rather than attempting company-wide transformation. Define "who is it for" before opening any artifacts, and design openness based on specific benefits rather than blanket transparency. **Practical Application**: Use the 7-step InnerSource Way playbook: define beneficiaries, start small but open, make transparent, ensure 48-hour response times, define roles, measure and share metrics, and find scaling partners. **WordPress Community Connection**: These principles apply directly to WordPress contribution workflows - defining clear maintainer roles, transparent processes, and measuring community health metrics. Resources: [InnerSource Commons](https://innersourcecommons.org/), [WordPress Contributor Handbook](https://make.wordpress.org/core/handbook/), [Community Team](https://make.wordpress.org/community/) ## ✅ Action Items #### DevRel - Developer advocacy: Create InnerSource success story templates for conference presentations and case study documentation - Education: Develop workshops on "InnerSource Way" mindset vs traditional InnerSource principles, targeting enterprise transformation teams - Developer experience: Design clear beneficiary identification frameworks for evaluating open source project scope and community boundaries - Community management: Establish 48-hour response time SLAs for enterprise open source communities and internal collaboration platforms #### OSPO - Policy & Governance: Draft InnerSource contribution policies based on role-based actions framework (executive, manager, individual contributor levels) - Software Inventory: Create technology catalog templates using markdown and pull request workflows for internal asset documentation - Developer Support: Build training curricula on designed openness vs blanket transparency for internal project management - Community Engagement: Establish metrics tracking frameworks for demonstrating InnerSource value to executive leadership - Strategic Alignment: Develop InnerSource maturity assessments aligned with enterprise transformation objectives and cultural change management #### Community - Maintainers: Create clear product owner and trusted committer role definitions for internal collaboration projects - Contributors: Design grassroots adoption strategies for bottom-up InnerSource community building within traditional organizational structures - Ecosystem: Build cross-project coordination templates for solving common technical challenges through shared asset development #### WordPress - Core: Apply InnerSource Way principles to component team collaboration, focusing on clear beneficiary identification for shared libraries - Community: Develop case studies of successful WordPress InnerSource implementations in enterprise environments - Training: Create lesson plans on enterprise open source adoption using WordPress contribution workflows as practical examples - Documentation: Build enterprise-friendly documentation templates based on technology catalog case study approaches ## 🧪 Hypotheses - Traditional enterprises achieve higher InnerSource adoption rates when starting with technical infrastructure (Linux distributions, shared platforms) rather than process or governance initiatives - Designed openness with clear beneficiaries produces more sustainable collaboration than broad transparency mandates in hierarchical organizations - External success examples from industry peers create stronger internal adoption pressure than theoretical benefits or executive mandates - Role-based action frameworks reduce implementation confusion and accelerate adoption across different organizational levels ### 📊 Methodology - Study design: Compare InnerSource adoption rates between infrastructure-first vs governance-first implementation strategies across similar enterprise environments - Data sources: Track collaboration metrics, response times, and sustained contribution rates across different openness design approaches - Experiments: A/B test role-based vs general InnerSource training programs measuring implementation confidence and actual adoption behaviors ### ❓ Questions - How do cultural factors in traditional enterprises affect optimal InnerSource implementation strategies beyond the Japanese context presented? - What specific metrics best predict long-term InnerSource sustainability in enterprises with strong hierarchical structures? - How can the 48-hour response time expectation be adapted for organizations with different time zones or asynchronous collaboration patterns? ### 🔮 Future Research - Cross-cultural validation of InnerSource Way framework across different enterprise cultures and organizational structures - Longitudinal studies of InnerSource maturity progression using the 7-step playbook in various industry contexts - Integration patterns between InnerSource Way principles and existing enterprise transformation methodologies ### 💡 Implications - Practice: Shift InnerSource implementation focus from policy-driven to benefit-driven approaches with clear stakeholder identification - Policy: Develop role-specific InnerSource governance frameworks rather than one-size-fits-all collaboration mandates - Education: Train enterprise transformation teams on designed openness principles and cultural change management for technical collaboration - Funding: Structure InnerSource budgets around measurable collaboration metrics and cross-team value creation rather than theoretical adoption goals ### 🧠 Learning Styles Assessment Reading level estimate: Flesch-Kincaid Grade Level 8-9 #### 👀 Visual learners - Present: Case study examples, framework diagrams, step-by-step playbook visualization - Improve: InnerSource maturity progression charts, organizational role mapping diagrams, collaboration flow visualizations #### 🔊 Aural learners - Present: Conference presentation format with speaker narration and real-world examples - Improve: 5-minute audio summary of key implementation principles, podcast-format case study discussions #### 🗣️ Verbal learners - Present: Clear terminology definitions, analogies (castle/moat metaphor), practical examples - Improve: Glossary of InnerSource Way terms, comparison tables between traditional vs InnerSource approaches #### 🧩 Kinesthetic learners - Present: Step-by-step playbook framework, practical implementation examples - Improve: Interactive assessment tools for identifying beneficiaries, hands-on workshop templates for role-based planning #### 🧠 Logical learners - Present: 7-step framework progression, cause-and-effect case study analysis, metrics-driven validation - Improve: Decision trees for openness design, ROI calculation frameworks, implementation timeline templates #### 🧑‍🤝‍🧑 Social learners - Present: Community building examples, cross-team collaboration case studies - Improve: Peer mentoring guides for InnerSource champions, discussion prompts for organizational change management #### 🧘‍♀️ Solitary learners - Present: Self-assessment frameworks for organizational readiness, individual case study analysis - Improve: Reflection worksheets on cultural barriers, personal implementation planning templates #### 🌿 Naturalistic learners - Present: Organizational ecosystem thinking, cultural environment analogies - Improve: Systems thinking approaches to enterprise transformation, sustainability metrics for collaboration practices ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear headings, structured case study progression, logical content flow - Improve: Enhanced alt text for framework diagrams, detailed descriptions of visual implementation models #### Keyboard navigation - Present: Standard presentation navigation, accessible video player controls - Improve: Skip links for case study sections, keyboard shortcuts for framework navigation #### Contrast and readability - Present: Standard presentation contrast, clear slide text - Improve: High-contrast mode for framework diagrams, adjustable text sizing for detailed content #### Media and captions - Present: Video presentation with spoken content - Improve: Professional captions for technical terminology, downloadable transcript with timestamps ### 🌍 DEIB Assessment #### Cultural breadth - Present: Specific focus on Japanese enterprise culture, acknowledgment of cultural barriers - Improve: Examples from diverse enterprise cultures, adaptation strategies for different organizational contexts #### Inclusive language - Present: Gender-neutral technical terms, accessible explanations of complex concepts - Improve: Plain-language alternatives for enterprise jargon, cultural sensitivity in organizational change discussions #### Neurodiversity support - Present: Structured framework presentation, clear step-by-step guidance - Improve: Multiple information processing pathways, reduced cognitive load through simplified implementation steps #### Representation - Present: Single cultural perspective with deep expertise, authentic organizational experience - Improve: Diverse case studies from different industries and cultural contexts, varied implementation approaches ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Framework derives logically from identified implementation failures and cultural barriers - Inductive strength: Multiple case studies support general principles about designed openness and incremental adoption - Causal reasoning: Clear connections between cultural factors, implementation approaches, and adoption outcomes - Analogical strength: Castle/moat metaphor effectively illustrates gradual organizational change strategies #### Fallacies - Hasty generalization: Japanese enterprise experience may not generalize to all traditional organizations, requires broader validation - False dichotomy: Presents designed vs blanket openness as binary choice, may overlook hybrid approaches #### Tone of voice - Overall tone: Practical and encouraging with authentic organizational experience, balances optimism with realistic challenge acknowledgment ### 🛡️ DARVO Analysis - Deny: No denial patterns present - Attack: No attack patterns present - Reverse victim/offender: No reversal patterns present - Emotional cues and rhetoric: Positive, solution-focused presentation with authentic vulnerability about implementation challenges ## 🎯 Conclusion The InnerSource Way --- ## Full Transcript [00:06] All right. Uh thank you very much uh to [00:08] attending my session and this is the [00:11] last session for Innosource common [00:13] summit in Yokohama. And now I'd like to [00:16] start my session uh titled driving [00:19] inource way uh in the enterprise and my [00:22] name is Yoske Kobayashi. And let me [00:24] introduce myself first. Uh my name is [00:28] Yoshake just call me Yoshi when you [00:31] talking in English and uh I'm belonging [00:34] uh working for Toshiba but I also have [00:37] several heart uh reading open source [00:40] project uh two open source project and [00:44] one uh project uh creating uh Linux [00:49] uh for sustainable society. We maintain [00:54] uh open source rein more than 10 years [00:57] right so it's very uh kind of [01:04] important project for us for our society [01:08] and uh I also studied the inner source [01:11] activities in Japan um as [01:15] introduced myself uh I translated all [01:19] inource running first and then after [01:22] that uh Yuki uh translated all Inosourus [01:26] patterns. So now uh we work together at [01:30] Inosourus Commons foundations. So this [01:33] is a kind of story why we stay there [01:35] inosource [01:37] and there is some motivations uh why and [01:41] uh start inosource. So from internally [01:45] uh let's say our company as a Japanese [01:50] traditional company. So uh we have a [01:54] very uh old culture and if even they [01:58] have a similar issue similar challenge [02:01] they don't work together. [02:03] I thought why then don't do that and do [02:07] that. So my internal motivation is rest [02:11] shares challenges together. So this is a [02:14] kind of interest from my side. But if I [02:20] look around [02:22] other companies in Japan, maybe they [02:25] also have a similar issues [02:28] and [02:30] but then in globally many companies now [02:34] try to collaborate a lot to provide a [02:37] product or services very quickly. So if [02:40] we continue to have this kind of [02:43] culture, we lost. So this is a sense of [02:48] urgency and why uh this is why I would [02:52] uh introduce inasource in Japan. [02:56] So let me say uh driving innosource in [03:00] the enterprise [03:03] is hard. [03:06] Um maybe you can see here [03:12] conditions may apply. [laughter] [03:15] So yeah it's hard but yeah if you are [03:19] doing inner source effectively [03:22] that makes a lot of benefit for us [03:25] but before doing explaining this kind of [03:28] stuff I would like to uh yeah introduce [03:32] what is inner source maybe you already [03:35] expert for inner source but then yeah [03:38] just uh would like to mainly mention [03:42] about that so the focus uh for The inner [03:45] source is a yeah the practice of [03:47] applying opensource principles inside an [03:50] organizations [03:53] and there is four uh inner source [03:57] principles openness transparency [03:59] prioritize mentorship and voluntary code [04:01] contributions and overall [04:05] we can just say open all artifacts [04:09] welcome visitors this is quite nice [04:14] terminal technology I think [04:17] and that uh yeah originally by adas [04:23] summit 2018 [04:26] but then this uh when you see this u [04:32] terms maybe you can uh imagine something [04:35] like okay now we have many sales inside [04:39] the company so when we introduce in [04:43] source [04:44] many uh collaborations happens. [04:48] So [04:49] it's true but not true. Just introduce [04:54] inner source inside the company no [04:56] actions made. [05:00] So there is many common misunderstanding [05:03] about the inner source. [05:05] First [05:07] u misunderstanding is everything must be [05:10] open. So open all fact artifacts means [05:15] something like everything must be open [05:17] but to effective inner source um benefit [05:22] uh openness should be designed based on [05:25] whose benefit [05:28] otherwise [05:30] nothing happens and second [05:32] misunderstanding is inner source is the [05:35] ultimate goal. [05:37] So now we have innerosource okay uh [05:42] inner source rules inside the company [05:45] okay everyone now collaborate now [05:50] and s mis misunderstanding is it's only [05:53] our source code [05:57] maybe you know documentation or [06:00] templates or scripts anything um [06:03] reusable [06:05] it's uh [06:08] will be become a part of winners I think [06:12] and for misanding is you need a massive [06:15] companywide community. [06:18] So start from everyone [06:22] sometimes [06:24] makes confusion. [06:28] So uh I yeah uh many uh presenter for [06:32] today they also mention start small. [06:35] Yeah, two teams collaboration is already [06:38] insource in action [06:42] and last misunder understanding is if [06:44] you open it contributions will come [06:47] automatically. No, [06:52] I should say no. The contribution [06:54] require clear process transparency and [06:57] psychology safety and also promoting [07:02] otherwise [07:03] no one knows [07:05] this is open. [07:09] So uh that means open all artifacts [07:12] needs more context [07:15] um open widely but with purpose. [07:20] So the goal for open or artifacts means [07:23] ensure when uh new stakeholders join [07:27] there is no barriers or cost to access [07:31] uh asset. [07:34] But so recommended practice is make [07:38] artifacts visible across company [07:41] something like open for everyone but [07:44] yeah this is not ultimate goal. You can [07:47] also open to some limited community. [07:51] But if the community is wider than [07:55] expected, it's already inner source. [08:02] So [08:04] driving inner source in the enterprise [08:07] is difficult. Now I would like to uh [08:10] explain driving in way in the [08:14] enterprise. [08:16] Let me explain uh let me define uh for [08:19] this presentation what is inosource way [08:23] and inasource way I would direct to [08:25] define a practical mindset and approach [08:32] to solve business and technical [08:34] challenges. [08:36] So uh inner source uh focusing on what [08:41] but inner source way focus on how and [08:45] why we do it and the goal is drive [08:50] successful outcomes. [08:53] To get that we should start think about [09:00] when we have some asset who's it for? [09:05] If this uh asset is just by myself that [09:09] is not for inner source but if some [09:13] asset maybe uh useful for other persons [09:19] that is now consider to open to the [09:25] company wise or [09:27] um yeah bound to the other [09:32] teams [09:34] and after open But um yeah you openness [09:38] principle is important. [09:40] So in ideal uh open to everyone is [09:43] ultimate goal but you can start a much [09:46] small uh community and third things [09:50] focus on common issues. So if some uh [09:53] issues or challenges can be uh [09:58] shared to the others and also uh they [10:00] have similar challenges or issues that [10:04] can be uh yeah work together [10:08] and last things in way is build code. [10:15] So focus on the issue is important. This [10:20] is a kind of inner source way start from [10:23] the third point or the inner source way [10:26] approach [10:27] in the morning uh [10:31] uh also uh presented in his presentation [10:35] you can see some triangle in the bottom [10:40] he shows challenges then solutions and [10:44] then implementations. [10:46] So start from issues that uh might be uh [10:51] common for the others. This is the [10:53] starting point for the inner source way. [11:00] So now I'm going to the into some case [11:03] studies I um experienced in maybe uh 15 [11:09] years. [11:10] And first uh I'd like to say um I have a [11:15] experience to promote or to introduce [11:19] opensource software for many kind of [11:22] products [11:24] uh start from a latest machine to the uh [11:29] industrial controller for power plant. [11:32] Yeah, I have 60 or more. Why I did uh I [11:38] can did that is I'm introducing uh open [11:42] source I have common uh platform for the [11:48] for the all uh Toshiba products and that [11:52] was a Linux distributions [11:55] and when uh we created our internal [11:57] distributions we had a private [12:00] environment private repository uh for [12:03] data [12:05] But then yeah when we uh adapt uh this [12:08] kind of distribution to the many uh [12:11] department they want to copy it [12:15] that makes serious issues because uh oh [12:20] sorry [12:21] yeah when they copy it they make [12:24] modifications and they don't give us a [12:27] feedback [12:29] that makes many dialects we cannot [12:32] maintain all of that. [12:35] So we uh decided to open it to all [12:39] department [12:40] and they they our um [12:46] business unit only needs to make a [12:48] configurations to adapt this [12:51] distributions. [12:53] Each embedded systems requires different [12:56] types of packages. [12:59] But this list of packages different but [13:03] some for example security issue is [13:05] common. We'd like to share that. [13:10] So uh once we open that uh they also [13:14] created their own products by own uh [13:18] with business partner [13:22] and they also able to give us a [13:24] feedback. [13:27] So there is some kind of uh issues for [13:30] the transfer pricing or budget or [13:33] something like that [13:35] but this was open source. Um [13:40] so when we develop the yeah uh Linux [13:44] distributions and find some issues [13:48] uh there is a opensource community [13:49] outside the company [13:52] and [13:53] even that product team they can directly [13:57] contribute to opensource community [14:00] by make it open for the uh solutions [14:06] that makes that solve issues for the [14:08] transfer pricing [14:11] because it's open source [14:14] and this is a kind of easiest way but [14:18] yeah I know this is uh really difficult [14:21] for the internal products but this uh [14:25] types of inner source way approach is uh [14:28] quite success inside the company and I [14:31] think now are still a biggest uh success [14:35] in Toshiba. [14:38] So the background was a multiple [14:40] business unit requires a Linux. This is [14:42] a common challenge [14:45] and we did open it and uh we open all uh [14:50] report bug report and uh yeah other [14:53] cases [14:55] uh to open and then uh work with open [14:59] source community to solve many kind of [15:01] issues. [15:04] And second approach is the midterm [15:06] technology development planning. [15:09] Uh probably uh the big company or even [15:12] small companies uh will sometimes try to [15:15] create uh a midterm plan for three years [15:19] or five years something like that and [15:22] our department is kind of a common [15:24] department uh to provide common [15:27] technology to many kind of uh uh [15:30] products. So I thought our midterm plan [15:34] should be shared to the uh other [15:37] business unit when we discussing why we [15:42] when we discussing [15:44] uh for this one because we can get a [15:47] feedback from the business unit easily. [15:51] So I open it first to all business unit [15:57] then post uh something to our corporate [16:01] SNS to PR and after that uh many comment [16:07] and requirement [16:09] uh comes from business unit [16:12] so that's really nice [16:15] but after that [16:17] um I have some success stories and fails [16:23] from positive side. Uh many feedback [16:26] from business unit and that can be [16:29] improve our plan [16:31] and the different perspectives [16:34] helps us uh refine uh priorities or some [16:38] uh unknown issues. So that is kind of a [16:43] yeah good uh point for that. [16:47] But um negative point is uh [16:52] yeah I asked all members [16:57] to do a inasource way but they don't [17:00] know how to do that and my mistake was I [17:05] didn't tell enough how they need to act [17:10] that makes internal response was very [17:14] slow [17:16] uh sometimes over a week without [17:18] reactions [17:20] and [17:21] even they have uh this uh yeah one week [17:26] they discussing internally [17:30] and after they have a solution or they [17:32] have an answer then they open it to the [17:37] uh business unit. [17:41] Maybe the reason why is uh maybe they [17:44] want know they have some um [17:48] aim to do something they don't want to [17:52] change [17:55] this is a kind of issues uh what happens [17:59] so that makes uh [18:03] yeah [18:04] um [18:06] that makes uh yeah that makes less trust [18:10] from the business unit [18:15] and uh third case test case test case uh [18:18] third um [18:20] case study is technology catalog. So as [18:23] I said our department have a common u [18:26] technologies. [18:28] So I try to open our technology as a [18:31] cataro technology cataro and at that [18:34] time I [18:36] I asked all members to write a markdown [18:41] to introduce your technologies to the [18:44] company [18:47] and they are very familiar with uh to [18:51] create repositories and they can just [18:54] send us a pull request. So that is quite [18:58] nice and uh I promote uh technology [19:02] catalog to all users and after that uh [19:06] yeah the users sometimes find some [19:09] issues because our technology and is [19:13] growing growing again sometimes link is [19:16] broken so they ask oh this link is [19:20] broken what happened I'd like to access [19:22] this assets or something like that and [19:25] so that makes improvement for this our [19:27] technology catalog. [19:30] So this is a open uh kind of a yeah [19:33] inner source approach and also AI [19:36] friendly approach [19:38] like that. So at that time um I uh [19:42] defined the product owner and also trust [19:45] commiter uh during our development. [19:49] Uh that makes a clear role and when uh [19:54] they uh yeah make some pull request they [19:58] can ask trusted commit for review and if [20:02] the there is something happens [20:04] uh maybe uh product owner also uh yeah [20:07] responsible for that. [20:10] Um but to make uh this uh kind of uh cut [20:15] also uh takes a time. So I uh allocated [20:21] the time for documentations. [20:25] We use uh by using internal exhibition [20:28] time. Our department have internal [20:32] exhibitions once a year. at that time uh [20:36] they create some kind of panels and they [20:41] uh yeah takes lots of time to make that [20:45] but at that time I said if you make this [20:50] cut you don't need it for to make a [20:54] poster or something we just uh use this [20:59] material for internal marketing [21:02] uh we did a lot of webinar instead of [21:05] the internal exhibition. [21:07] So that is a kind of a yeah success [21:11] stories or that and last one is gross [21:14] root approach and yeah probably uh some [21:20] uh one knows uh map this is a kind of a [21:23] markdown based presentation uh tools. [21:27] Um [21:29] I have a pain point. Um yeah, when I [21:32] want to create text uh based [21:35] presentations, I don't want to use a [21:38] PowerPoint. [21:40] I direct you to use just uh some techies [21:43] to make the presentations. This uh [21:45] opensource map is yeah useful for that. [21:50] So but to use this kind of presentation [21:54] internally internal the company we [21:57] should align with the [22:00] design company design. [22:04] So I created template for presentations [22:08] and make it open to the public uh [22:10] internally. [22:12] This is a actual uh actual run just [22:16] write markdown and you can receive the [22:18] presentations. [22:20] Yeah, something like that. So to promote [22:23] this activity I uh try to open it as [22:27] fast as I can. So I yeah open it um [22:33] during the development and I going to [22:37] some uh activ uh poster exhibitions. [22:40] uh this is a kind of grassroot uh poster [22:43] exhibitions [22:44] and promote this uh approach. Then I [22:48] find many uh yeah users um yeah and [22:54] someone says oh you make this one I [22:59] maybe uh [snorts] create this similar [23:02] stuff three years ago. [23:05] Oh, in that case, yeah, please give me a [23:07] feedback or something. Then I I have a [23:11] community [23:13] or that and now it's stable enough. So [23:16] no many uh contribution will happens but [23:19] some I still have some feedback from [23:21] users. I'm using this template. Thank [23:24] you very much or something like that. [23:28] So [23:30] um so from now I'm going to driving in [23:34] way in the enterprise how we make it [23:36] real. [23:41] This is a inner source way playbook I [23:44] created. [23:45] First thing is define who is it for [23:51] and second thing start small but open [23:56] as you know and third step is make it [23:59] transparent. [24:02] This three step is very important and [24:07] you should follow that [24:10] other four to seven might be useful. Uh [24:16] but for the uh [24:20] yeah if you work just by yourself [24:23] keep in mind I need to reply for 4 48 [24:27] hours something. Yeah this is a kind [24:28] basically [24:31] and uh yeah if you working alone [24:35] you are a product owner and committer [24:38] but if you're a team you need to define [24:41] that. [24:43] So it's depending on the project [24:47] and [24:49] point six is measure share measure and [24:52] share metrics and this is important if [24:56] you want make this inner source product [25:02] uh more useful or more uh no more useful [25:07] but you at that time you need to get [25:10] budget from the company. So you need to [25:15] give the uh you need to track uh metrics [25:20] to explain or to convince your boss [25:24] and last stuff. Yeah, you need to find [25:26] also find some uh friend or partner to [25:31] scale for scale the innosource. So this [25:35] is a framework for the inner source way [25:39] and I also uh would like to introduce [25:43] inner source weight in Japan and my [25:45] strategy is beginning from the inner [25:48] source running past Japanese [25:50] translations [25:52] and uh I also wrote articles on codine [25:56] uh this is a web media [26:00] and uh I also doing uh yeah talks at the [26:03] conference and meetups. [26:08] Do you know why uh I did something like [26:11] that? [26:14] In Japan uh we have a word [26:20] is yeah and I difficult to find the [26:25] right word in English but yeah if you [26:28] want to uh broke this castle [26:33] yeah most is yeah have waters so you [26:38] need to fill all stuffs [26:42] yeah that makes easier [26:45] So [26:46] um like uh Mitsubishi electric now they [26:50] doing inner sauceource [26:53] other companies they also doing a inner [26:56] source I should say why we don't use [26:59] inner sauce [27:02] so this is a my strategy [27:05] to make inner sauce in there [27:10] and there is some uh role based actions [27:14] uh to drive innosource way and if we are [27:17] executives [27:18] uh please allow allocate a budget for [27:22] the inner source products [27:25] that makes very easy to go next steps [27:30] but we usually need no we means I or [27:34] maybe all of you may need to convince [27:39] executives. [27:42] So if you're a manager uh please uh [27:45] connect teams and share same problems [27:49] and once they work together and get they [27:52] get success [27:55] easy to uh convince our executives [27:59] and if you are just a member start small [28:04] and invite others would you like to [28:07] solve this together with inasource way [28:11] that makes small change inside the [28:14] company but if you get some success [28:19] with some metrics [28:21] easy to convince your manager the [28:24] manager also easy to convince your boss [28:30] so uh I'd like to call actions start the [28:33] inner source way take one step with the [28:36] inner source way sync open no no define [28:40] whose benefit sync open share a little [28:42] one create the value beyond your team. [28:48] Um so uh driving in way in the [28:52] enterprise is [28:54] uh challenging but realing and maybe you [28:59] look me [29:00] it's fun. [29:03] So [29:04] uh let's think of and if you find or if [29:09] you have some success story [29:13] please share it to the inner source [29:15] comments and join our activity. [29:19] Thank you very much for your attentions.