Ryo Ashikawa – Three points that promoted InnerSource activities #InnerSourceSummit2025

Ryo Ashikawa – Three points that promoted InnerSource activities #InnerSourceSummit2025 🔗 **Source:** [Ryo Ashikawa – Three points that promoted InnerSource activities #InnerSourceSummit2025](https://www.youtube.com/watch?v=OLQ00QHByX4) > [!note]+ Document Notes > tags: [innersource, corporate-culture, engineering-management] > author: Ryo Ashikawa > source: InnerSource Summit 2025 > reference: https://www.youtube.com/watch?v=OLQ00QHByX4 > date created: 2025-01-05 10:30 > > # 🏷️ Title: Three Points That Promoted InnerSource Activities at Nifty Corporation >  ## 🧰 Action Inbox - [H1] Implement contribution practice sessions with 60-minute agenda — 16:45 hands-on format #training - [H2] Create low-barrier contribution workflows using GitHub web UI — 13:20 non-engineers #process - [H3] Establish bi-weekly volunteer meetings for InnerSource promotion — 19:15 governance #community ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [InnerSource Patterns Book](https://patterns.innersourcecommons.org/) - [InnerSource Commons Community](https://innersourcecommons.org/) ## 📝 Summary - Ryo Ashikawa shares how Nifty Corporation successfully implemented InnerSource across 150+ engineers and 1000+ repositories over 3 years - Three key acceleration points: align interests, integrate into workflows, create contributor onboarding - 50% engineer participation achieved through bottom-up culture change rather than top-down mandates - Focus on mutual benefit for contributors and maintainers drives sustainable adoption - Non-engineer participation enabled through GitHub web UI and simplified contribution processes ## 📖 Main Content Nifty Corporation, a traditional Japanese internet service provider established in 1986, transformed their engineering collaboration through strategic InnerSource adoption. With 500 employees and 150+ engineers managing over 1,000 repositories, they faced typical resource management challenges where some teams were overloaded while others had capacity. The transformation began in 2022 when Ashikawa discovered InnerSource as a solution to cross-team collaboration without reorganizing team structures. Rather than implementing top-down mandates, they chose a bottom-up cultural approach, empowering young engineers to champion the initiative while ensuring management recognized InnerSource contributions in performance evaluations. Their success stems from three core principles: ensuring mutual benefit for both contributors and maintainers, seamlessly integrating InnerSource into existing business workflows, and providing structured pathways for first-time contributors. The company now maintains regular contribution practice sessions and has expanded participation beyond engineers to include business staff through simplified GitHub web interfaces. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/OLQ00QHByX4?t=0) — [H1] Introduction and Speaker Background - Key idea: Ryo Ashikawa, 20-year Nifty veteran, focuses on team collaboration and developer productivity - Evidence: "I worked for Nifty Corporation for 20 years. I started as a backend engineer in 2004" #### ⏱️ [02:15](https://youtu.be/OLQ00QHByX4?t=135) — [H1] Nifty Corporation Overview - Key idea: Traditional Japanese internet company with modern engineering practices - Evidence: "Established in 1986... 150+ engineers in about 15 teams managing over 1,000 repositories" #### ⏱️ [04:30](https://youtu.be/OLQ00QHByX4?t=270) — [H2] Initial Motivation and Discovery - Key idea: Resource management problems led to InnerSource discovery as solution - Evidence: "Some teams are busy and some are not... I thought is there any way to do this without changing team composition?" #### ⏱️ [06:45](https://youtu.be/OLQ00QHByX4?t=405) — [H2] Bottom-up Cultural Approach - Key idea: Engineering manager chose grassroots adoption over top-down mandates - Evidence: "I wanted to make a culture that was bottom up. So I choose a young engineer interesting in source" #### ⏱️ [08:20](https://youtu.be/OLQ00QHByX4?t=500) — [H1] Implementation Timeline - Key idea: Three-year progression from discovery to 50% engineer participation - Evidence: "Discovered in 22, started experimental project 2023... now about 50% of engineers contribute" #### ⏱️ [09:45](https://youtu.be/OLQ00QHByX4?t=585) — [H1] First Acceleration Point: Interest Alignment - Key idea: InnerSource works best when both contributors and maintainers benefit - Evidence: "If both contributor and repository maintainers benefit, contribution happens naturally" #### ⏱️ [12:30](https://youtu.be/OLQ00QHByX4?t=750) — [H2] Platform Team Example - Key idea: API permission management demonstrates mutual benefit model - Evidence: "Users can submit pull request to authorize their own use... allows contributor to use API quickly" #### ⏱️ [13:20](https://youtu.be/OLQ00QHByX4?t=800) — [H1] Second Point: Workflow Integration - Key idea: Incorporate InnerSource into established business processes - Evidence: "Business department can directly edit email templates on GitHub with web UI" #### ⏱️ [14:45](https://youtu.be/OLQ00QHByX4?t=885) — [H2] Non-Engineer Participation - Key idea: GitHub web UI enables contributions without command-line knowledge - Evidence: "Even people who can't use git commands can contribute using only a browser" #### ⏱️ [15:30](https://youtu.be/OLQ00QHByX4?t=930) — [H1] Third Point: Contributor Onboarding - Key idea: Structured practice sessions help users become first-time contributors - Evidence: "Small contribution practice session more than 10 people participates every time" #### ⏱️ [16:45](https://youtu.be/OLQ00QHByX4?t=1005) — [H2] Practice Session Structure - Key idea: 60-minute agenda covers theory, hands-on practice, and incentives - Evidence: "What is inner source 5 minutes, hands-on implementation 40 minutes, sticker giveaway 5 minutes" #### ⏱️ [18:00](https://youtu.be/OLQ00QHByX4?t=1080) — [H2] Adaptation Challenges - Key idea: Open source practices need modification for corporate constraints - Evidence: "Contributors can contribute freely in their own time but inside company they are using working hour limits" #### ⏱️ [19:15](https://youtu.be/OLQ00QHByX4?t=1155) — [H1] Governance Structure - Key idea: Volunteer-driven promotion without formal OSPO - Evidence: "Volunteers work together... meet every two weeks to talk about task progress" #### ⏱️ [20:30](https://youtu.be/OLQ00QHByX4?t=1230) — [H1] Future Plans - Key idea: Support both maintainers and contributors while expanding non-engineer participation - Evidence: "Check repositories one by one... suggest inner source ideas to maintainers" ## 📚 References - [InnerSource Patterns Book](https://patterns.innersourcecommons.org/) - [InnerSource Commons Community](https://innersourcecommons.org/) - [Nifty Corporation](https://www.nifty.co.jp/) ## 🗣️ Paraphrase - Nifty Corporation solved cross-team collaboration challenges by adopting InnerSource practices that align contributor and maintainer interests rather than forcing organizational restructuring - Success came from grassroots cultural change supported by management recognition, focusing on mutual benefits and seamless workflow integration rather than top-down mandates - Structured contributor onboarding through practice sessions and simplified GitHub web interfaces enabled participation beyond traditional engineering roles, achieving 50% engineer engagement ## 📰 Newsletter **InnerSource Success: How Nifty Corporation Achieved 50% Engineer Participation** Ryo Ashikawa from Nifty Corporation shared compelling insights on scaling InnerSource across a traditional Japanese internet company. Their three-year journey from resource management struggles to 50% engineer participation offers practical lessons for any organization. **Key Breakthrough:** Focus on mutual benefit rather than forced collaboration. When both contributors and maintainers win, adoption happens naturally. **Practical Applications:** - Enable non-technical staff contributions through GitHub web UI - Run 60-minute practice sessions for first-time contributors - Integrate InnerSource into existing business workflows The bottom-up cultural approach, supported by management recognition in performance reviews, proved more effective than top-down mandates. Resources: [InnerSource Patterns](https://patterns.innersourcecommons.org/), [InnerSource Commons](https://innersourcecommons.org/) ## ✅ Action Items #### DevRel - Developer advocacy: Create InnerSource success story presentations for conferences and meetups - Education: Develop 60-minute contribution workshop curricula based on Nifty's model - Developer experience: Design GitHub web UI contribution workflows for non-engineers - Community management: Establish bi-weekly volunteer coordination meetings #### OSPO - Policy & Governance: Create InnerSource contribution recognition policies for performance reviews - Software Inventory: Audit existing repositories for InnerSource potential using Nifty's criteria - Developer Support: Design practice session programs for first-time contributors - Community Engagement: Connect with InnerSource Commons for knowledge sharing - Strategic Alignment: Define mutual benefit KPIs for contributors and maintainers #### Community - Maintainers: Provide InnerSource readiness assessment templates and contributing file examples - Contributors: Create "good first issue" identification processes and low-barrier entry points - Ecosystem: Facilitate cross-team collaboration without organizational restructuring #### WordPress - Core: Apply InnerSource principles to increase cross-team contributions on Core projects - Community: Adapt contribution practice sessions for WordCamp and meetup formats - Documentation: Develop InnerSource adoption guides for WordPress agencies and enterprises - Meta: Enable business team contributions to .org content through simplified interfaces ## 🧪 Hypotheses - InnerSource adoption accelerates when both contributors and maintainers receive clear, measurable benefits from collaboration - Bottom-up cultural change supported by management recognition is more sustainable than top-down InnerSource mandates - Non-engineer participation increases significantly when contribution barriers are lowered through web-based interfaces - Regular structured practice sessions convert passive users to active contributors more effectively than documentation alone ### 📊 Methodology - Longitudinal study tracking contribution patterns before and after implementing the three acceleration points - A/B testing of top-down versus bottom-up InnerSource introduction approaches across similar organizations - User experience research on GitHub web UI versus command-line contribution workflows for non-technical staff ### ❓ Questions - How does InnerSource contribution quality compare between engineer and non-engineer participants? - What performance review criteria most effectively incentivize sustained InnerSource participation? - Which organizational structures beyond traditional ISPs could benefit from Nifty's three-point model? ### 🔮 Future Research - Measuring long-term sustainability of volunteer-driven InnerSource governance models - Quantifying productivity gains from cross-team collaboration versus traditional siloed development - Exploring cultural adaptation requirements for InnerSource in different organizational contexts ### 💡 Implications - Practice: Organizations can achieve significant InnerSource adoption without formal OSPO structures through volunteer coordination - Policy: Performance review systems must explicitly recognize cross-team contributions to sustain InnerSource culture - Education: Structured onboarding programs are essential for converting users to contributors at scale - Funding: InnerSource initiatives may require minimal budget when leveraging existing tools and volunteer enthusiasm ### 🧠 Learning Styles Assessment Reading level estimate: Flesch-Kincaid Grade Level 8 #### 👀 Visual learners - Present: Contribution network diagrams, timeline charts, organizational structure visuals - Improve: Process flow diagrams for the three acceleration points, before/after comparison charts #### 🔊 Aural learners - Present: Conference presentation format with speaker narration and audience interaction - Improve: Podcast-style case study discussion, audio summary of key practices #### 🗣️ Verbal learners - Present: Clear definitions of InnerSource concepts, analogies to open source practices - Improve: Glossary of Japanese corporate culture terms, comparison tables for different approaches #### 🧩 Kinesthetic learners - Present: 60-minute hands-on practice session template, step-by-step GitHub web UI workflows - Improve: Interactive checklist for assessing InnerSource readiness, simulation exercises #### 🧠 Logical learners - Present: Three-year implementation timeline, cause-and-effect relationship between practices and adoption - Improve: ROI calculations for InnerSource investment, decision trees for contribution scenarios #### 🧑‍🤝‍🧑 Social learners - Present: Community-building emphasis, volunteer coordination model, cross-team collaboration examples - Improve: Discussion guides for implementation planning, peer mentoring frameworks #### 🧘‍♀️ Solitary learners - Present: Individual reflection opportunities through case study analysis - Improve: Self-assessment tools for InnerSource readiness, private journaling prompts #### 🌿 Naturalistic learners - Present: Organic cultural evolution concepts, ecosystem thinking about organizational silos - Improve: Sustainability metrics for long-term adoption, natural growth pattern analogies ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure, descriptive slide content, logical information flow - Improve: Alt text for network diagrams and organizational charts, table headers for timeline data #### Keyboard navigation - Present: Standard presentation navigation, accessible video player controls - Improve: Skip links for long content sections, keyboard shortcuts for timestamp navigation #### Contrast and readability - Present: High contrast slides, readable font sizes in presentation - Improve: Color-blind friendly network diagrams, increased line spacing for dense content #### Text resizing and reflow - Present: Scalable presentation format, responsive video player - Improve: Reflowable transcript format, mobile-optimized reading experience #### Media and captions - Present: Full transcript provided, clear speaker audio - Improve: Closed captions with speaker identification, downloadable SRT files #### Forms and interactions - Present: Standard video playback controls, accessible timestamp links - Improve: Interactive practice session worksheets, accessible feedback forms #### Standards reference - Meets WCAG 2.2 AA for video content with transcript provision ### 🌍 DEIB Assessment #### Cultural breadth - Present: Japanese corporate culture perspective, traditional company transformation story - Improve: Comparative analysis with Western InnerSource implementations, global applicability discussion #### Inclusive language - Present: Gender-neutral role descriptions, accessible technical explanations - Improve: Define Japanese corporate culture terms, avoid cultural assumptions #### Neurodiversity support - Present: Structured presentation format, clear section divisions, predictable information flow - Improve: Content warnings for time pressure discussions, sensory-friendly session alternatives #### Representation - Present: Engineering manager perspective from non-Western technology company - Improve: Include diverse contributor voices, represent various organizational roles #### Psychological safety - Present: Emphasis on volunteer participation, recognition of nervousness and learning - Improve: Address imposter syndrome in contribution, create welcoming community guidelines ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear cause-effect relationships between practices and adoption rates - Inductive strength: Generalizes from specific Nifty examples to broader organizational principles - Causal reasoning: Links bottom-up approach to sustainable cultural change - Analogical strength: Effective parallels between open source and corporate collaboration #### Fallacies - Selection bias: Only presents successful cases without discussing failures, needs balanced examples - Hasty generalization: Assumes 50% participation rate is universally --- ## Full Transcript [00:06] Hello. Hello everyone and Haras [00:11] day. Yay. [00:15] Thank you and thank you for joining my [00:17] session. My name is Rio Ashkawa, [00:20] engineering manager at Nifty Corporation [00:23] in Japan. [00:24] Today I'll share how we started inner [00:27] source at nifty and three key points [00:31] that accelerated it. I hope our story [00:34] gives some hints for your own inner [00:36] source journey. [00:42] Uh quick intro about me. I worked for [00:46] Nifty Corporation for 20 years. [00:50] I started as a backend engineer in 20 [00:53] 2004 and became a scrum master and now I [00:58] work on engineering Malaysia. [01:01] Uh I feel a bit nervous because I uh I [01:06] feel like Katrasan was putting pressure [01:09] Malaysia. [01:11] So my hands were uh just sweaty just [01:15] moment. [01:27] >> There is innocent hero. [01:30] Oh, [01:33] it's all right. You can do it. Thank you [01:35] in hero. [01:37] So [01:42] I focus team collaboration and developer [01:45] productivity [01:46] and that is why inosource matters to me. [01:55] Today's story [01:57] first I'll introduce nifty and what kind [02:00] what kind of company we are. Second I'll [02:04] share our discoveries and efforts for [02:06] inner source. Third, I'll talk about and [02:11] about three points that help inource [02:13] grow in our company. [02:16] Finally, I would like to talk about what [02:19] we are planning to do in the future. [02:30] Welcome to the company is Nifty. [02:35] Nifty Corporation is one of Japan's [02:37] traditional internet companies. We are [02:40] established is uh in 1986 is very old [02:45] and now we are internet service [02:47] provider. [02:49] Our employees is about uh 500s. [02:53] We provide services like internet [02:56] connection and security plus web content [02:59] such as news and point service and so [03:02] on. [03:03] So you can say we are old but flexible [03:07] company always adapting to new [03:10] technology. [03:11] This background help us understand [03:14] legacy systems and modern practices like [03:17] inner source. [03:20] Our [03:24] engineering organization has more than [03:27] 150 engineers in about 15 teams and we [03:30] manage over 1,000 repositories [03:34] and we manage these repository under [03:36] single GitHub organization account. We [03:39] have front end, back end, web and [03:42] customer support system teams or SR and [03:45] QA teams. [03:47] We are looking for a better way to [03:49] collaborate beyond many teams and that [03:52] that led us to inner source. [04:00] Next, let me share the discoveries and [04:02] efforts for inner source. [04:05] Uh in this slides [04:07] in Japanese that means uh let's do our [04:11] best with inner source from here. [04:15] Um please could you after uh repeat [04:18] after me? [04:22] Yeah. [04:24] What a wonderful community I have here. [04:31] Um one of the earliest motivation for [04:33] adopting was that we are having problems [04:37] with resource management. [04:39] Each team is has its own tasks and some [04:43] teams are busy and some are not uh [04:46] depend on time of year. At the time it [04:49] was hard to share tasks or skills or [04:52] help across teams. [04:55] I thought is there any way to do this [04:58] without changing team composition? [05:05] Then I found inner source and eye opener [05:08] for me. I read an article and case [05:12] studies about inner source that inspired [05:15] me. They showed that we can reuse open [05:18] source practices inside the company. I [05:21] first saw the website in this screenshot [05:25] written by mi Mr. Kayashi and Tosha [05:28] Corporation. [05:32] Where is he? [05:43] As has been shown so far, the inner [05:46] patterns book was very helpful. It [05:49] explains how to start begins with [05:52] experimental project then expand [05:55] gradually. [05:56] I really strongly recommend this book if [05:59] you plan to start winners in your [06:01] company. [06:05] As a side story, I'd like to explain how [06:10] uh as an engineering manager, I [06:13] introduced inner source culture to my [06:15] organization. [06:17] As a engineering manager, I was also [06:21] able to introduce inner source in a [06:23] topdown way. However, in the context of [06:28] autonomous collaboration between [06:30] engineers, I wanted to make a culture [06:33] that was bottom up. So, I choose a young [06:36] engineer interesting in a source and [06:39] many field reps to promote it. [06:43] Another thing I focused on the engine [06:46] manager [06:48] uh that was telling other manager to [06:50] properly recognize the successful inner [06:53] source activities in performance [06:55] evaluations. [06:57] In this way, Nifty's inner source was [07:00] able to spread primary through the [07:02] field. [07:07] There is timeline of Nifty's efforts. [07:10] We discovered inosource in 22 and [07:13] started experimental project and 2023 we [07:17] created the guidelines [07:20] and inosource portal. [07:22] In 2024 we joined the inosour common [07:25] community. This community thank you so [07:28] much for finding our company's [07:30] activities. [07:38] More recently, we provide operational [07:40] support to the Inosour Gathering Tokyo [07:43] uh 24 and 25 and now about 50% of our [07:47] engineers contribute [07:50] uh contribute to indust project of our [07:52] company. We are making steady progress. [08:00] This chart shows our contribution [08:02] network as of October 2025. [08:06] Each red circle represents a [08:08] contributor. [08:09] Each blue square represents a [08:11] repository. [08:13] The line shows contribution network that [08:16] go beyond their own teams. [08:19] About 50% of engineers active [08:22] contributors. [08:24] It's a small step but an important one [08:27] for culture. [08:33] Now I'll share three points. The [08:36] accelerated inner source at niftyd [08:39] one [08:40] when interests align inner source [08:43] accelerates [08:45] two incorporate inner source in your [08:47] workflow [08:49] three create a press to jump from user [08:52] to contributor [08:54] now I'll explain it step by step [09:02] first [09:04] in works best when interests align. [09:08] These are case the are cases where [09:12] inosource works well. For example, in [09:14] the figure on the left, these are small [09:18] tools and UTD commands that one person [09:21] have created to make their work a little [09:24] easier. [09:25] Everyone wants to finish their work [09:27] quickly. [09:29] These are the same interest. [09:32] Maybe they want to go home on time to [09:34] play video games and play his his child. [09:39] I don't know if this inner source [09:41] activity also started here [09:44] or in the figure on the right when [09:47] stream aligned teams share the same [09:50] source like a platform team source [09:55] to give a specific and simple example at [09:58] Nifty. The definition file of the of [10:03] user permission for the API is managed [10:06] by platform teams inside the repository [10:10] and then and that users can submit pull [10:13] request to authorize their own use [10:16] through contributions. [10:18] This allows contributor to use the API [10:21] quickly and maintainers only need to [10:24] approve it. [10:29] Next example or in the figure on the [10:32] left I think it it would very uh work [10:35] well if team with the same goal helped [10:38] each others out. However, [10:42] in the figure on the right it doesn't [10:45] work well [10:47] because each teams is working toward a [10:49] different goals. For example, [10:52] differences in business domains [10:54] uh or technology stacks and so on. In [10:58] other words, if both contributor and [11:01] repository maintainers benefit, [11:04] contribution happens naturally. [11:07] If only one side benefits, it doesn't [11:10] work well. So we always ask how can [11:15] contributors and repository maintainers [11:17] both win. I think this is the most [11:21] important thing about source. [11:26] Second, include inner source in daily [11:29] workflows. [11:31] This means [11:33] incorporating inner source practice into [11:35] established business workflows. [11:38] A concrete example. [11:41] A business department can directly edit [11:44] email templates on GitHub with Ubu UI. [11:49] Web UI is important point. [11:52] They don't need they don't need to ask [11:55] engineers for small changes of email [11:58] templates. [12:03] Here's a real example of contributing [12:06] file. We just need to describe how to [12:10] send a rep request with a screenshot in [12:14] the contributing file. So then even [12:17] people who can't use g commands can [12:20] contribute to using only a browser. [12:23] This lowers the barrier and speeds up [12:26] improvements. [12:28] In other words, inner source is no [12:30] longer just for engineers. [12:38] Third, create a press to first time [12:41] contributors. [12:43] In the oss world, it's often said that [12:46] there's a big hurdle when moving from [12:48] user to first time contributor. [12:52] Uh it's the first first step in the [12:55] figure [12:57] and it's the same in inource. [13:00] So we had a small contribution practice [13:03] session more than 10 people participates [13:06] every time and many asked to continue [13:10] regularly. [13:11] It helped users to take their first step [13:14] as a contributors. [13:19] Here is a 60 uh 60 minute agenda of [13:24] the contribution practice session. What [13:27] is inner source? Five minutes. How to [13:30] contribute with contributing file five [13:33] minutes. Explore good first issues of [13:36] the product 5 minutes. Hands- on [13:40] implementation four minutes. Short [13:42] survey and sticker giveaway 5 minutes. [13:48] Uh these stickers are always very [13:50] useful. [13:57] So far I've talked about three points to [14:00] accelerate inner source within the [14:02] organization. [14:04] Uh based on my own experience looking [14:07] back I realized that it's difficult to [14:11] bring everything from open source world [14:14] into an organization as it is. [14:18] There are various constraints. So we [14:21] need to change about our way of thinking [14:24] and find suitable ways adapting [14:26] effectively. [14:28] For example in open source contributors [14:32] can contribute freely in their own time [14:36] but inside the company they are using [14:39] usually working our limits. [14:42] On the other hand, since everyone wants [14:44] to go home on time, people tend to be [14:48] highly interested in improving improving [14:52] work efficiency. [14:54] You know, well, our interests arign [14:57] naturally at this point [15:01] and let's think about how to make [15:03] insource accessible to people who are [15:06] not engineers. [15:08] Furthermore, within the same [15:11] organization, we home the multiple [15:13] business goals and sometimes silos are [15:16] formed. [15:19] But rather than seeing these silos as [15:22] everything negative, [15:24] we can see them are good silos that help [15:27] reduce cognitive load. [15:30] Instead of trying to break them down, [15:33] maybe we should think about how we can [15:36] carry out inner source activities [15:39] effectively in inside the company. [15:47] Finally, I would like to talk about our [15:49] future plans and the effort we are [15:53] making. [15:59] and nifty volunteers work together to [16:03] promote inner source activities within [16:05] the company. We don't have an OSPO and [16:09] or ISPO. [16:11] We meet every two weeks to talk about [16:13] our task progress. [16:16] They are they are the innerource [16:18] officers of Nifty like inner source [16:20] views. Among them there are tech lead [16:24] engineer and also business staff who is [16:27] not engineer. [16:29] They are not here today but I really [16:32] thank them for their help. [16:39] This is our plan until March 2026. [16:44] We are work uh we are working to support [16:46] both repository maintainers and [16:48] contributors [16:50] at nifty. There are more more than 1,000 [16:53] repositories as I mentioned earlier. We [16:56] check the repositories one by one and [16:59] try to find the ones that can grow the [17:03] grow as inner source projects. [17:06] Then we suggest inner source ideas to [17:08] the maintainers. [17:11] We also hold a contribution practice [17:13] session to encourage contributors. As I [17:16] mentioned earlier [17:19] in 2025, we will continue these [17:23] activities [17:25] and we also want to find new ways for [17:28] non-engineers to join inner source [17:30] activities. As I said earlier, we want [17:33] to make inner source practice [17:36] of our daily workflow. [17:38] We believe there are more use case for [17:42] this idea. For example, maybe we can [17:44] apply it to internal document that [17:46] everyone use. [17:55] Thank you so much for listening so far. [17:58] To summarize, [18:00] Nifty started in three three years ago. [18:04] Now about 50% of engineers are [18:07] contributors. [18:08] Three accelerator as well. One, [18:12] innerosource accelerates when interests [18:14] align. Two, incorporating inner source [18:18] into your workflow with non-engineers. [18:22] Three, create a place to jump from user [18:24] to contributors. [18:27] We still have much to do and we'll keep [18:30] sharing our learnings with the [18:31] community. [18:36] Thank you so much for listening. If you [18:39] are interested in these activities, [18:42] please come and talk to me after the [18:43] session. Thank you. [18:47] >> Thank you.  ## 📺 Video ![](https://www.youtube.com/watch?v=OLQ00QHByX4) --- # 📝 Full Notes (Deep-Read Analysis) # 🏷️ Title: Three Points That Promoted InnerSource Activities at Nifty Corporation ## 🧰 Action Inbox - [H1] Implement contribution practice sessions with 60-minute agenda — 16:45 hands-on format #training - [H2] Create low-barrier contribution workflows using GitHub web UI — 13:20 non-engineers #process - [H3] Establish bi-weekly volunteer meetings for InnerSource promotion — 19:15 governance #community ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [InnerSource Patterns Book](https://patterns.innersourcecommons.org/) - [InnerSource Commons Community](https://innersourcecommons.org/) ## 📝 Summary - Ryo Ashikawa shares how Nifty Corporation successfully implemented InnerSource across 150+ engineers and 1000+ repositories over 3 years - Three key acceleration points: align interests, integrate into workflows, create contributor onboarding - 50% engineer participation achieved through bottom-up culture change rather than top-down mandates - Focus on mutual benefit for contributors and maintainers drives sustainable adoption - Non-engineer participation enabled through GitHub web UI and simplified contribution processes ## 📖 Main Content Nifty Corporation, a traditional Japanese internet service provider established in 1986, transformed their engineering collaboration through strategic InnerSource adoption. With 500 employees and 150+ engineers managing over 1,000 repositories, they faced typical resource management challenges where some teams were overloaded while others had capacity. The transformation began in 2022 when Ashikawa discovered InnerSource as a solution to cross-team collaboration without reorganizing team structures. Rather than implementing top-down mandates, they chose a bottom-up cultural approach, empowering young engineers to champion the initiative while ensuring management recognized InnerSource contributions in performance evaluations. Their success stems from three core principles: ensuring mutual benefit for both contributors and maintainers, seamlessly integrating InnerSource into existing business workflows, and providing structured pathways for first-time contributors. The company now maintains regular contribution practice sessions and has expanded participation beyond engineers to include business staff through simplified GitHub web interfaces. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/OLQ00QHByX4?t=0) — [H1] Introduction and Speaker Background - Key idea: Ryo Ashikawa, 20-year Nifty veteran, focuses on team collaboration and developer productivity - Evidence: "I worked for Nifty Corporation for 20 years. I started as a backend engineer in 2004" #### ⏱️ [02:15](https://youtu.be/OLQ00QHByX4?t=135) — [H1] Nifty Corporation Overview - Key idea: Traditional Japanese internet company with modern engineering practices - Evidence: "Established in 1986... 150+ engineers in about 15 teams managing over 1,000 repositories" #### ⏱️ [04:30](https://youtu.be/OLQ00QHByX4?t=270) — [H2] Initial Motivation and Discovery - Key idea: Resource management problems led to InnerSource discovery as solution - Evidence: "Some teams are busy and some are not... I thought is there any way to do this without changing team composition?" #### ⏱️ [06:45](https://youtu.be/OLQ00QHByX4?t=405) — [H2] Bottom-up Cultural Approach - Key idea: Engineering manager chose grassroots adoption over top-down mandates - Evidence: "I wanted to make a culture that was bottom up. So I choose a young engineer interesting in source" #### ⏱️ [08:20](https://youtu.be/OLQ00QHByX4?t=500) — [H1] Implementation Timeline - Key idea: Three-year progression from discovery to 50% engineer participation - Evidence: "Discovered in 22, started experimental project 2023... now about 50% of engineers contribute" #### ⏱️ [09:45](https://youtu.be/OLQ00QHByX4?t=585) — [H1] First Acceleration Point: Interest Alignment - Key idea: InnerSource works best when both contributors and maintainers benefit - Evidence: "If both contributor and repository maintainers benefit, contribution happens naturally" #### ⏱️ [12:30](https://youtu.be/OLQ00QHByX4?t=750) — [H2] Platform Team Example - Key idea: API permission management demonstrates mutual benefit model - Evidence: "Users can submit pull request to authorize their own use... allows contributor to use API quickly" #### ⏱️ [13:20](https://youtu.be/OLQ00QHByX4?t=800) — [H1] Second Point: Workflow Integration - Key idea: Incorporate InnerSource into established business processes - Evidence: "Business department can directly edit email templates on GitHub with web UI" #### ⏱️ [14:45](https://youtu.be/OLQ00QHByX4?t=885) — [H2] Non-Engineer Participation - Key idea: GitHub web UI enables contributions without command-line knowledge - Evidence: "Even people who can't use git commands can contribute using only a browser" #### ⏱️ [15:30](https://youtu.be/OLQ00QHByX4?t=930) — [H1] Third Point: Contributor Onboarding - Key idea: Structured practice sessions help users become first-time contributors - Evidence: "Small contribution practice session more than 10 people participates every time" #### ⏱️ [16:45](https://youtu.be/OLQ00QHByX4?t=1005) — [H2] Practice Session Structure - Key idea: 60-minute agenda covers theory, hands-on practice, and incentives - Evidence: "What is inner source 5 minutes, hands-on implementation 40 minutes, sticker giveaway 5 minutes" #### ⏱️ [18:00](https://youtu.be/OLQ00QHByX4?t=1080) — [H2] Adaptation Challenges - Key idea: Open source practices need modification for corporate constraints - Evidence: "Contributors can contribute freely in their own time but inside company they are using working hour limits" #### ⏱️ [19:15](https://youtu.be/OLQ00QHByX4?t=1155) — [H1] Governance Structure - Key idea: Volunteer-driven promotion without formal OSPO - Evidence: "Volunteers work together... meet every two weeks to talk about task progress" #### ⏱️ [20:30](https://youtu.be/OLQ00QHByX4?t=1230) — [H1] Future Plans - Key idea: Support both maintainers and contributors while expanding non-engineer participation - Evidence: "Check repositories one by one... suggest inner source ideas to maintainers" ## 📚 References - [InnerSource Patterns Book](https://patterns.innersourcecommons.org/) - [InnerSource Commons Community](https://innersourcecommons.org/) - [Nifty Corporation](https://www.nifty.co.jp/) ## 🗣️ Paraphrase - Nifty Corporation solved cross-team collaboration challenges by adopting InnerSource practices that align contributor and maintainer interests rather than forcing organizational restructuring - Success came from grassroots cultural change supported by management recognition, focusing on mutual benefits and seamless workflow integration rather than top-down mandates - Structured contributor onboarding through practice sessions and simplified GitHub web interfaces enabled participation beyond traditional engineering roles, achieving 50% engineer engagement ## 📰 Newsletter **InnerSource Success: How Nifty Corporation Achieved 50% Engineer Participation** Ryo Ashikawa from Nifty Corporation shared compelling insights on scaling InnerSource across a traditional Japanese internet company. Their three-year journey from resource management struggles to 50% engineer participation offers practical lessons for any organization. **Key Breakthrough:** Focus on mutual benefit rather than forced collaboration. When both contributors and maintainers win, adoption happens naturally. **Practical Applications:** - Enable non-technical staff contributions through GitHub web UI - Run 60-minute practice sessions for first-time contributors - Integrate InnerSource into existing business workflows The bottom-up cultural approach, supported by management recognition in performance reviews, proved more effective than top-down mandates. Resources: [InnerSource Patterns](https://patterns.innersourcecommons.org/), [InnerSource Commons](https://innersourcecommons.org/) ## ✅ Action Items #### DevRel - Developer advocacy: Create InnerSource success story presentations for conferences and meetups - Education: Develop 60-minute contribution workshop curricula based on Nifty's model - Developer experience: Design GitHub web UI contribution workflows for non-engineers - Community management: Establish bi-weekly volunteer coordination meetings #### OSPO - Policy & Governance: Create InnerSource contribution recognition policies for performance reviews - Software Inventory: Audit existing repositories for InnerSource potential using Nifty's criteria - Developer Support: Design practice session programs for first-time contributors - Community Engagement: Connect with InnerSource Commons for knowledge sharing - Strategic Alignment: Define mutual benefit KPIs for contributors and maintainers #### Community - Maintainers: Provide InnerSource readiness assessment templates and contributing file examples - Contributors: Create "good first issue" identification processes and low-barrier entry points - Ecosystem: Facilitate cross-team collaboration without organizational restructuring #### WordPress - Core: Apply InnerSource principles to increase cross-team contributions on Core projects - Community: Adapt contribution practice sessions for WordCamp and meetup formats - Documentation: Develop InnerSource adoption guides for WordPress agencies and enterprises - Meta: Enable business team contributions to .org content through simplified interfaces ## 🧪 Hypotheses - InnerSource adoption accelerates when both contributors and maintainers receive clear, measurable benefits from collaboration - Bottom-up cultural change supported by management recognition is more sustainable than top-down InnerSource mandates - Non-engineer participation increases significantly when contribution barriers are lowered through web-based interfaces - Regular structured practice sessions convert passive users to active contributors more effectively than documentation alone ### 📊 Methodology - Longitudinal study tracking contribution patterns before and after implementing the three acceleration points - A/B testing of top-down versus bottom-up InnerSource introduction approaches across similar organizations - User experience research on GitHub web UI versus command-line contribution workflows for non-technical staff ### ❓ Questions - How does InnerSource contribution quality compare between engineer and non-engineer participants? - What performance review criteria most effectively incentivize sustained InnerSource participation? - Which organizational structures beyond traditional ISPs could benefit from Nifty's three-point model? ### 🔮 Future Research - Measuring long-term sustainability of volunteer-driven InnerSource governance models - Quantifying productivity gains from cross-team collaboration versus traditional siloed development - Exploring cultural adaptation requirements for InnerSource in different organizational contexts ### 💡 Implications - Practice: Organizations can achieve significant InnerSource adoption without formal OSPO structures through volunteer coordination - Policy: Performance review systems must explicitly recognize cross-team contributions to sustain InnerSource culture - Education: Structured onboarding programs are essential for converting users to contributors at scale - Funding: InnerSource initiatives may require minimal budget when leveraging existing tools and volunteer enthusiasm ### 🧠 Learning Styles Assessment Reading level estimate: Flesch-Kincaid Grade Level 8 #### 👀 Visual learners - Present: Contribution network diagrams, timeline charts, organizational structure visuals - Improve: Process flow diagrams for the three acceleration points, before/after comparison charts #### 🔊 Aural learners - Present: Conference presentation format with speaker narration and audience interaction - Improve: Podcast-style case study discussion, audio summary of key practices #### 🗣️ Verbal learners - Present: Clear definitions of InnerSource concepts, analogies to open source practices - Improve: Glossary of Japanese corporate culture terms, comparison tables for different approaches #### 🧩 Kinesthetic learners - Present: 60-minute hands-on practice session template, step-by-step GitHub web UI workflows - Improve: Interactive checklist for assessing InnerSource readiness, simulation exercises #### 🧠 Logical learners - Present: Three-year implementation timeline, cause-and-effect relationship between practices and adoption - Improve: ROI calculations for InnerSource investment, decision trees for contribution scenarios #### 🧑‍🤝‍🧑 Social learners - Present: Community-building emphasis, volunteer coordination model, cross-team collaboration examples - Improve: Discussion guides for implementation planning, peer mentoring frameworks #### 🧘‍♀️ Solitary learners - Present: Individual reflection opportunities through case study analysis - Improve: Self-assessment tools for InnerSource readiness, private journaling prompts #### 🌿 Naturalistic learners - Present: Organic cultural evolution concepts, ecosystem thinking about organizational silos - Improve: Sustainability metrics for long-term adoption, natural growth pattern analogies ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure, descriptive slide content, logical information flow - Improve: Alt text for network diagrams and organizational charts, table headers for timeline data #### Keyboard navigation - Present: Standard presentation navigation, accessible video player controls - Improve: Skip links for long content sections, keyboard shortcuts for timestamp navigation #### Contrast and readability - Present: High contrast slides, readable font sizes in presentation - Improve: Color-blind friendly network diagrams, increased line spacing for dense content #### Text resizing and reflow - Present: Scalable presentation format, responsive video player - Improve: Reflowable transcript format, mobile-optimized reading experience #### Media and captions - Present: Full transcript provided, clear speaker audio - Improve: Closed captions with speaker identification, downloadable SRT files #### Forms and interactions - Present: Standard video playback controls, accessible timestamp links - Improve: Interactive practice session worksheets, accessible feedback forms #### Standards reference - Meets WCAG 2.2 AA for video content with transcript provision ### 🌍 DEIB Assessment #### Cultural breadth - Present: Japanese corporate culture perspective, traditional company transformation story - Improve: Comparative analysis with Western InnerSource implementations, global applicability discussion #### Inclusive language - Present: Gender-neutral role descriptions, accessible technical explanations - Improve: Define Japanese corporate culture terms, avoid cultural assumptions #### Neurodiversity support - Present: Structured presentation format, clear section divisions, predictable information flow - Improve: Content warnings for time pressure discussions, sensory-friendly session alternatives #### Representation - Present: Engineering manager perspective from non-Western technology company - Improve: Include diverse contributor voices, represent various organizational roles #### Psychological safety - Present: Emphasis on volunteer participation, recognition of nervousness and learning - Improve: Address imposter syndrome in contribution, create welcoming community guidelines ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear cause-effect relationships between practices and adoption rates - Inductive strength: Generalizes from specific Nifty examples to broader organizational principles - Causal reasoning: Links bottom-up approach to sustainable cultural change - Analogical strength: Effective parallels between open source and corporate collaboration #### Fallacies - Selection bias: Only presents successful cases without discussing failures, needs balanced examples - Hasty generalization: Assumes 50% participation rate is universally --- # 📄 Full Transcript *Auto-generated from YouTube captions · timestamps roughly every 30 seconds · [watch on YouTube](https://www.youtube.com/watch?v=OLQ00QHByX4)* **[00:06]** Hello. Hello everyone and Haras day. Yay. [laughter] Thank you [snorts] and thank you for joining my session. My name is Rio Ashkawa, engineering manager at Nifty Corporation in Japan. Today I'll share how we started inner source at nifty and three key points that accelerated it. I hope our story gives some hints for your own inner **[00:36]** source journey. Uh quick intro about me. I worked for Nifty Corporation for 20 years. I started as a backend engineer in 20 2004 and became a scrum master and now I work on engineering Malaysia. Uh I feel a bit nervous because I uh I **[01:06]** feel like Katrasan was putting pressure Malaysia. So my hands were uh just sweaty just moment. >> There is innocent hero. [laughter] Oh, it's all right. You can do it. Thank you in hero. **[01:37]** So >> [snorts] >> I focus team collaboration and developer productivity and that is why inosource matters to me. Today's story first I'll introduce nifty and what kind what kind of company we are. Second I'll share our discoveries and efforts for inner source. Third, I'll talk about and **[02:11]** about three points that help inource grow in our company. Finally, I would like to talk about what we are planning to do in the future. Welcome to the company is Nifty. Nifty Corporation is one of Japan's traditional internet companies. We are established is uh in 1986 is very old **[02:45]** and now we are internet service provider. Our employees is about uh 500s. We provide services like internet connection and security plus web content such as news and point service and so on. So you can say we are old but flexible company always adapting to new technology. This background help us understand legacy systems and modern practices like **[03:17]** inner source. Our engineering organization has more than 150 engineers in about 15 teams and we manage over 1,000 repositories and we manage these repository under single GitHub organization account. We have front end, back end, web and customer support system teams or SR and QA teams. **[03:47]** We are looking for a better way to collaborate beyond many teams and that that led us to inner source. Next, let me share the discoveries and efforts for inner source. Uh in this slides in Japanese that means uh let's do our best with inner source from here. Um please could you after uh repeat **[04:18]** after me? Yeah. [laughter] What a wonderful community I have here. Um one of the earliest motivation for adopting was that we are having problems with resource management. Each team is has its own tasks and some teams are busy and some are not uh depend on time of year. At the time it **[04:49]** was hard to share tasks or skills or help across teams. I thought is there any way to do this without changing team composition? Then I found inner source and eye opener for me. I read an article and case studies about inner source that inspired me. They showed that we can reuse open source practices inside the company. I **[05:21]** first saw the website in this screenshot written by mi Mr. Kayashi and Tosha Corporation. Where is he? [laughter] >> [snorts] >> As has been shown so far, the inner patterns book was very helpful. It explains how to start begins with **[05:52]** experimental project then expand gradually. I really strongly recommend this book if you plan to start winners in your company. As a side story, I'd like to explain how uh as an engineering manager, I introduced inner source culture to my organization. As a engineering manager, I was also able to introduce inner source in a **[06:23]** topdown way. However, in the context of autonomous collaboration between engineers, I wanted to make a culture that was bottom up. So, I choose a young engineer interesting in a source and many field reps to promote it. Another thing I focused on the engine manager uh that was telling other manager to properly recognize the successful inner source activities in performance **[06:55]** evaluations. In this way, Nifty's inner source was able to spread primary through the field. There is timeline of Nifty's efforts. We discovered inosource in 22 and started experimental project and 2023 we created the guidelines and inosource portal. In 2024 we joined the inosour common **[07:25]** community. This community thank you so much for finding our company's activities. [snorts] More recently, we provide operational support to the Inosour Gathering Tokyo uh 24 and 25 and now about 50% of our engineers contribute uh contribute to indust project of our company. We are making steady progress. **[08:00]** This chart shows our contribution network as of October 2025. Each red circle represents a contributor. Each blue square represents a repository. The line shows contribution network that go beyond their own teams. About 50% of engineers active contributors. It's a small step but an important one for culture. **[08:33]** Now I'll share three points. The accelerated inner source at niftyd one when interests align inner source accelerates two incorporate inner source in your workflow three create a press to jump from user to contributor now I'll explain it step by step first **[09:04]** in works best when interests align. These are case the are cases where inosource works well. For example, in the figure on the left, these are small tools and UTD commands that one person have created to make their work a little easier. Everyone wants to finish their work quickly. These are the same interest. Maybe they want to go home on time to **[09:34]** play video games and play his his child. I don't know if [snorts] this inner source activity also started here or in the figure on the right when stream aligned teams share the same source like a platform team source to give a specific and simple example at Nifty. The definition file of the of user permission for the API is managed **[10:06]** by platform teams inside the repository and then and that users can submit pull request to authorize their own use through contributions. This allows contributor to use the API quickly and maintainers only need to approve it. Next example or in the figure on the left I think it it would very uh work well if team with the same goal helped **[10:38]** each others out. However, in the figure on the right it doesn't work well because each teams is working toward a different goals. For example, differences in business domains uh or technology stacks and so on. In other words, if both contributor and repository maintainers benefit, contribution happens naturally. If only one side benefits, it doesn't **[11:10]** work well. So we always ask how can contributors and repository maintainers both win. I think this is the most important thing about source. Second, include inner source in daily workflows. This means incorporating inner source practice into established business workflows. A concrete example. **[11:41]** A business department can directly edit email templates on GitHub with Ubu UI. Web UI is important point. They don't need they don't need to ask engineers for small changes of email templates. Here's a real example of contributing file. We just need to describe how to send a rep request with a screenshot in **[12:14]** the contributing file. So then even people who can't use g commands can contribute to using only a browser. This lowers the barrier and speeds up improvements. In other words, inner source is no longer just for engineers. Third, create a press to first time contributors. In the oss world, it's often said that **[12:46]** there's a big hurdle when moving from user to first time contributor. Uh it's the first first step in the figure and it's the same in inource. So we had a small contribution practice session more than 10 people participates every time and many asked to continue regularly. It helped users to take their first step as a contributors. **[13:19]** Here is a 60 uh 60 minute agenda of the contribution practice session. What is inner source? Five minutes. How to contribute with contributing file five minutes. Explore good first issues of the product 5 minutes. Hands- on implementation four minutes. Short survey and sticker giveaway 5 minutes. Uh these stickers are always very **[13:50]** useful. >> [snorts] >> So far I've talked about three points to accelerate inner source within the organization. [snorts] Uh based on my own experience looking back I realized that it's difficult to bring everything from open source world into an organization as it is. There are various constraints. So we **[14:21]** need to change about our way of thinking and find suitable ways adapting effectively. For example in open source contributors can contribute freely in their own time but inside the company they are using usually working our limits. On the other hand, since everyone wants to go home on time, people tend to be highly interested in improving improving **[14:52]** work efficiency. You know, [clears throat] well, our interests arign naturally at this point and let's think about how to make insource accessible to people who are not engineers. Furthermore, within the same organization, we home the multiple business goals and sometimes silos are formed. But rather than seeing these silos as **[15:22]** everything negative, we can see them are good silos that help reduce cognitive load. Instead of trying to break them down, maybe we should think about how we can carry out inner source activities effectively in inside the company. Finally, I would like to talk about our future plans and the effort we are **[15:53]** making. and nifty volunteers work together to promote inner source activities within the company. We don't have an OSPO and or ISPO. We meet every two weeks to talk about our task progress. They are they are the innerource officers of Nifty like inner source views. Among them there are tech lead **[16:24]** engineer and also business staff who is not engineer. They are not here today but I really thank them for their help. This is our plan until March 2026. We are work uh we are working to support both repository maintainers and contributors at nifty. There are more more than 1,000 repositories as I mentioned earlier. We **[16:56]** check the repositories one by one and try to find the ones that can grow the grow as inner source projects. Then we suggest inner source ideas to the maintainers. We also hold a contribution practice session to encourage contributors. As I mentioned earlier in 2025, we will continue these activities and we also want to find new ways for **[17:28]** non-engineers to join inner source activities. As I said earlier, we want to make inner source practice of our daily workflow. We believe there are more use case for this idea. For example, maybe we can apply it to internal document that everyone use. Thank you so much for listening so far. To summarize, **[18:00]** Nifty started in three three years ago. Now about 50% of engineers are contributors. Three accelerator as well. One, innerosource accelerates when interests align. Two, incorporating inner source into your workflow with non-engineers. Three, create a place to jump from user to contributors. We still have much to do and we'll keep **[18:30]** sharing our learnings with the community. Thank you so much for listening. If you are interested in these activities, please come and talk to me after the session. Thank you. >> Thank you.