Applying InnerSource for DATEV's Shared Frontend Library #InnerSourceSummit2025

Applying InnerSource for DATEV's Shared Frontend Library #InnerSourceSummit2025 🔗 **Source:** [Applying InnerSource for DATEV's Shared Frontend Library #InnerSourceSummit2025](https://www.youtube.com/watch?v=tHzF8reJBIw) > [!note]+ Document Notes > tags: [innersource, frontend-library, enterprise-collaboration] > author: InnerSource Commons > source: YouTube > reference: https://www.youtube.com/watch?v=tHzF8reJBIw > date created: 2025-01-11 15:30 > > # 🏷️ Title: Applying InnerSource for DATEV's Shared Frontend Library #InnerSourceSummit2025 >  ## 🧰 Action Inbox - [H1] Document pilot project early for repeatability — 26 inner source practices documented #documentation - [H2] Measure development speed improvements — 30 days maintainers vs 14 days contributors #metrics - [H3] Build maintainer diversity across departments — grew from 3 to 12 maintainers #governance ## 🧭 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 Summit 2025](https://innersourcecommons.org/) - [Inner Source Patterns](https://patterns.innersourcecommons.org/) ## 📝 Summary - DATEV successfully rebuilt their frontend library using InnerSource practices after an initial failed attempt - The project achieved 99 teams contributing with 314 total contributors over 2.5 years - Key metrics showed faster development cycles and improved knowledge transfer across the organization - Management support and dedicated maintainers were critical success factors - The pilot documented 26 repeatable InnerSource practices for organizational adoption ## 📖 Main Content DATEV, a €1.5 billion German IT services company, shares their journey of successfully implementing InnerSource practices to build a shared frontend library called "Duckle." The presentation covers both failures and successes, providing practical insights for enterprise InnerSource adoption. The company initially attempted InnerSource 10 years ago but failed due to lack of management support and inexperience. A previous frontend library succeeded initially but died when maintainers were reassigned during organizational restructuring in 2020. In 2021, with explicit management support and a dedicated 3-person team, DATEV launched their current InnerSource frontend library project. They documented 26 specific practices aligned with InnerSource Commons patterns and achieved significant measurable outcomes including faster development cycles and broad organizational participation. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/tHzF8reJBIw?t=0) — [H1] Introduction to DATEV and Context - Key idea: DATEV is a major German IT services provider rebuilding frontend library with InnerSource - Evidence: "€1.5 billion turnover, 40,000 members, 850,000 clients, 9,000 employees" #### ⏱️ [02:30](https://youtu.be/tHzF8reJBIw?t=150) — [H2] First InnerSource Attempt Failed - Key idea: Initial InnerSource attempt 10 years ago failed due to lack of support and experience - Evidence: "Stakeholders said 'great idea...but you know at the moment we have a lot of pressure'" #### ⏱️ [03:45](https://youtu.be/tHzF8reJBIw?t=225) — [H3] Previous Library Success Then Failure - Key idea: Earlier frontend library succeeded until maintainers were reassigned in 2020 reorganization - Evidence: "The maintainers got lost...no one cared about the community anymore" #### ⏱️ [04:30](https://youtu.be/tHzF8reJBIw?t=270) — [H1] Management Support Enabled Success - Key idea: 2021 relaunch had explicit management backing and dedicated team resources - Evidence: "Management told me to build up a team with three persons" #### ⏱️ [05:15](https://youtu.be/tHzF8reJBIw?t=315) — [H2] Frontend Library as InnerSource Pilot - Key idea: Duckle designed as both frontend library and InnerSource practice demonstration - Evidence: "Use it as a pilot as a vehicle to demonstrate that inner source practices can work" #### ⏱️ [06:00](https://youtu.be/tHzF8reJBIw?t=360) — [H3] Documented 26 InnerSource Practices - Key idea: Team systematically documented repeatable practices aligned with community patterns - Evidence: "26 inner source practices that are repeatable and that we documented for our colleagues" #### ⏱️ [07:30](https://youtu.be/tHzF8reJBIw?t=450) — [H2] Impressive Contribution Metrics - Key idea: Achieved broad organizational participation with nearly 100 contributing teams - Evidence: "99 teams contributing or 314 contributors...15% of all merge requests come from inner source contributors" #### ⏱️ [08:45](https://youtu.be/tHzF8reJBIw?t=525) — [H1] Maintainer Diversity Achievement - Key idea: Successfully grew maintainer team from 3 to 12 across different departments - Evidence: "We grew the maintainer team from three maintainers in the beginning to 12 maintainers" #### ⏱️ [10:00](https://youtu.be/tHzF8reJBIw?t=600) — [H2] Development Speed Improvements - Key idea: InnerSource contributors resolved issues faster than core maintainers - Evidence: "Maintainers worked on something median it was 30 days...inner source contributor, it was two weeks" #### ⏱️ [11:30](https://youtu.be/tHzF8reJBIw?t=690) — [H3] Episodic vs Habitual Contributors - Key idea: Two-thirds episodic contributors indicate successful "scratch and leave" pattern - Evidence: "One third of those habitual contributors...two thirds of episodic contributors" #### ⏱️ [12:45](https://youtu.be/tHzF8reJBIw?t=765) — [H2] Knowledge Transfer Evidence - Key idea: "Good Samaritan comments" demonstrate active knowledge sharing - Evidence: "23 times in the average month...once a business day actually" #### ⏱️ [14:00](https://youtu.be/tHzF8reJBIw?t=840) — [H3] Passive Documentation Value - Key idea: Old issues continue to be referenced, proving lasting documentation value - Evidence: "Even 100 days, 200 days, 300 days, years after we had the initial discussion" #### ⏱️ [15:30](https://youtu.be/tHzF8reJBIw?t=930) — [H2] Communication Culture Challenges - Key idea: Shifting from synchronous to asynchronous communication required significant cultural change - Evidence: "They told us ah the maintainers of Duck don't want to talk to us" #### ⏱️ [16:45](https://youtu.be/tHzF8reJBIw?t=1005) — [H3] Responsibility Model Confusion - Key idea: Contributors worried about long-term maintenance responsibilities - Evidence: "Am I responsible for it till the end of my life? No, surely not" #### ⏱️ [18:00](https://youtu.be/tHzF8reJBIw?t=1080) — [H1] Success Declaration and Key Takeaways - Key idea: Project succeeded in building library, knowledge transfer, and inspiring other teams - Evidence: "We infected other colleagues with inner source virus...yes it's a success story" ## 📚 References - [InnerSource Commons](https://innersourcecommons.org/) - [InnerSource Patterns](https://patterns.innersourcecommons.org/) - [Apache Software Foundation](https://apache.org/) ## 🗣️ Paraphrase - DATEV's journey demonstrates that InnerSource requires both management support and dedicated maintainers to succeed in large enterprises - Measuring and documenting benefits like faster development cycles and knowledge transfer helps justify InnerSource investments to leadership - Cultural challenges around communication patterns and responsibility models require careful explanation and patience to overcome ## 📰 Newsletter 🎯 **Enterprise InnerSource Success: DATEV's Frontend Library Journey** DATEV, a major German IT services company, just shared compelling evidence that InnerSource can work at scale in traditional enterprises. Their "Duckle" frontend library attracted 314 contributors from 99 teams and delivered measurable improvements in development speed. **Key Success Factors:** - **Management Support**: Essential after previous attempts failed without executive backing - **Dedicated Maintainers**: Grew maintainer team from 3 to 12 across departments for sustainability - **Measurement Focus**: Documented 26 practices and tracked metrics to prove ROI **Practical Benefits Achieved:** - 50% faster issue resolution (14 vs 30 days) - Daily knowledge transfer through "Good Samaritan" comments - Sustainable contribution model with healthy mix of episodic and habitual contributors The presentation includes honest discussion of cultural challenges, particularly around shifting from synchronous to asynchronous communication patterns. Their measurement approach provides a solid template for other organizations building business cases for InnerSource adoption. Resources: [InnerSource Commons](https://innersourcecommons.org/), [InnerSource Patterns](https://patterns.innersourcecommons.org/), [DATEV Case Study](https://www.youtube.com/watch?v=tHzF8reJBIw) ## ✅ Action Items #### OSPO - Policy & Governance: Develop InnerSource practice documentation template based on DATEV's 26 practices - Developer Support: Create maintainer training program addressing evangelism and technical responsibilities - Community Engagement: Establish measurement frameworks for contribution patterns and knowledge transfer - Strategic Alignment: Define KPIs for development speed improvements and maintainer diversity #### Community - Maintainers: Implement maintainer diversity strategies across departments to prevent single points of failure - Contributors: Design contributor onboarding that supports both episodic and habitual participation patterns - Sponsors: Secure explicit management support before launching enterprise InnerSource initiatives ## 🧪 Hypotheses - Management support is necessary but not sufficient for enterprise InnerSource success - Maintainer diversity across organizational units increases project sustainability - Asynchronous communication cultural shift requires deliberate change management - Measuring development speed improvements provides compelling business case for InnerSource investment ### 📊 Methodology - Study design: Longitudinal analysis of contribution patterns and development metrics over 2.5 years - Data sources: GitLab instance data, LDAP organizational data, anonymized with worker council coordination - Analysis approach: Median development times, contribution frequency patterns, reference tracking for passive documentation ### ❓ Questions - How can organizations better predict which developers will become successful maintainers? - What specific interventions help episodic contributors transition to habitual engagement when desired? - How do communication culture changes affect team performance beyond InnerSource projects? ### 🔮 Future Research - Comparative analysis of InnerSource adoption patterns across different organizational cultures - Long-term sustainability study of maintainer diversity approaches - Cross-industry validation of development speed improvement metrics ### 💡 Implications - Practice: InnerSource requires dedicated resources and cultural change management, not just technical infrastructure - Policy: Worker council coordination and privacy considerations are crucial for InnerSource measurement programs - Education: Maintainer role training should explicitly address evangelism and community building responsibilities - Funding: Business case development benefits from systematic measurement of development speed and knowledge transfer ### 🧠 Learning Styles Assessment Reading level estimate: 12th Grade (technical presentation with domain-specific terminology) #### 👀 Visual learners - Present: Contribution graph visualization, timeline charts, statistical presentations - Improve: Process flow diagrams, before/after organizational charts #### 🔊 Aural learners - Present: Conference presentation with speaker narration and audience interaction - Improve: Podcast-format discussion of lessons learned, maintainer interview series #### 🗣️ Verbal learners - Present: Clear definitions of InnerSource terms, analogies to open source practices - Improve: Glossary of enterprise-specific terminology, comparison frameworks #### 🧩 Kinesthetic learners - Present: Real project implementation case study with concrete outcomes - Improve: Implementation checklist, step-by-step maintainer onboarding guide #### 🧠 Logical learners - Present: Clear metrics, timeline progression, cause-effect relationships - Improve: Decision tree for maintainer selection, ROI calculation framework #### 🧑‍🤝‍🧑 Social learners - Present: Conference format with community discussion, team collaboration examples - Improve: Facilitator guide for InnerSource discussion groups, peer review templates #### 🧘‍♀️ Solitary learners - Present: Comprehensive case study for individual analysis - Improve: Self-assessment checklist for InnerSource readiness, reflection prompts #### 🌿 Naturalistic learners - Present: Organizational ecosystem thinking, sustainable maintainer practices - Improve: InnerSource maturity lifecycle models, ecosystem health indicators ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Standard presentation structure with clear headings - Improve: Alt text for contribution graphs, data table alternatives for visualizations #### Keyboard navigation - Present: Video player supports standard keyboard controls - Improve: Slide deck downloadable format, transcript with logical reading order #### Contrast and readability - Present: Standard presentation slides with adequate contrast - Improve: High-contrast version of data visualizations, larger font options #### Text resizing and reflow - Present: Video content maintains readability at zoom levels - Improve: Responsive slide deck format, mobile-optimized viewing #### Media and captions - Present: Full transcript provided for video content - Improve: Professional captions with speaker identification, downloadable transcript #### Forms and interactions - Present: Simple video player interface - Improve: Interactive slide deck with accessible controls ### 🌍 DEIB Assessment #### Cultural breadth - Present: German enterprise context with European business practices - Improve: Multi-regional InnerSource examples, cultural adaptation considerations #### Inclusive language - Present: Professional technical presentation with defined jargon - Improve: Plain language summary, non-native speaker accessibility #### Neurodiversity support - Present: Well-structured presentation with clear sections - Improve: Content outline upfront, consistent slide formatting #### Representation - Present: Two male presenters from same organization - Improve: Diverse speaker perspectives, varied organizational examples #### Psychological safety - Present: Honest discussion of failures and challenges - Improve: Content warnings for organizational change stress, support resources ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear connection between management support and project success - Inductive strength: Solid generalization from specific metrics to broader InnerSource benefits - Causal reasoning: Well-supported claims about maintainer impact on project sustainability - Analogical strength: Effective use of open source practices applied to enterprise context #### Fallacies - Selection bias: Acknowledge that successful teams may tackle different types of issues, potentially skewing development speed metrics - Post hoc reasoning: Correlation between maintainer diversity and project success needs clearer causal mechanism #### Tone of voice - Overall tone: Professional and balanced, acknowledging both successes and failures with appropriate humility ### 🛡️ DARVO Analysis - Deny: No problematic denials present - Attack: No attacks on critics or skeptics - Reverse victim/offender: No reversal patterns detected - Emotional cues and rhetoric: Appropriate enthusiasm balanced with honest self-reflection ## 🎯 Conclusion DATEV's InnerSource journey provides a compelling template for enterprise adoption, demonstrating that success requires management support, dedicated maintainers, systematic measurement, and patience for cultural change. Their documented practices and honest discussion of challenges offer practical --- ## Full Transcript [00:06] Hi everyone and welcome to our talk [00:09] about [00:10] um building up our front-end library [00:12] with the inner source approach. [00:18] So [00:22] I think we have a technical problem with [00:24] the [00:25] >> Oh, let me get Okay. So that's the [00:29] agenda we brought you today. First of [00:32] all, we give you a short context on DATF [00:35] and then I'd like to share my history [00:38] with innersource at Dart with you. After [00:41] that, [00:42] um, Max tells you about our experience [00:46] with building our front-end library with [00:48] the inner source approach. And last but [00:51] not least, we'll have a short look at [00:53] the Royo. [00:56] So, Datiff [00:59] um, Datiff is the IT community for tax [01:02] ad for tax consultants, auditors, and [01:05] lawyers as well as their clients. Dataf [01:08] was built in 1966 [01:11] and it's now one of the largest provider [01:15] of business solutions in Germany as well [01:18] as one of the largest IT service [01:21] provider in Europe. [01:24] Uh we have solutions around uh HR [01:28] management, payroll, [01:31] taxes, [01:33] um public sector [01:36] payroll and so on. [01:38] Let's have a short look at the figures. [01:40] Our turnover last year was about€ 1.5 [01:43] billion euros. We have 40,000 members [01:47] who trust in us, more than 850,000 [01:51] clients who work with our solutions and [01:53] 9,000 employees who work for Datif. [01:57] So I think that's enough about Datiff. [02:00] Let's have a look at inner source [02:02] adaptive and my journey with inner [02:05] source adaptive. [02:07] It started about well 10 years ago. I [02:11] had the requirement to establish a [02:13] conversion service [02:15] conversion service that should be used [02:17] by multiple applications. [02:19] And one day a colleague came to me and [02:22] asked me if I had thought about [02:25] realizing this using the inner source [02:27] approach. No, I haven't thought about [02:30] it. But after that I read a little about [02:33] inner source and I find it very [02:35] interesting and compelling [02:37] uh open up our development for [02:39] contributions from all over the [02:41] organization sounded great to me and [02:45] then I talked to my stakeholders and [02:47] told him about the idea and the answer [02:50] was it's a great idea we absolutely [02:52] should do that. That sounds very good [02:55] but but you know at the moment we have a [02:58] lot of pressure and you know we don't [03:00] have any resources and maybe a later [03:03] time and that's what the text all [03:06] stakeholders told me. So well looking [03:10] back I would say I had no experience [03:12] with insource I didn't know much about [03:15] the success factors and I had no support [03:18] from our management. So I wasn't able to [03:21] convince our stakeholders. [03:23] So was a good idea and I put it into my [03:26] drawer for a later opportunity. [03:30] A few years later other colleagues [03:32] started um inner source project. They [03:36] started building a front-end library [03:37] with inner source and they had great [03:40] maintainers and it was a success. They [03:44] built the inner source library. They had [03:45] a lot of contributions. Everything went [03:47] fine. [03:49] It went fine till about 2020. [03:53] Then our development department was [03:55] completely reorganized [03:58] and the maintainers for the front-end [04:00] library got lost. They didn't really got [04:03] lost, but they took on new [04:04] responsibilities [04:06] and no one cared about the community [04:09] anymore. And self-organization is great, [04:13] but uh for inner source projects, you [04:16] need maintainers who support the [04:17] community. [04:19] who um care for the contributions, who [04:23] care about the quality of the project. [04:25] And if the maintainers are gone, well, [04:28] the contributions decreased and one day [04:32] the library was more or less dead. [04:35] So, one year later, about 2021, [04:41] uh the management realized we need a [04:43] front-end library. And so I was tasked [04:46] with setting up a new front-end library [04:48] and also based on the inner source [04:50] approach. And this time I had the [04:52] support of our management [04:55] and they told me to build up a team with [04:57] three persons [04:59] and build the front-end library with [05:02] them. And that was the time uh Max [05:04] joined the team too. [05:08] And we had a dream. We wanted to prove [05:10] that inner sauce could be a success [05:11] story at Dart. Am I right, Max? [05:15] >> Well, I will tell you right after you [05:17] give me the clicker. Thank you. [05:21] And actually, right after I give you at [05:24] least a little bit of context on that [05:27] front end library or how we call it uh [05:30] our duckle uh for German speakers, [05:32] that's obviously uh the pun is intended. [05:35] Um it is what you think of a front-end [05:39] library to be. It's a library with nice [05:43] and sweet components like buttons or in [05:46] this case form elements. And the thing [05:48] that was special about it uh for me is [05:51] that from the very first moment Enis [05:54] told me think of Duck not only as a [05:57] front-end library that we are going to [05:59] build but also use it as a pilot as a [06:02] vehicle to demonstrate as you said that [06:05] inner source practices can work at [06:08] Datev. [06:10] So [06:12] from the very beginning we we isolated [06:15] and documented carefully what we did. Uh [06:17] in total 26 inner source practices that [06:21] are repeatable and that we documented [06:23] for our colleagues. Now uh don't worry [06:25] I'm not going to read through all of [06:26] them. In fact where's Sebastian? Ah he's [06:29] not there you are. Um most of them there [06:32] is a huge overlap to the inner source [06:34] patterns actually. So the inner source [06:37] patterns community uh is documenting a [06:40] lot of them and sometimes when we [06:41] document it for our colleagues it's [06:43] really just a link to the patterns. Um [06:46] and much of those things it it will be [06:49] very familiar to you after a whole day [06:51] of of inner source here in Berlin. Um of [06:54] course we made sure that we provided [06:56] detailed user documentation so that we [06:59] can win over users and turn [07:33] Ah, no. [07:34] >> Okay, [07:35] >> this one works as well. Now, thank you [07:37] so much. Um, where were we? Of course, [07:40] user documentation because we wanted to [07:42] turn users into contributors and for [07:46] that we have to win over the users [07:48] first. Um, nothing new for you. Of [07:51] course, we provided infrastructure and [07:53] configured our in our case GitLab in a [07:55] way that people could actually [07:56] contribute. Um, and of course, we had [07:59] maintainers or how at the inner source [08:00] commons we sometimes call them trusted [08:02] committers. Um, and yes, we did not only [08:06] provide an infrastructure for a [08:08] synchronous communication, but we also [08:10] tried to incentivize and move people to [08:12] actually use it. Um [08:16] what's um pretty unique for us at dataf [08:21] in this project is that we made sure [08:24] that not only us in the core team would [08:26] be the maintainers but gradually we [08:29] wanted to share this responsibility with [08:32] with colleagues from other teams. We [08:34] borrowed heavily from the Apache [08:36] software foundation and how we set up uh [08:38] those processes and you can believe uh [08:41] in a traditional company this also [08:44] raised some eyebrows in the beginning. [08:47] So [08:49] so much about the context this is our [08:52] neat patchflow graph. So what you see [08:54] here is um all the teams that [08:56] contributed to the front- end project as [08:59] tiny little white boxes and if there is [09:02] a green edge it means they contributed [09:05] code and non-code contributions. If it's [09:08] a gray edge it's only code contributions [09:10] and we were really really happy over the [09:14] years when we collected a total of 99 [09:16] teams contributing or 314 contributors. [09:21] What was a surprise to us is that [09:24] recently a lot of work happens by inner [09:27] source code contributions. So every [09:30] piece of code that goes into this [09:32] project goes through a merge request is [09:34] reviewed. Roughly 15 of all of those uh [09:39] merge requests come from inner source [09:41] contributors. [09:44] So these numbers without context don't [09:48] mean much. Certainly they won't convince [09:51] management. They will just tell you well [09:53] you build a lot of collaboration. What's [09:56] the benefit to me? One thing though that [09:59] I was personally very happy about and [10:01] that's the last bullet point here very [10:03] much in the bottom. Um we grew the [10:05] maintainer team from uh three [10:07] maintainers in the beginning to 12 [10:09] maintainers. And for me it's very [10:13] important um that we achieved something [10:15] that's called maintainer diversity. I [10:18] think it's also an Apache term, isn't [10:19] it? Yes, you're nodding. Um, so in the [10:22] open-source world, maintainer diversity [10:24] means you have maintainers from [10:26] different companies and that means you [10:29] can be certain that not one company is [10:31] calling the shot. Um, we translated that [10:34] to to inner source to mean we wanted to [10:37] have maintainers from different [10:39] departments and this is something we [10:41] gladly achieved. [10:44] So, so much about the context. Now, [10:46] Enis, finally on to your question. Um, [10:49] was it worth it? Um, [10:53] Enus was not the only one asking the [10:55] question. In fact, some people were [10:57] asking us the question and even worse, [10:59] some people were not asking us any [11:00] questions about Inner Source. So, what [11:03] we did is Enis and I and our colleague [11:06] Vincent Ox, we compiled a report with a [11:09] lot of colorful figures where we [11:10] explained everything we learned. We [11:13] explained the benefits we observed and [11:16] also the challenges and the costs we [11:18] observed. And I want to take you through [11:20] a short summary of that. [11:24] Um this is the data overview. Um so it's [11:27] a two and a half uh year period we were [11:29] covering with that report and we [11:31] collected the data mostly from our [11:33] GitLab instance and some organizational [11:35] data from from LDUP. Um what's important [11:39] and what was important to us as well is [11:40] that we from the very beginning [11:42] coordinated very carefully with our [11:44] workers council. Um so we are engineers [11:47] ourselves and we don't want to be uh uh [11:50] having some big brother looking over us. [11:52] So we made sure that we anonymized [11:54] everything carefully and also [11:56] transparently documented if we were not [11:58] able to anonymize something for whatever [12:01] reason. [12:03] The first thing we we analyzed [12:08] the first thing we analyzed was the [12:10] increase in development speed. So this [12:12] is something if you if you look at [12:14] pretty much every piece of literature [12:16] about inner source it's a promise that [12:19] inner source makes increase the [12:21] development speed increase time to [12:22] market. So we were keen to learn [12:25] uh will it will inner source fulfill [12:27] that promise for us and uh so we [12:29] measured what's the typical time from an [12:32] issue being created to a merge request [12:36] being merged and if the maintainers [12:38] worked on something median it was 30 [12:41] days one calendar month. [12:45] So [12:48] come again [12:55] Oh, no. It's it's really just calendar [12:56] days. So, we we counted the weekends as [12:59] well. But good point. Yeah, thanks for [13:00] pointing that out. Um, so when it was [13:03] resolved by an inner source contributor, [13:06] it was much quicker. It was two weeks [13:09] actually. And if we were able to [13:12] convince the person who initially [13:14] submitted the issue that he or she [13:16] should fix that issue theirelves then it [13:19] was even 11 calendar days. And now to be [13:24] honest I I see you all making photos. I [13:26] will tell you a secret. Such numbers can [13:29] of course be skewed by all kinds of [13:31] biases. So for example, one could argue [13:34] and maybe this person would be right um [13:37] that those numbers are skewed because [13:39] maintainers typically take over the [13:41] larger tasks, the more complex tasks. [13:44] And this is probably true and we [13:46] presented this to our colleagues and to [13:48] our management as honestly as we just [13:50] did to you and they were still happy to [13:54] see about those 15 or 11 days because [13:57] this is definitely not the normal median [14:00] speed uh for many large companies. [14:04] Another thing that a lot of our [14:06] colleagues, a lot of our management [14:07] cared about was the flexible assignment [14:10] of developers. Um to to measure that we [14:13] borrowed heavily from the work uh and [14:15] Barcom and her colleagues at University [14:17] of Calgary are doing around habitual and [14:20] episodic volunteering. Um [14:24] episodic volunteers or contributors are [14:27] folks who come into a project, they fix [14:29] what they need and then they also leave [14:31] again. While habituals are those who [14:35] stay in the project, stay engaged in the [14:37] community for a longer period of time [14:39] with a lot of consistency. And what we [14:42] found is that in our project, we have [14:45] onethird of those habitual contributors. [14:48] Great. This made us very happy because [14:51] it seems we're nice people and people [14:53] like to work with us and we don't send [14:55] them away. But we also had twothirds of [14:59] episodic contributors. [15:01] And at first I was, I might say, [15:04] disappointed. I was like, what did we do [15:05] wrong with those people? Why why are [15:07] they leaving us? And what we found out [15:10] is yes, we did some things wrong and we [15:13] of course worked on fixing them. But [15:15] also, it was just they had their itch, [15:18] they scratched it, they moved on. So for [15:20] us that was a clear indication that all [15:23] those things we do in inner source for [15:24] example a well ststructured contributing [15:27] MD actually help people to get up to [15:30] speed to contribute but also to leave [15:32] again when they need [15:34] the knowledge transfer. This is another [15:37] thing we wanted to demonstrate to folks [15:39] and that was mighty difficult to [15:41] measure. Um so we came up with uh what [15:43] we call the good Samaritan comments. So [15:46] whenever a commenter in an issue or [15:49] merge request was not involved in this [15:51] in any way um and also not a maintainer [15:54] of the project but contributed we called [15:57] it a good Samaritan uh commit uh comment [16:00] obviously and we found that those happen [16:03] really really often in the project in [16:06] fact 23 times in the average month. Um [16:10] so that means to going back to the [16:12] business days once a business day [16:14] actually and for us this was at least an [16:18] indication not a proof but an indication [16:21] that knowledge transfer is happening. [16:24] Of course you can't really talk about [16:27] persisting and transferring knowledge [16:29] without coming back to the topic of a [16:31] synchronous communication again. Um [16:34] luckily I don't have to define it to you [16:36] because Isabelle so brilliantly [16:37] brilliantly did that earlier. Um the [16:40] problem for us was it was fairly easy to [16:43] show that passive documentation is [16:45] there. You can just count the number of [16:47] issues or the number of comments. But [16:49] it's difficult to show that it's [16:51] actually useful. And so our assumption [16:55] was it's always useful when you [16:58] reference it when you reference it. And [17:01] we found that um every second week one [17:05] of our at least one month old issues [17:08] would be referenced. Now one month is [17:10] not that old. So we plotted that in a [17:12] histogram here where we have on the uh [17:16] on the yaxis the number of issues or [17:18] merge requests and on the x-axis down [17:21] there the age. And what you can see [17:23] there is that even 100 days, 200 days, [17:26] 300 days, years after we had the initial [17:29] discussion in an issue, we would come [17:31] back and reference it. And [17:36] this for us was yeah substantiation that [17:38] passive documentation is not only there [17:41] but also helpful for us and for our [17:43] colleagues. [17:46] We have a couple of benefits. [17:47] Unfortunately, [17:49] there were also challenges that Enis [17:51] will tell us about once I handed the [17:53] clicker back. [17:58] >> Yeah, you wouldn't have believed us if [17:59] we only told you that there are only [18:01] benefits. So, the challenges [18:05] one challenge was to find the balance [18:08] between a synchronous and synchronous [18:10] communication [18:12] in normal you have a product team. It's [18:14] responsible for one component and if you [18:17] have questions or bugs or whatever, you [18:20] talk to them, call them and talk to [18:22] them, set up a meeting and if that [18:24] happened in our case, we told them um [18:27] could you please open an issue in our [18:29] issue tracker so everyone could read it [18:31] and discuss there and most of the [18:34] colleagues find it very weird at the [18:36] beginning. They told us ah the [18:38] maintainers of Duck don't want to talk [18:40] to us. They are they are a bit strange. [18:43] It needed a lot of explanation to tell [18:45] them why we were doing this to get the [18:48] passive documentation that helps [18:50] everyone and that it's not the point [18:53] that we don't like them or don't want to [18:55] talk to them. [18:58] The next one was the responsibility [19:01] team. If you have a product team, it's [19:04] responsible for a component and if there [19:06] are bugs, well, the product team will [19:09] resolve it [19:11] um early or later. [19:14] In our case, we um provided the library [19:17] as is and if someone uh reported a bug [19:21] to us, we ask nicely um would it be able [19:25] that you fix the bug yourself? [19:29] Uh some colleagues find it great because [19:31] they could help themselves but other [19:34] colleagues were a bit irritated. So um [19:37] should we make you a job now? That also [19:40] needed a lot of explanation. [19:43] And another point about responsibility [19:46] um developers who contributed to Duckle [19:50] were a bit concerned if I make a [19:52] contribution to Duckle now um am I [19:55] responsible for it till the end of my [19:57] life? No, surely not. If the merge [20:00] request is committed, they are free [20:02] again and the maintainers take the rep [20:06] responsibility again. [20:10] And another point was the job of the [20:12] maintainers. [20:14] It's a great part of the job to [20:16] evangelize and internalize [20:19] inner source values and practices in the [20:22] company. It's a lot of work to do this. [20:25] also fill out the maintainer role and [20:28] make the merge requests also a lot of [20:31] work. And if it's developers, they want [20:34] to develop and not only to talk and to [20:39] make presentations, to make merch [20:41] requests. So you need the right kind of [20:44] people who love that kind of job, who [20:46] love to support others, who love to help [20:49] others to be very good maintainers. [20:54] So now we've seen the benefits and the [20:57] challenges [20:58] and the question was it a success? Would [21:01] we do it again? Well, let's look at the [21:04] facts. With this approach, we were able [21:07] to build a front-end library that's now [21:10] widely used in our applications [21:13] and we helped to make the knowledge [21:16] transfer regarding front-end exposes [21:19] across the organization. [21:21] We help teams on delivering the [21:24] requirements and deliver their [21:26] requirements more quickly than had would [21:28] have been possible with a central team. [21:32] And beside that, we learned a lot about [21:34] inner source. What makes Innerosource [21:36] successful? [21:38] What also can get in the way? And we [21:42] also infected other colleagues with [21:44] inner source virus. [21:46] There's another library near Duckle [21:48] which is driven with inner source and [21:51] other colleagues ask us if this would be [21:53] a possibility for their projects. So at [21:56] the end I would say yes it's a success [21:58] story and yes it would I would do it [22:00] again [22:04] and this are the four key takeaways we [22:07] want you to take home with you after [22:09] this day. The first one document your [22:12] pilot early on to make your success [22:14] repeatable. [22:16] Inner source leads to knowledge sharing [22:18] and faster development. [22:21] You can demonstrate inner source [22:22] benefits and return on invest by [22:24] applying simple measurements. And in our [22:27] case, the benefits outweigh the cons. [22:32] So thanks for your attention.