A Frictionless Inner Source Journey #InnerSourceSummit2025

A Frictionless Inner Source Journey #InnerSourceSummit2025 🔗 **Source:** [A Frictionless Inner Source Journey #InnerSourceSummit2025](https://www.youtube.com/watch?v=UzgJM6VKAiE) > [!note]+ Document Notes > tags: [innersource, developer-experience, mercedes-benz] > author: Inner Source Summit > source: YouTube > reference: https://www.youtube.com/watch?v=UzgJM6VKAiE > date created: 2025-01-27 10:30 > > # 🏷️ Title: A Frictionless Inner Source Journey - Mercedes-Benz Experience >  ## 🧰 Action Inbox - [H1] Implement developer feedback loops — continuous improvement process #innersource - [H2] Create recognition models for contributors — motivation and visibility #devrel - [H3] Establish metrics for inner source adoption — measurable outcomes #ospo ## 🧭 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 - [Mercedes-Benz FOSS Manifesto](https://opensource.mercedes-benz.com) - [Inner Source Summit](https://innersourcecommons.org/) ## 📝 Summary - Mercedes-Benz analyzed why their inner source adoption wasn't meeting expectations despite having comprehensive infrastructure - They surveyed developers directly to identify friction points rather than assuming problems - Three types of friction identified: emotional, cognitive, and interactive barriers - Success story: internal time tracking system received 50+ contributions from 12-15 developers - Currently implementing strategic initiatives to reduce friction and improve developer experience ## 📖 Main Content Mercedes-Benz has established comprehensive inner source infrastructure including common platforms (GitHub for Enterprise IT, GitLab for R&D), dedicated training, wiki documentation, inner source licensing, and OSPO consulting hours. However, adoption remained below expectations. Their breakthrough came from directly surveying developers about pain points rather than making assumptions. This revealed systematic issues: scattered information requiring extra effort to navigate, overwhelming processes with too many steps, lack of project visibility, middle management focus on delivery over contribution, absence of feedback loops, no recognition models, and cultural preference for keeping code within teams. The analysis identified three core friction types affecting developers: emotional friction (feeling unrecognized despite effort), cognitive friction (mental overhead of complex processes), and interactive friction (barriers to collaboration between teams). ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/UzgJM6VKAiE?t=0) — [H1] Introduction to Mercedes-Benz inner source reality - Key idea: Inner source appears easy but Mercedes-Benz faces adoption challenges despite infrastructure - Evidence: "Inner Source is easy, right? That's why we're all here. And at Mercedes-Benz, we do things really well." #### ⏱️ [01:30](https://youtu.be/UzgJM6VKAiE?t=90) — [H2] Mercedes-Benz inner source infrastructure overview - Key idea: Comprehensive tooling and processes already established across enterprise - Evidence: "Enterprise IT is mostly on GitHub. R&D colleagues vehicle IT are mainly on GitLab" #### ⏱️ [03:15](https://youtu.be/UzgJM6VKAiE?t=195) — [H1] Success story: Time tracking system inner sourcing - Key idea: Internal time tracking system became successful inner source project with broad participation - Evidence: "North of 50 contributions from 12 or 15 different people, 2 and a half thousand people use this system" #### ⏱️ [05:45](https://youtu.be/UzgJM6VKAiE?t=345) — [H2] Characteristics of promising inner source projects - Key idea: Successful projects solve common pain with company-specific requirements and dedicated maintainers - Evidence: "Common and widespread pain, with company specifics, needs dedicated maintainers and community management" #### ⏱️ [07:30](https://youtu.be/UzgJM6VKAiE?t=450) — [H1] Reality check on inner source expectations - Key idea: Only small percentage of projects succeed, similar to open source patterns - Evidence: "Only about 2% of open source projects are considered successful with skewed distribution" #### ⏱️ [08:15](https://youtu.be/UzgJM6VKAiE?t=495) — [H2] Major stumbling blocks identified - Key idea: Time constraints, departmental metrics, and lack of incentives create barriers - Evidence: "Engineers way too busy, I need to fulfill numbers in my department, no tangible incentives" #### ⏱️ [10:00](https://youtu.be/UzgJM6VKAiE?t=600) — [H1] Developer feedback analysis approach - Key idea: Direct developer surveys revealed systematic friction rather than assumed problems - Evidence: "We went directly to the source. Our developers. We asked them share with us what are the pain areas" #### ⏱️ [11:30](https://youtu.be/UzgJM6VKAiE?t=690) — [H2] Identified friction categories - Key idea: Scattered information, overwhelming processes, poor project visibility, and cultural barriers - Evidence: "Information was scattered, overall process was overwhelming, projects that deserve spotlight not getting it" #### ⏱️ [13:00](https://youtu.be/UzgJM6VKAiE?t=780) — [H1] Three types of human friction - Key idea: Emotional, cognitive, and interactive friction create barriers to participation - Evidence: "I have put in effort but received no recognition, inner source becomes inner stress" #### ⏱️ [14:45](https://youtu.be/UzgJM6VKAiE?t=885) — [H2] Strategic response framework - Key idea: Map frictions to actionable initiatives with measurement and continuous feedback - Evidence: "Simple, scalable and measurable strategic moves with embedded continuous feedback loop" #### ⏱️ [16:00](https://youtu.be/UzgJM6VKAiE?t=960) — [H3] Implementation initiatives in progress - Key idea: New joiner awareness, project showcasing, departmental advocates, and promotional events - Evidence: "New joiners awareness session, shout outs in newsletters, FOSS advocates from each department" #### ⏱️ [17:30](https://youtu.be/UzgJM6VKAiE?t=1050) — [H1] Continuous improvement approach - Key idea: Ongoing feedback gathering and iterative process improvement rather than one-time fixes - Evidence: "We gather feedback, reanalyze it, improve it and this process keeps going" ## 📚 References - [Mercedes-Benz Open Source](https://opensource.mercedes-benz.com) - [Inner Source Commons](https://innersourcecommons.org/) - [Mercedes-Benz FOSS Manifesto](https://opensource.mercedes-benz.com) ## 🗣️ Paraphrase - Mercedes-Benz built comprehensive inner source infrastructure but struggled with low adoption rates despite having all the technical pieces in place - Instead of guessing at problems, they surveyed developers directly and discovered systematic friction points including scattered documentation, overwhelming processes, and lack of recognition - They categorized friction into emotional (feeling unrecognized), cognitive (mental overhead), and interactive (collaboration barriers) types that require different solutions - Their response involves mapping each friction type to specific initiatives while building continuous feedback loops for ongoing improvement ## 📰 Newsletter Mercedes-Benz's inner source journey offers valuable lessons for any organization struggling with adoption despite solid infrastructure. Their key insight: ask developers directly about pain points rather than assuming what's wrong. Their systematic approach of categorizing friction into emotional, cognitive, and interactive types provides a useful framework for diagnosing adoption issues. The emotional friction around lack of recognition particularly resonates - technical solutions can't fix motivation problems. The success story of their time tracking system shows the potential when conditions align: solving common pain with company-specific requirements and dedicated maintainers yielding 50+ contributions from diverse contributors. Most importantly, they treat this as continuous improvement rather than a one-time fix, building feedback loops to catch and address emerging issues. Resources: [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/) ## ✅ Action Items #### DevRel - Developer advocacy: Create showcase events for successful inner source projects with metrics and impact stories - Education: Develop new joiner awareness sessions covering inner source processes and opportunities - Developer experience: Map current documentation scattered across platforms and consolidate into discoverable pathways - Developer marketing: Implement newsletter shout-outs and social recognition for contributions and contributors - Community management: Establish feedback loops through regular surveys and office hours for continuous improvement #### OSPO - Policy & Governance: Review and streamline inner source processes to reduce cognitive load and touchpoints - Community Engagement: Deploy departmental advocates to maintain momentum through management hierarchy - Strategic Alignment: Develop metrics framework for measuring inner source adoption and impact - Developer Support: Create recognition models for contributors addressing emotional friction around visibility #### Community - Maintainers: Identify projects with common pain points, company specifics, and dedicated maintainer capacity - Contributors: Reduce barriers to first contributions through simplified onboarding and clear project discovery - Ecosystem: Build cross-team collaboration mechanisms to break down cultural silos #### WordPress - Core Program Team: Apply friction analysis framework to identify adoption barriers in WordPress contribution processes - Community: Implement recognition systems for core contributors and successful collaboration examples - Documentation: Consolidate scattered contributor information into coherent pathways reducing cognitive load - Meta: Create feedback mechanisms for ongoing assessment of contributor experience and process improvements ## 🧪 Hypotheses - Direct developer surveys reveal more actionable friction points than leadership assumptions about adoption barriers - Emotional friction around recognition has greater impact on contribution rates than technical or process barriers - Middle management focus on departmental metrics creates systematic barriers to cross-team collaboration that require structural solutions - Continuous feedback loops prevent friction from accumulating into disengagement over time ### 📊 Methodology - Developer survey design covering emotional, cognitive, and interactive friction categories - A/B testing of recognition systems measuring contribution rate changes - Longitudinal analysis of projects with dedicated maintainers versus those without community management ### ❓ Questions - How do recognition systems need to vary across different engineering cultures and organizational hierarchies? - What ratio of successful inner source projects justifies the infrastructure investment and community management overhead? - How can departmental metrics be restructured to incentivize cross-team contributions without undermining accountability? ### 🔮 Future Research - Comparative analysis of friction patterns across different organizational sizes and industries - Effectiveness measurement of different recognition models on long-term contributor engagement - Cultural transformation strategies for shifting from team-centric to collaborative development mindsets ### 💡 Implications - Practice: Focus on developer experience and friction reduction rather than just tooling and documentation - Policy: Build feedback loops into governance processes to catch disengagement before it becomes systematic - Security: Inner source adoption can improve security through broader code review when friction barriers are addressed - Education: Training programs must address emotional and social aspects, not just technical processes - Funding: Budget for community management and recognition systems as essential infrastructure, not optional additions ### 🧠 Learning Styles Assessment Reading level estimate: Flesch-Kincaid Grade Level 12 #### 👀 Visual learners - Present: Process diagrams, friction categorization framework, success metrics visualization - Improve: Developer journey maps, before/after process flows, friction impact charts #### 🔊 Aural learners - Present: Conference presentation with speaker explanations and real examples - Improve: Developer interview audio clips, success story podcasts #### 🗣️ Verbal learners - Present: Clear definitions of friction types, analogies to open source patterns, storytelling approach - Improve: Glossary of inner source terminology, comparison frameworks with external benchmarks #### 🧩 Kinesthetic learners - Present: Actionable framework for mapping friction to initiatives, step-by-step survey methodology - Improve: Workshop templates, friction assessment checklists, implementation playbooks #### 🧠 Logical learners - Present: Systematic categorization, metrics framework, cause-and-effect analysis of friction sources - Improve: Decision trees for addressing different friction types, ROI calculations for initiatives #### 🧑‍🤝‍🧑 Social learners - Present: Team collaboration examples, cross-departmental advocate programs, community feedback emphasis - Improve: Peer discussion guides, collaborative assessment workshops, success story sharing formats #### 🧘‍♀️ Solitary learners - Present: Self-assessment frameworks, individual reflection on organizational friction points - Improve: Personal action planning worksheets, individual contributor journey maps #### 🌿 Naturalistic learners - Present: Ecosystem thinking about organizational dynamics, natural patterns in adoption curves - Improve: Organizational ecosystem mapping, natural adoption lifecycle models ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading hierarchy, descriptive presentation content - Improve: Alt text for process diagrams, transcript availability for video content #### Keyboard navigation - Present: Standard presentation navigation - Improve: Keyboard-accessible interactive elements in any digital materials #### Contrast and readability - Present: Standard presentation contrast - Improve: High-contrast versions of framework diagrams, larger text options #### Text resizing and reflow - Present: Scalable presentation format - Improve: Responsive documentation layout, zoom-friendly diagrams #### Media and captions - Present: Video content with transcript provided - Improve: Professional captions, audio descriptions for visual frameworks #### Forms and interactions - Present: Standard survey methodology discussion - Improve: Accessible survey design recommendations, inclusive feedback collection methods ### 🌍 DEIB Assessment #### Cultural breadth - Present: Large multinational corporation perspective, automotive industry context - Improve: Cross-industry examples, varying organizational culture adaptations #### Inclusive language - Present: Professional terminology, respectful framing of developer challenges - Improve: Plain language summaries, cultural context for management hierarchy impacts #### Neurodiversity support - Present: Structured framework, clear categorizations, logical flow - Improve: Multiple information processing pathways, reduced cognitive load examples #### Representation - Present: Focus on developer experience across roles - Improve: Diverse contributor examples, inclusive imagery in materials #### Psychological safety - Present: Emphasis on feedback gathering, non-judgmental approach to friction identification - Improve: Guidelines for safe feedback collection, protection for contributors raising concerns ### ✅ Logical Validity #### Strong reasoning - Inductive strength: Pattern recognition from developer feedback leading to friction categorization framework - Causal reasoning: Clear connections between specific friction types and adoption barriers with measurable outcomes - Analogical strength: Effective comparison to open source success rates providing realistic expectations #### Fallacies - Survivorship bias: Focus on successful time tracking project without discussing failed attempts, weakens generalizability - False dichotomy: "Inner source vs inner stress" oversimplifies complex organizational dynamics requiring nuanced solutions #### Tone of voice - Overall tone: Honest and self-reflective about challenges while maintaining constructive problem-solving approach with appropriate humility about ongoing journey ### 🛡️ DARVO Analysis - Deny: No denial patterns observed - presenters acknowledge shortcomings openly - Attack: No attacks on critics - instead seeks out and values critical feedback - Reverse victim/offender: No reversal patterns - takes responsibility for organizational barriers - Emotional cues and rhetoric: Appropriate use of humor to acknowledge challenges while maintaining professional problem-solving focus ## 🎯 Conclusion Mercedes-Benz's systematic approach to diagnosing inner source adoption challenges offers a replicable framework for organizations struggling despite solid infrastructure. Their key insight - surveying developers directly rather than assuming problems - revealed emotional, cognitive, and interactive friction requiring different solution approaches. The emphasis on continuous feedback loops and measurement makes this a practical model for sustainable improvement rather than one-time fixes. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad Purpose: Stage CEE units that become Literature notes. Split level: H3 ### [H1] Developer friction categorization reveals systematic adoption barriers > [!quote] [A Frictionless Inner Source Journey #Inner --- ## Full Transcript [00:06] Hi everyone. [00:08] So my name is Sim and I am very [00:11] passionate about force. I'll just say [00:13] one line about it. You know I believe [00:16] that force is magic and with this great [00:18] power comes great responsibility and my [00:21] role is spreading this power of magic. [00:25] >> Exactly. Very good. [00:28] Very good. So, Inner Source is easy, [00:32] right? [00:34] That's why we're all here. And at [00:37] Mercedes-Benz, we do things really well. [00:42] Just gauging people's reactions there. [00:48] Okay, we'll talk later. So, we have it [00:51] all figured out. Inner source is easy. [00:53] At Mercedes, we've got it all figured [00:56] out. We have a common inner source [00:58] platform. Okay. Two that means uh [01:03] Mercedes-Benz enterprise IT is mostly on [01:06] GitHub. Uh our R&D colleagues vehicle IT [01:10] are mainly on GitLab and uh vehicle IT [01:14] has some very special prerequisites. you [01:16] know they have um they have uh [01:20] requirements that are very strong with [01:22] regards to safety of course and it's a [01:25] very highly regulated industry uh some [01:27] stuff is not open you know like it's [01:30] internal or secret even so in the [01:33] remainder of this talk I'm going to talk [01:34] about mainly enterprise IT okay uh just [01:38] to be clear so we have an inner source [01:40] process which is wonderful we have [01:45] okay we'll talk. Um, we have an inner [01:48] source process. We have uh uh inner [01:52] source training specially uh dedicated [01:55] for this purpose. We have a wiki [01:57] platform that talks all about inner [02:00] source and open source but has a special [02:02] inner source section. We have an inner [02:04] source license. Uh lots of discussions [02:06] about that back in the day but it's [02:08] there now. It works. Um we have the [02:10] Mercedes-Benz FOS manifesto. If you [02:12] haven't heard of that or don't know it, [02:14] then I encourage you to take a look. Go [02:16] to open source Mercedes-Benz.com, our [02:18] open source landing page, and in the top [02:20] right corner, you'll find a link to it. [02:22] And um Peter Giza has mentioned uh their [02:26] manifesto as well, and several other [02:27] companies have one. And uh in our [02:30] manifesto, there are a few passages with [02:33] regard to innersource. And we have [02:36] consulting hours in our OSPO, our open [02:38] source program office, which also caters [02:40] to inner source, uh twice a week. So our [02:42] engineers uh can come with their [02:44] questions and ask if they have uh if [02:46] anything is unclear. So [02:49] and here is our latest inner source [02:53] success story. Uh this is actually [02:54] really cool. Uh so we have an internal [02:58] time tracking system where every [03:00] employee this is now for Mercedes-Benz [03:02] tech innovation specifically. Um so 2 [03:05] and a half thousand people uh a lot of [03:07] engineers there uh they have to you know [03:10] we put we record our working times. You [03:12] start in the morning you have this break [03:14] and you end your your day at this time. [03:18] And uh we recently were like well at the [03:21] beginning of the year we introduced a [03:23] new system. it was completely revamped [03:25] and introduced and now everybody uses [03:27] this system and uh it wasn't working [03:30] 100% well at first and so people started [03:34] complaining ah and we should do [03:36] something to fix it so we came up with a [03:38] suggestion why don't you insource it you [03:40] know and then people can work on it [03:42] collaboratively and that actually worked [03:45] really nicely so I just spoke to the [03:48] colleagues from uh this time tracking [03:50] tool uh two weeks ago last week or two [03:52] weeks ago And uh they said you know [03:55] really nice we're very grateful you know [03:57] we advised them how to do inner source [04:00] how to you know get all the [04:01] prerequisites done and how to uh work [04:03] the magic and they said so we've gotten [04:07] I I think uh north of 50 contributions [04:13] they got from uh they got code [04:16] contributions and non-code contributions [04:18] you know issues um for for uh all kinds [04:23] of areas also code contributions that's [04:26] obviously quite valuable uh from 12 or [04:30] 15 different people you know not just [04:32] one person but like from different [04:34] people so the team reported you know it [04:37] was additional effort that we had to put [04:39] in um for documentation and for [04:43] onboarding and so forth but it was well [04:45] worth the time and we as the main team [04:48] we learned a lot because again you know [04:50] that's what happens in open source as [04:52] you engage with the community and so in [04:56] this case an internal community and so [04:58] they got other engineers [05:00] uh that came up with pull requests and [05:02] and and code contributions you know [05:04] there was an interaction and so they [05:06] said it was really uh worth it. So very [05:08] good story. Um now here why is it a [05:12] success this particular project because [05:15] if you look for promising inner source [05:17] projects they tend to have these [05:20] characteristics. So uh need to solve a [05:22] common and widespread pain not just [05:25] developer pain but in this case it's [05:27] everybody's pain or demand and everybody [05:30] uses it two and a half thousand people [05:32] uh with company specifics [05:34] because if it's not company specific you [05:36] know you could just open source it but [05:38] this is an internal time tracking system [05:40] that's completely uninteresting for the [05:42] general public. Um and it needs to have [05:45] a team that actually caters to that [05:48] project and takes care of it. So you [05:49] need to have uh one or better at least [05:52] two dedicated maintainers and you need [05:54] to do community management. So we did [05:55] some uh you know articles in the [05:57] internet and we said hey everybody now [05:59] it's inner source please help us and so [06:00] forth. So this is this is really nice. [06:03] Yeah. Uh so as I said in source is easy [06:08] we have it all figured out. [06:11] Yeah. Okay. [06:12] So still um you know it's so in general [06:18] we have some projects that are really [06:19] nice like this one but in general it's [06:22] staying behind its expectations still [06:25] and uh why is that? I mean if you look [06:26] at it uh you need to do some [06:28] expectations management you know it's [06:30] not like [06:33] we're doing inner source now every [06:34] project is inner source and every [06:36] project gets contributions from [06:37] everybody all over the place and so it's [06:39] not that's not how it works and I mean [06:41] obviously you know this um open source [06:43] projects are created for sharing from [06:48] the beginning usually but inner source [06:51] are usually tailored to very specific [06:53] needs and please notice is that only [06:56] about 2% of open source projects are [06:58] considered successful. Yeah. Um with a [07:02] skewed distribution meaning the first.5% [07:04] are hugely more successful than the [07:07] remaining 1.5%. Yeah. Uh this is just an [07:11] estimate and uh remember that about [07:15] 63.48% [07:17] of all statistics are made up on the [07:19] fly. [07:21] And uh so but the thing is you know why [07:23] should this be any different inner [07:24] source? It's not reasonable to expect [07:26] that everything is inner source and is [07:27] successful. So here are some big [07:30] stumbling blocks. The time and [07:31] availability of your engineers. [07:33] Everybody's way too busy. They have to [07:35] meet certain deadlines. Uh I I don't [07:38] have the time to think about your [07:39] problem. Sorry about that. I need to [07:41] fulfill the numbers in my department. [07:42] You know, this is especially a [07:43] management thing. like if you know my [07:47] engineers are working over there then I [07:49] have bad numbers they have good numbers [07:52] but I have to report up you know my [07:54] numbers so I don't really want to you [07:56] know give like hand them out to the [07:59] engineers so that's a problem no [08:01] tangible incentives sim will talk about [08:03] that and the lack of community [08:04] management [08:06] but also adding to these points there [08:10] seems to be a bit of a pain and there [08:13] seems to be some friction [08:15] Yeah. Um, whoops. Wait. Here's a short [08:18] video that we made. It's just like less [08:21] than a minute. [08:23] We used this on um for the announcement [08:25] for this talk. So if you haven't seen it [08:27] uh here [08:29] >> a lot of times when we ask our [08:31] developers why they don't participate [08:32] more in inner source they say [08:37] you know I really like inner source but [08:41] but sometimes it's just too painful. [08:46] What? Too painful? [08:49] Tell us all about it. [08:52] And so [08:54] >> and so we asked developers about the [08:57] struggles that they are facing in our [08:59] current innosource process. It wasn't [09:01] just about rules or rules, but something [09:03] deeper wasn't clicking. Some were aware, [09:06] some were struggling, but some were [09:09] living in a source. [09:11] >> On November 13th at the Inner Source [09:13] Summit, we'll show you what we found on [09:16] our Inner Source journey and how we're [09:18] going about to remove the hassle so that [09:20] the Inner Source is with us. [09:27] So, thanks. [09:31] Heading over to Sim. Uh, we did this [09:33] analysis and she will tell you all about [09:35] it. Here we go. Here's the clicker. [09:44] >> Okay. So we saw all about our idol innos [09:48] state and also that something deeper [09:50] wasn't clicking. [09:53] Innos adoption hadn't grown the way we [09:55] expected. So what we did? We went deep. [10:00] We wanted to not assume what the [10:02] problems could be but we went directly [10:05] to the source. And what was the source? [10:08] Our developers. We asked them share with [10:11] us what are the pain areas that you see [10:14] in our current innosource process and [10:16] they did not hold back. [10:20] So once we gathered everything we sat [10:22] down and categorize this feedback. [10:26] Once we started this we sat we observed [10:29] that there were some patterns and when [10:32] these patterns were repeating it says [10:34] that something is wrong with the system. [10:38] From there on we moved into action [10:40] mapping. We started resolving things [10:44] where we found the pain areas. [10:47] Okay. Do you all want to see what the [10:49] feedback was about? But before that, [10:54] this was it. So when you know the [10:57] process needs a fixing, [11:01] but you would rather be handling the sea [11:04] monsters than dealing with the feedback. [11:06] The amount of feedback that we got [11:08] required time to handle. It was better [11:10] to face the sea monsters than dealing [11:12] with those. [11:16] Okay. So these were the frictions that [11:19] we identified. You know we had all the [11:21] informations, the documentations, the [11:23] trainings, everything was there but all [11:26] of this was scattered. [11:28] Our developers had to put in extra [11:30] effort to identify where to begin with. [11:34] The overall process itself was [11:36] overwhelming. Too many steps, too many [11:39] touch points. [11:42] The projects that deserve the spotlight [11:44] was not getting it. You know, our [11:47] organization embraces innosource and [11:49] open source. [11:51] But this enthusiasm, it fades down the [11:53] hierarchy. The middle managers they are [11:57] focused on the delivery deadlines not on [11:59] the contribution. [12:01] So what happens the place where it [12:05] matters the most this momentum was lost. [12:10] We did not have a feedback loop. [12:13] So if something was not working it stays [12:16] that way. And in this case it doesn't [12:20] mean it is satisfaction it's [12:22] disengagement. [12:24] We do not have a recognition model for [12:26] our contributors [12:29] and most importantly culture. [12:31] You know some teams they prefer to keep [12:34] the code within themselves or even [12:36] contribute beyond their bubbles. They [12:39] just prefer to be within that area. [12:45] Okay. So now we identified what are the [12:48] frictions, what are the pain areas. What [12:50] is the next step? The next step was to [12:53] identify why this pain is caused. [12:57] Because a process is having some pain, [13:00] it translates into human friction. And [13:04] in our case, we identified three [13:06] frictions that was holding our [13:08] developers back. The first one, [13:11] emotional friction. [13:14] So this was about how our developers [13:16] feel when they contribute. [13:19] You know we heard things like I have put [13:21] in effort but I have not received any [13:24] recognition. Nobody sees my effort. [13:28] Isn't it demotivating? [13:30] If motivation is low, no amount of [13:33] documentation can fix that. [13:37] Next up is the cognitive cognitive [13:39] friction. [13:41] So this is the mental effort that is [13:44] required to go through the process [13:46] understand things. [13:49] So this is not inner source it's inner [13:51] stress if you have to go through a lot [13:53] of things. [13:56] Next is about interactive friction. So [13:59] barriers that hinder collaboration and [14:01] communication between teams and [14:03] individuals. [14:08] So now we wanted to make a sense of what [14:10] all these was. So we created some [14:14] strategic moves which was simple, [14:16] scalable and measurable. [14:19] The first step was to map each of these [14:21] frictions into actionable initiatives. [14:25] We just did not want to define in things [14:28] that we were not going to work upon. We [14:30] wanted to have each of this [14:33] having proper implementation framework [14:36] that each of these initiatives could be [14:39] properly measured and held accountable [14:41] that yes this is working and someone is [14:45] already looking into it [14:48] and the most important was embedding a [14:51] continuous feedback loop because [14:55] innosource isn't a one-time initiative [14:57] it's a continuous process and the most [14:59] important thing that we realized was [15:01] that we need to have a continuous [15:04] feedback loop with our developers. If [15:06] they are facing any kind of problems, we [15:09] should be aware about it and we should [15:11] know ways how we can handle it. You [15:14] know, spreading this magic of force is [15:16] also about understanding. Yes, is there [15:18] a problem in the magic? How do I fix it? [15:26] So, let's now have a look at what we are [15:28] doing. [15:30] Let me be transparent. This is a [15:33] journey. So, some of these initiatives [15:36] are in progress, some are in pilot and [15:38] some are in planning. [15:41] We have launched various initiatives [15:43] like [15:44] new joiners awareness session where the [15:47] new joiners are well informed about the [15:49] process so they can be boarded early on. [15:54] Now when there are successful Inosus [15:56] projects we give a shout out to them in [15:58] the in newsletters we have social intra [16:01] pages and even during events we tell [16:05] about these successful NUS projects [16:08] because if that particular team can work [16:10] on an innocus project which is very [16:12] successful why not this team so they get [16:15] inspired too. [16:19] Now we have false advocates from each [16:21] and every department who push this topic [16:24] within their teams within their [16:26] departments and that's how we are [16:28] handling that level of hierarchy where [16:31] the momentum is lost [16:35] and we also held various events like [16:37] first day events which gives us a [16:39] platform to promote inner source [16:41] activities. [16:43] So are we done? Not yet. The rule is [16:47] simple. [16:49] We gather the feedback, reanalyze it, [16:53] improve it and this process keeps going. [16:58] We are solving the friction bit by bit [17:01] and we are reaching closer towards a [17:03] smooth, efficient and impactful [17:05] developer experience. [17:09] You know next time when we see we'll [17:11] tell you about where we are and how how [17:14] far we have achieved. [17:16] Over to you. Thank you. [17:23] >> Thank you. So, uh in summary, um inner [17:27] source is easy, but it's working in [17:30] parts and for some projects, but we're [17:32] not satisfied [17:36] with the overall adoption. And this is [17:38] why we started this. We have also [17:40] created metrics for open-source adoption [17:43] but also for inner source uh to make it [17:46] measurable and visible because you know [17:48] management approaches us and says inner [17:50] source is not working is it I'm like no [17:51] no it's working it's show me you know [17:55] and uh so because uh as Daniel also says [17:59] you know sometimes is uh um if you don't [18:03] have data you're just a person with an [18:04] opinion [18:06] and uh that's very true and so also so [18:09] we need the metrics to prove that right [18:11] that's why we started with them um we [18:12] analyzed our process framework as Sim [18:14] has pointed out around inner source and [18:17] we asked the colleagues what their pains [18:18] are and they gave us the feedback and [18:21] now it's on us to implement the findings [18:23] and make the changes so we cannot [18:26] present to you yet and we have changed [18:28] all of these things and the outcome was [18:30] this we will do that next time all right [18:33] uh but we're in the process of of as Sim [18:35] pointed out you know some things we've [18:37] already done some things we're in the [18:38] process [18:39] uh of doing and then hopefully we'll [18:41] report next time so that that we have [18:44] more inner source and less inner stress. [18:47] Thank you very much.