Isabel Drost-Fromm – Open communication for open development #InnerSourceSummit2025

Isabel Drost-Fromm – Open communication for open development #InnerSourceSummit2025 🔗 **Source:** [Isabel Drost-Fromm – Open communication for open development #InnerSourceSummit2025](https://www.youtube.com/watch?v=GuHlyhQ2yX4) > [!note]+ Document Notes > tags: [innersource, open-communication, developer-advocacy] > author: Isabel Drost-Fromm > source: InnerSource Commons > reference: https://www.youtube.com/watch?v=GuHlyhQ2yX4 > date created: 2025-01-12 14:30 > > # 🏷️ Title: Open communication for open development >  ## 🧰 Action Inbox - [H1] Start reading and following open source communities weekly — builds expertise and contribution skills #devrel - [H2] Implement structured communication channels for projects — enables contributor onboarding #ospo - [H3] Schedule relationship building time for distributed teams — prevents silos in remote-first work #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 Commons Foundation](https://innersourcecommons.org/) - [Apache Software Foundation](https://apache.org/) ## 📝 Summary - Isabel Drost-Fromm explains how open source communication patterns apply to InnerSource development - Key insight: Contributing starts with reading and following communities, not immediately writing code - InnerSource faces same challenges as open source but within corporate constraints - Success requires structured communication channels, archived discussions, and relationship building - Management and cultural buy-in essential beyond engineering teams ## 📖 Main Content Isabel Drost-Fromm, co-founder of InnerSource Commons Foundation and Apache Software Foundation member, argues that effective InnerSource adoption requires implementing open source communication practices within enterprises. Rather than focusing solely on code publication, she emphasizes that participation begins with reading and following project communities. The talk addresses a common misconception that open source contribution starts with writing patches. Instead, Drost-Fromm advocates beginning with weekly reading of project communications to understand community dynamics, roadmaps, and recurring questions. This approach naturally leads to answering questions and making first contributions. Key infrastructure requirements include public discussion forums, issue trackers, documentation, and clear pathways for different types of contributions. The communication must be archived, searchable, linkable, and persistent - enabling knowledge reuse and faster response times. However, corporate environments present unique challenges: meeting scheduling difficulties, permission management, safety concerns around public communication, and cultural resistance to visible work. Success requires extending training beyond engineers to managers and product owners, as larger changes need organizational alignment. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/GuHlyhQ2yX4?t=0) — [H1] Introduction and speaker background - Key idea: Speaker combines open source and InnerSource expertise from Apache Foundation and corporate experience - Evidence: "Co-founder and member of the InnerSource Commons Foundation, member of the Apache Software Foundation" #### ⏱️ [02:30](https://youtu.be/GuHlyhQ2yX4?t=150) — [H2] Common misconception about open source participation - Key idea: People assume open source means publishing all code rather than participating in existing projects - Evidence: "If I tell you that I want to invite you to do open source, how many of you think I want you to publish all of your code?" #### ⏱️ [04:15](https://youtu.be/GuHlyhQ2yX4?t=255) — [H1] Starting with reading, not coding - Key idea: Effective open source contribution begins with reading community discussions weekly - Evidence: "You spend maybe an hour a week just to read. By reading what you see is how the community works" #### ⏱️ [06:45](https://youtu.be/GuHlyhQ2yX4?t=405) — [H2] Learning business value from community participation - Key idea: Following open source communities teaches patterns for testing, CI, quality control, and remote coordination - Evidence: "You learn which kinds of patterns they use in order to do testing, to do continuous integration, to do quality control" #### ⏱️ [08:20](https://youtu.be/GuHlyhQ2yX4?t=500) — [H1] Infrastructure requirements for contributors - Key idea: Projects need discoverable communication channels, documentation, and clear contribution paths - Evidence: "You look for the website. You will find the links that says community. You check where does he discuss" #### ⏱️ [11:30](https://youtu.be/GuHlyhQ2yX4?t=690) — [H2] Benefits of archived, searchable communication - Key idea: Public communication creates written, searchable, linkable knowledge base - Evidence: "It is written down. It is archived... You can go back all the way to the 90s" #### ⏱️ [13:45](https://youtu.be/GuHlyhQ2yX4?t=825) — [H3] Remote-first doesn't mean remote-only - Key idea: Strong online communities enable effective in-person meetups - Evidence: "I had no idea that the people I was meeting... came 267 kilometers one way and back" #### ⏱️ [15:20](https://youtu.be/GuHlyhQ2yX4?t=920) — [H1] Contributor conversion ratios - Key idea: Community growth follows predictable patterns from users to contributors to committers - Evidence: "For each 100 users, you will have one contributor. For each 100 contributors, you will have one committer" #### ⏱️ [17:10](https://youtu.be/GuHlyhQ2yX4?t=1030) — [H2] InnerSource faces same communication challenges - Key idea: Corporate InnerSource projects need identical infrastructure to open source but with additional constraints - Evidence: "In InnerSource it's much easier, right? We're all working for the same company towards the same goals" #### ⏱️ [20:30](https://youtu.be/GuHlyhQ2yX4?t=1230) — [H1] Corporate communication tripwires - Key idea: Private meetings, isolated planning, and disconnected tools prevent contributor engagement - Evidence: "Where does everyday communication and coordination happen? Does it happen at the same desk where your contributor cannot listen in?" #### ⏱️ [23:15](https://youtu.be/GuHlyhQ2yX4?t=1395) — [H2] Cultural safety challenges - Key idea: Public communication requires psychological safety for mistakes and questions - Evidence: "How safe do your colleagues feel sharing communicating openly, making mistakes, asking what they may consider dumb questions" #### ⏱️ [25:40](https://youtu.be/GuHlyhQ2yX4?t=1540) — [H1] Relationship building in distributed teams - Key idea: Remote teams must intentionally schedule relationship building that happens accidentally in co-located teams - Evidence: "Relationship building happens accidentally, incidentally, at the coffee machine... With remote teams, distributed teams, this doesn't happen automatically" #### ⏱️ [28:00](https://youtu.be/GuHlyhQ2yX4?t=1680) — [H2] Beyond engineering teams - Key idea: InnerSource success requires training and buy-in from managers and product owners, not just engineers - Evidence: "As soon as you want to make larger modifications, trouble starts to pop up because larger modifications take time" #### ⏱️ [29:45](https://youtu.be/GuHlyhQ2yX4?t=1785) — [H1] InnerSource Commons collaboration - Key idea: Organizations can collaborate on training materials and best practices through InnerSource Commons - Evidence: "There's people from Bosch, there's people from SAP, there's people all around the room who can work together with you" ## 📚 References - [InnerSource Commons Foundation](https://innersourcecommons.org/) - [Apache Software Foundation](https://apache.org/) - [European Open Source Academy](https://eosa.org/) ## 🗣️ Paraphrase - Open source participation starts with reading communities weekly to understand their patterns and answering recurring questions, not with writing code patches - Successful projects need structured communication infrastructure including public forums, documentation, issue tracking, and archived searchable discussions - Corporate InnerSource faces additional challenges around meeting coordination, permission management, psychological safety, and extending buy-in beyond engineering teams ## 📰 Newsletter ## Learning from Open Source: Better InnerSource Communication This week's insight comes from InnerSource expert Isabel Drost-Fromm on applying open source communication patterns within enterprises. The key breakthrough? Contributing starts with reading, not coding. **The One-Hour Weekly Investment**: Instead of jumping straight into code contributions, spend an hour weekly reading the communications of open source projects you already use. You'll naturally start answering recurring questions—your first contribution—while learning valuable patterns for testing, CI, and remote coordination. **Infrastructure That Scales**: Successful projects need discoverable communication channels, archived discussions, searchable knowledge bases, and clear contribution paths. Think of it as creating the "Wikipedia effect" for your internal projects. **Beyond Engineering**: The biggest insight? InnerSource success requires training managers and product owners, not just engineers. Larger changes need organizational alignment that extends far beyond the development team. **Community Connections**: Join the growing WordPress community exploring similar patterns in our distributed development model. 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 reading guides for following open source communities, track contribution funnels from reading to active participation - Education: Develop workshops on open source communication patterns, establish office hours for contribution mentoring - Developer experience: Implement searchable, archived communication channels with clear contribution pathways - Developer marketing: Document success stories of reading-first contribution approach, create content about corporate open source participation - Community management: Establish moderation guidelines for safe public communication, survey psychological safety barriers #### OSPO - Policy & Governance: Create contribution policies that start with community reading, establish charters for internal project communication - License Compliance: Review communication archiving requirements, ensure compliance in public corporate participation - Security Management: Implement secure communication channels that maintain openness, establish vulnerability disclosure for public participation - Software Inventory: Track open source projects used internally, map contribution opportunities to business value - Developer Support: Provide training on open source community engagement, establish tooling for contribution tracking - Community Engagement: Fund upstream projects teams actively read, create agreements for collaborative training materials - Strategic Alignment: Define KPIs for community participation, establish OKRs connecting reading activities to business outcomes #### Community - Maintainers: Implement communication infrastructure templates, establish governance models supporting contributor growth - Contributors: Create onboarding programs starting with community reading, establish first-issue programs for question answering - Sponsors: Develop transparent budgets for community participation time, create impact reports showing contribution ROI - Ecosystem: Coordinate cross-project communication standards, establish search and archiving capabilities #### WordPress - Core: Implement structured onboarding for reading core communications, establish mentorship for first-time contributors - Community: Develop meetup kits teaching open source participation patterns, establish WordCamp tracks on corporate contribution - Training: Create lesson plans for reading-first contribution approach, develop learning paths from user to contributor - Documentation: Audit HelpHub/DevHub for contribution pathway clarity, establish style guides for welcoming communication - Meta: Improve .org communication discoverability, implement integrated search across communication channels #### The WPCC - Programs: Establish fellowships for companies implementing InnerSource communication patterns - Projects: Fund governance clinics teaching open source communication infrastructure - Funding: Provide matched grants for corporate teams contributing to WordPress through reading-first approach #### FAIR - Technical independence: Ensure communication archiving maintains project independence from corporate influence - Policies: Develop transparency requirements for corporate participation in open projects - Governance artifacts: Create charters protecting community communication from corporate capture ## 🧪 Hypotheses - Weekly reading of open source communications leads to natural contribution progression within 4-6 weeks - Organizations implementing archived, searchable internal communication see 3x faster knowledge transfer rates - InnerSource projects with manager training achieve 2x more cross-team contributions than engineer-only training - Teams scheduling intentional relationship building time show 40% better remote collaboration metrics ### 📊 Methodology - Study design: Track contribution funnels from reading activities to active participation across multiple open source projects - Data sources: Analyze Apache mailing list archives, GitHub contribution patterns, and corporate InnerSource adoption metrics - Experiments: A/B test reading-first vs. code-first onboarding approaches, measure relationship building interventions in distributed teams ### ❓ Questions - How do psychological safety metrics correlate with successful InnerSource communication adoption? - What infrastructure investments show highest ROI for converting users to contributors in corporate environments? - Which communication patterns from small open source projects scale most effectively to large enterprise InnerSource initiatives? ### 🔮 Future Research - Longitudinal study of corporate teams transitioning from closed to open communication patterns - Cross-cultural analysis of InnerSource adoption in different organizational contexts - Integration of AI-assisted community management tools with human relationship building approaches ### 💡 Implications - Practice: Development teams should budget 5-10% time weekly for reading external communities they depend on - Policy: Corporate contribution policies should explicitly encourage and protect time for community participation - Security: Communication archiving systems need long-term data governance considering both transparency and compliance requirements - Education: Technical training programs must expand beyond engineers to include managers and product stakeholders - Funding: ROI calculations for open source participation should include learning transfer value, not just direct code contributions ### 🧠 Learning Styles Assessment Reading level estimate: Flesch-Kincaid Grade Level 9.2 #### 👀 Visual learners - Present: Presentation slides with clear diagrams of contributor funnels and communication flows - Improve: Add architecture diagrams showing communication infrastructure, visual representations of the 100:10:1 contributor ratio #### 🔊 Aural learners - Present: Live presentation with clear speaking and interactive elements - Improve: Provide audio summary of key infrastructure requirements, record Q&A session for reference #### 🗣️ Verbal learners - Present: Clear definitions of InnerSource vs open source, analogies between community participation and business operations - Improve: Add more storytelling around specific corporate transformation examples, create glossary of community management terms #### 🧩 Kinesthetic learners - Present: Interactive polling exercises, hands-on exploration of community websites during presentation - Improve: Create step-by-step checklists for implementing communication infrastructure, provide sandbox environments for testing approaches #### 🧠 Logical learners - Present: Clear progression from reading to contribution, structured requirements for communication infrastructure - Improve: Add decision trees for choosing communication tools, establish KPIs and success metrics for each implementation phase #### 🧑‍🤝‍🧑 Social learners - Present: Community-focused examples, emphasis on relationship building and collaborative training development - Improve: Create cohort guides for teams implementing InnerSource together, establish peer review processes for communication strategies #### 🧘‍♀️ Solitary learners - Present: Self-directed reading recommendations, individual reflection on current communication practices - Improve: Develop personal worksheets for assessing team communication maturity, create self-paced learning paths #### 🌿 Naturalistic learners - Present: Ecosystem thinking about contributor growth and community sustainability - Improve: Add analogies to natural community development, emphasize long-term sustainability of communication practices ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure in presentation, descriptive slide content - Improve: Provide detailed alt text for contributor funnel diagrams, ensure interactive elements have proper ARIA labels #### Keyboard navigation - Present: Standard presentation navigation available - Improve: Ensure interactive polling tools support keyboard-only navigation, provide skip links for long presentation sections #### Contrast and readability - Present: High contrast presentation slides with readable fonts - Improve: Verify 4.5:1 contrast ratio on all slide text, ensure readability at 200% zoom for detailed diagrams #### Text resizing and reflow - Present: Presentation scales appropriately across different screen sizes - Improve --- ## Full Transcript [00:06] Thank you for the introduction and thank [00:08] you for the advertisement. Very much [00:10] appreciated. [00:23] >> Is it now working? Yes. So, thanks again [00:26] for everyone. Um, thanks for the intro [00:29] and thanks for the advertisement. Um, [00:32] I'm going to talk about open [00:33] communication for open development. [00:36] Coming from an open source background, [00:38] that's where I learned it. And I noticed [00:40] that in Inosour, we have the same [00:42] challenges. [00:45] So, I can pretty much skip that. I'm a [00:47] co-founder and member of the Innos [00:48] Commons Foundation, member of the Apache [00:51] Software Foundation, member of the [00:52] European Open Source Academy and [00:54] opensource strategist at OP which is [00:57] just down the street 10 minutes on the [00:59] other side. [01:03] So if I tell you that I want to invite [01:05] you to do open source, [01:08] how many of you think I want you to [01:10] publish all of your code? [01:12] Awesome. because usually that's what [01:16] people think when I talk about do more [01:18] open source. [01:21] Okay, hands up if you are using open [01:22] source. [01:25] Do I see all hands? Awesome. I see all [01:27] hands. Yes. Very well. Now, the funny [01:31] thing is [01:33] we've just seen open sources everywhere. [01:36] It's also very likely a critical part of [01:38] your business. [01:41] Wouldn't you want to make sure that this [01:43] critical part and foundation remains [01:46] stable and want to have a look into what [01:49] you're using there? Now, that's why I [01:52] want to invite you to participate in [01:54] open source. [01:57] Okay. When I talk to people, what they [01:59] think about when I talk about [02:01] participate in open source, hands up if [02:03] you think that I want you to contribute [02:05] patches. [02:08] Okay, everyone who has your hands up, [02:10] you're three steps ahead. [02:14] What I really want you to do is to start [02:16] by reading and following along. So, [02:19] here's what I tell my colleagues and [02:20] everyone I bump into. If you want to get [02:23] started with open source, you look at [02:25] all of the stuffs that you're using [02:26] because that's what you're invested in [02:28] already. And then you check out how to [02:31] follow that community. [02:33] You read along. you spend maybe an hour [02:35] a week just to read. [02:38] By reading what you see is how the [02:40] community works, how they build um [02:42] what's on their schedule, what's on [02:43] their road map. And you will notice one, [02:47] two, three, four weeks into that [02:49] exercise that you start answering [02:51] questions because they are recurring. [02:54] Suddenly there's your first [02:55] contribution. [02:59] So you learn along the way. You start [03:01] helping others. You can become part of [03:03] the team. [03:07] And by the way, the learning along the [03:08] way, it's also learning for stuff that [03:10] you can use within your enterprise [03:12] because you know, you started with what [03:14] you were using already. So you learn how [03:17] to better use that open source. You [03:19] learn which kinds of patterns they use [03:21] in order to do testing, to do continuous [03:23] integration, [03:25] um to do quality control, to do [03:27] prioritization, to do coordination in [03:30] global teams that are remote first. [03:35] Okay, let me play a game. You have your [03:37] mobile phone with you? Good. Imagine [03:41] you're Mrs. Interested cat. You use your [03:44] project. You have experience with the [03:47] architecture because you're a good [03:48] engineer. You have interest in keeping [03:50] it alive and you want to pull that [03:53] person in as a committer. [03:57] Go to this web page. [04:10] So you can also go to menty.com and [04:12] enter 4559. [04:15] 7544. [04:21] >> You shouldn't be a prison. H. Yes. [04:24] Now you enter. Imagine you're at Miss [04:27] Missag Imaginary Cat. What do you need [04:30] to get started? [04:34] You want to start contributing to [04:36] Airflow, to Super Set, to Tomcat, maybe [04:41] even to HTTPD. [04:43] What do you need? [04:51] Lots of good things there. [04:54] And those who have done open source [04:56] before, you can think about your [04:57] journey. [05:25] I see documentation there in the middle. [05:27] We all know that we need it when we look [05:29] even in open source. How good is [05:31] documentation? [05:36] Good first patch maybe. [05:41] Okay, I'll break that here. [05:46] This is how you're getting started for [05:48] any open source project. You look for [05:50] the website. You will find the link [05:52] links that says community. You check [05:55] where does he discuss at the Apache [05:58] Software Foundation is often mailing [06:00] list. Sometimes it's Slack. Sometimes [06:01] it's Discord or whatever your cool kids [06:04] are using. You will find stuff for [06:07] developers and for users. You will find [06:09] the community in a semiructured chat [06:12] group. And essentially what you do find [06:16] is a contact point for users for [06:18] developers, an issue tracker where you [06:21] can leave all your uh issues, a quick [06:24] chat for quick questions, and sometimes [06:26] even office hours for meetings. [06:29] So you have clear paths for asking [06:32] questions for fixing documentation [06:33] proposing small changes and large [06:36] changes because often those paths have [06:39] to differ. [06:43] So the side effect of this public [06:46] communication is what Denise mentioned [06:48] earlier today. It is written down. [06:52] It is archived like all of the Apache [06:54] mailers are being archived for for [06:56] decades. You can go back all the way to [06:58] the 90s. You will find the discussions [07:01] there. It is searchable. [07:04] So you remember, wait a minute, I [07:06] answered that question yesterday. You [07:08] search for it and you link to it and [07:11] it's linkable and by that it's [07:12] persistent. [07:14] Does it mean you get less questions? [07:16] Nope. You get the same amount of [07:18] questions, but you get faster at [07:19] answering them because you can reference [07:21] them back. And anyone watching you can [07:24] do the same and help your answering. And [07:26] that's how you pull the people in. [07:32] Um, that also doesn't mean that you are [07:35] remote only. It means you're remote [07:37] first. [07:39] Every where I travel there is in a [07:42] Apache mailing list which is party [07:44] apache.org where you can post your um [07:47] coordinates and you can say want to have [07:49] a cup of tea this afternoon and very [07:52] likely people will will be there and [07:54] will meet with you. I was in Ireland two [07:56] weeks ago and I posted a similar [07:59] question to people I know in Ireland. I [08:01] had no idea that the people I was [08:03] meeting over a not a cup of tea, over [08:06] going to the zoo and having a hot [08:08] chocolate came 267 kilometers one way [08:11] and back. [08:14] That is the level of investment you have [08:15] in personal relationships. [08:18] So that is something that you may not [08:20] have in your company where sometimes [08:22] even having people on two floors [08:24] separates them. [08:27] So one of the tasks that you will have [08:30] as an innosource practitioner is getting [08:34] people to te drink tea together and even [08:37] if that means bringing cookies to the [08:39] office. [08:42] Okay. So your goal is to turn users into [08:44] contributors into committers. By the [08:46] way, for each 100 uh users, you will [08:49] have one contributor. For each 100 [08:51] contributors, you will have one [08:52] committer. That is roughly the um [08:55] percentages that translates to um [08:58] pulling people who are using your [09:00] project into your team. That's what we [09:02] had with um Mercedes earlier today where [09:04] it worked really really well when people [09:06] use the software themselves on a daily [09:08] basis to pull them in. [09:11] Essentially that is based on what um [09:14] generally called informed self-interest. [09:17] They themselves has an issue have an [09:19] issues that they have to solve and [09:20] that's what gets gets them active. [09:25] So in inos it's much easier, right? [09:27] We're all working for the same company [09:29] towards the same goals. [09:35] Okay, imagine you're Mr. Curious Cat. [09:38] You depend on an innosource project. [09:42] They are in a different team and you [09:44] want to finding common meeting times is [09:46] utterly difficult. [09:51] Same game as before. You still have the [09:53] page open, don't you? [09:57] What does Mr. Curious Cat need in order [10:00] to get started? [10:09] Come on. They also need the same stuff [10:10] that the open source people need. [10:13] It's not a trick question. [10:16] You're getting ahead of me here. [10:25] I still want to see documentation very [10:27] high up. [10:37] But that means that I can skip one more [10:39] slide. [10:40] Very nice of you. [10:44] So essentially it means again turning [10:46] contributors into committers, pulling [10:48] them into your project um invoking that [10:51] informed self-interest. [10:54] And the tricky part is what you just [10:56] shared. [10:58] I will skip that. You already shared a [11:01] lot of the trip wires, so I will not [11:03] make you type that up again. [11:07] Where does everyday communication and [11:09] coordination happen? Does it happen at [11:12] the same desk [11:14] where your contributor cannot listen in? [11:18] At Apache, they are globally [11:20] distributed. What didn't happen on the [11:21] mailing list didn't happen. That is for [11:24] the reason that everyone who wants to [11:25] contribute can watch over your shoulder. [11:29] You remember that uncomfortable feeling [11:31] sitting in school teacher behind you [11:33] while you were writing a test. That is [11:36] the feeling that you need. They watch [11:39] you in order to get started. [11:44] Where does planning and road map setting [11:46] happen? Is that something that is [11:48] visible for contributors or is that [11:50] something that happens in the meeting [11:51] room? Contributors need to know that so [11:55] that they don't work on stuff that is [11:57] out of scope. [12:01] Where does um user experience design [12:03] happen? How does your contributor know [12:06] whether the customers are in focus? [12:13] You already know I love going to the zoo [12:15] even in Ireland, but I hate having a zoo [12:17] of disconnected shoes. [12:21] If if what you want to do is to think [12:23] about archiving conversations long term [12:26] and long term meaning for the entire [12:29] life cycle of the product that you're [12:30] talking about. So no quickly switching [12:33] tools and forgetting the history. And [12:37] how many of you once bumped into a [12:39] feature where you were like is it [12:41] something I can throw away? Is it art or [12:44] what is it for? [12:46] I see a lot of smiling nodding faces. [12:48] just nobody daring to hand to raise [12:50] their hand. [12:52] Think about integrated search. In [12:54] companies, we usually have different [12:55] tools for issue tracking for Vicki and [12:57] depending on team you have a different [12:59] tool. You want to integrate that [13:01] together and hide it behind one search [13:03] bar. Open source has that that search [13:06] bar is a public search engine. [13:10] You don't want to have that. You have to [13:11] build it internally. [13:14] You have to think about linkability. [13:16] As I mentioned before, if an question [13:18] comes up again, you want to link to the [13:21] answer and not type it up again. And [13:24] unfortunately, you have to think about [13:26] permission handling. So, who gets access [13:29] to this project? We had that with Bosch [13:31] earlier today. [13:35] Does it have any impact on line [13:37] management? [13:41] Mhm. So with open source I can at least [13:44] point to my manager and tell them look [13:46] this is publicly visible you can see it [13:48] as well [13:50] if it's inside the corporation [13:52] potentially not vis this is going to be [13:56] interesting [13:59] and there is another question I'm [14:01] talking about communicating openly [14:04] visibly for everyone [14:06] how safe do your colleagues feel sharing [14:11] communicating openly, making mistakes, [14:15] asking what they may consider dumb [14:17] questions where no dumb questions exist. [14:23] Work outside of their team, outside of [14:26] their comfort zone with highly visible [14:28] communication. [14:30] So there is a certain company culture [14:34] working against you. [14:36] Remember [14:38] the example from two different floors. [14:41] We all know that this already drives [14:44] teams apart. How about teams [14:48] that how about people that are not in [14:50] the same team potentially remote first? [14:54] So there's a level up in terms of trust [14:56] building, in terms of communication, but [14:58] also in terms of management. [15:00] So what you need to make is time for [15:02] relationship building. We may be remote [15:04] first, but what we do is we schedule [15:08] work meetings [15:09] when we were in the office and not in a [15:12] distributed team. Relationship building [15:14] happens accidentally, incidentally, at [15:17] the coffee machine, drinking a cup of [15:19] tea, um going out for lunch together. [15:23] With remote teams, distributed teams, [15:25] this doesn't happen automatically. How [15:27] does it feel to schedule half an hour [15:30] for a virtual cup of tea? [15:33] Is that okay or is that something that [15:35] is encouraged? [15:39] Then we heard a lot about metrics [15:42] and we heard about works councils being [15:43] in the way. So you're in the way for a [15:46] certain reason. Metrics are scary. [15:48] Metrics sometimes can be used in order [15:51] to judge people. So it's vital if you [15:54] roll out metrics to pull the workforce [15:57] in and to make sure that you are not [16:00] measuring something that could be used [16:03] as like as a negative. [16:10] So with that I would like to conclude [16:11] that open source and innoves [16:17] way beyond code. You have to start a lot [16:19] more um a lot more a lot earlier. Sorry. [16:24] The funny thing is that openness is [16:26] vital and not only for us engineers. So [16:28] what I've seen in the wild is at some [16:31] point it starts working at the [16:33] engineering level. [16:35] That is usually the point where small [16:38] modifications [16:40] just make it into the codebase. They are [16:42] smoothless. As soon as you want to make [16:44] larger modifications, trouble starts to [16:47] pop up because larger modifications take [16:50] take time and you only get time if you [16:53] talk to your manager, to your product [16:54] owner, whatever. So these people also [16:57] need to be in the loop. What we've done [16:59] at my employer is to um have Innosource [17:03] training not only for the engineers but [17:06] for everyone and you can access this [17:08] training at the Inosourus Commons. Um [17:11] there is a learning path. It's for [17:12] trusted computers for contributors. [17:14] There's an introduction but there's also [17:16] for people that are not directly working [17:18] on GitHub, GitLab, whatever you you use [17:21] internally. [17:23] And the funny thing about the Inos [17:24] Commons Foundation is you don't have to [17:26] work on these materials internally [17:28] alone, but there's people from Bosch, [17:30] there's people from SAP, there's people [17:33] all around the room who can work [17:36] together with you on these trainings and [17:38] on that material and that is essentially [17:41] the core of the Inosource concept and [17:44] open source concept. So essentially [17:45] there's more layers than you may than [17:48] you may expect and it needs trust and [17:50] safety to be effective. And with that, [17:52] I'm happy to take questions.  ## 📺 Video ![](https://www.youtube.com/watch?v=GuHlyhQ2yX4) --- # 📝 Full Notes (Deep-Read Analysis) # 🏷️ Title: Open communication for open development ## 🧰 Action Inbox - [H1] Start reading and following open source communities weekly — builds expertise and contribution skills #devrel - [H2] Implement structured communication channels for projects — enables contributor onboarding #ospo - [H3] Schedule relationship building time for distributed teams — prevents silos in remote-first work #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 Commons Foundation](https://innersourcecommons.org/) - [Apache Software Foundation](https://apache.org/) ## 📝 Summary - Isabel Drost-Fromm explains how open source communication patterns apply to InnerSource development - Key insight: Contributing starts with reading and following communities, not immediately writing code - InnerSource faces same challenges as open source but within corporate constraints - Success requires structured communication channels, archived discussions, and relationship building - Management and cultural buy-in essential beyond engineering teams ## 📖 Main Content Isabel Drost-Fromm, co-founder of InnerSource Commons Foundation and Apache Software Foundation member, argues that effective InnerSource adoption requires implementing open source communication practices within enterprises. Rather than focusing solely on code publication, she emphasizes that participation begins with reading and following project communities. The talk addresses a common misconception that open source contribution starts with writing patches. Instead, Drost-Fromm advocates beginning with weekly reading of project communications to understand community dynamics, roadmaps, and recurring questions. This approach naturally leads to answering questions and making first contributions. Key infrastructure requirements include public discussion forums, issue trackers, documentation, and clear pathways for different types of contributions. The communication must be archived, searchable, linkable, and persistent - enabling knowledge reuse and faster response times. However, corporate environments present unique challenges: meeting scheduling difficulties, permission management, safety concerns around public communication, and cultural resistance to visible work. Success requires extending training beyond engineers to managers and product owners, as larger changes need organizational alignment. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/GuHlyhQ2yX4?t=0) — [H1] Introduction and speaker background - Key idea: Speaker combines open source and InnerSource expertise from Apache Foundation and corporate experience - Evidence: "Co-founder and member of the InnerSource Commons Foundation, member of the Apache Software Foundation" #### ⏱️ [02:30](https://youtu.be/GuHlyhQ2yX4?t=150) — [H2] Common misconception about open source participation - Key idea: People assume open source means publishing all code rather than participating in existing projects - Evidence: "If I tell you that I want to invite you to do open source, how many of you think I want you to publish all of your code?" #### ⏱️ [04:15](https://youtu.be/GuHlyhQ2yX4?t=255) — [H1] Starting with reading, not coding - Key idea: Effective open source contribution begins with reading community discussions weekly - Evidence: "You spend maybe an hour a week just to read. By reading what you see is how the community works" #### ⏱️ [06:45](https://youtu.be/GuHlyhQ2yX4?t=405) — [H2] Learning business value from community participation - Key idea: Following open source communities teaches patterns for testing, CI, quality control, and remote coordination - Evidence: "You learn which kinds of patterns they use in order to do testing, to do continuous integration, to do quality control" #### ⏱️ [08:20](https://youtu.be/GuHlyhQ2yX4?t=500) — [H1] Infrastructure requirements for contributors - Key idea: Projects need discoverable communication channels, documentation, and clear contribution paths - Evidence: "You look for the website. You will find the links that says community. You check where does he discuss" #### ⏱️ [11:30](https://youtu.be/GuHlyhQ2yX4?t=690) — [H2] Benefits of archived, searchable communication - Key idea: Public communication creates written, searchable, linkable knowledge base - Evidence: "It is written down. It is archived... You can go back all the way to the 90s" #### ⏱️ [13:45](https://youtu.be/GuHlyhQ2yX4?t=825) — [H3] Remote-first doesn't mean remote-only - Key idea: Strong online communities enable effective in-person meetups - Evidence: "I had no idea that the people I was meeting... came 267 kilometers one way and back" #### ⏱️ [15:20](https://youtu.be/GuHlyhQ2yX4?t=920) — [H1] Contributor conversion ratios - Key idea: Community growth follows predictable patterns from users to contributors to committers - Evidence: "For each 100 users, you will have one contributor. For each 100 contributors, you will have one committer" #### ⏱️ [17:10](https://youtu.be/GuHlyhQ2yX4?t=1030) — [H2] InnerSource faces same communication challenges - Key idea: Corporate InnerSource projects need identical infrastructure to open source but with additional constraints - Evidence: "In InnerSource it's much easier, right? We're all working for the same company towards the same goals" #### ⏱️ [20:30](https://youtu.be/GuHlyhQ2yX4?t=1230) — [H1] Corporate communication tripwires - Key idea: Private meetings, isolated planning, and disconnected tools prevent contributor engagement - Evidence: "Where does everyday communication and coordination happen? Does it happen at the same desk where your contributor cannot listen in?" #### ⏱️ [23:15](https://youtu.be/GuHlyhQ2yX4?t=1395) — [H2] Cultural safety challenges - Key idea: Public communication requires psychological safety for mistakes and questions - Evidence: "How safe do your colleagues feel sharing communicating openly, making mistakes, asking what they may consider dumb questions" #### ⏱️ [25:40](https://youtu.be/GuHlyhQ2yX4?t=1540) — [H1] Relationship building in distributed teams - Key idea: Remote teams must intentionally schedule relationship building that happens accidentally in co-located teams - Evidence: "Relationship building happens accidentally, incidentally, at the coffee machine... With remote teams, distributed teams, this doesn't happen automatically" #### ⏱️ [28:00](https://youtu.be/GuHlyhQ2yX4?t=1680) — [H2] Beyond engineering teams - Key idea: InnerSource success requires training and buy-in from managers and product owners, not just engineers - Evidence: "As soon as you want to make larger modifications, trouble starts to pop up because larger modifications take time" #### ⏱️ [29:45](https://youtu.be/GuHlyhQ2yX4?t=1785) — [H1] InnerSource Commons collaboration - Key idea: Organizations can collaborate on training materials and best practices through InnerSource Commons - Evidence: "There's people from Bosch, there's people from SAP, there's people all around the room who can work together with you" ## 📚 References - [InnerSource Commons Foundation](https://innersourcecommons.org/) - [Apache Software Foundation](https://apache.org/) - [European Open Source Academy](https://eosa.org/) ## 🗣️ Paraphrase - Open source participation starts with reading communities weekly to understand their patterns and answering recurring questions, not with writing code patches - Successful projects need structured communication infrastructure including public forums, documentation, issue tracking, and archived searchable discussions - Corporate InnerSource faces additional challenges around meeting coordination, permission management, psychological safety, and extending buy-in beyond engineering teams ## 📰 Newsletter ## Learning from Open Source: Better InnerSource Communication This week's insight comes from InnerSource expert Isabel Drost-Fromm on applying open source communication patterns within enterprises. The key breakthrough? Contributing starts with reading, not coding. **The One-Hour Weekly Investment**: Instead of jumping straight into code contributions, spend an hour weekly reading the communications of open source projects you already use. You'll naturally start answering recurring questions—your first contribution—while learning valuable patterns for testing, CI, and remote coordination. **Infrastructure That Scales**: Successful projects need discoverable communication channels, archived discussions, searchable knowledge bases, and clear contribution paths. Think of it as creating the "Wikipedia effect" for your internal projects. **Beyond Engineering**: The biggest insight? InnerSource success requires training managers and product owners, not just engineers. Larger changes need organizational alignment that extends far beyond the development team. **Community Connections**: Join the growing WordPress community exploring similar patterns in our distributed development model. 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 reading guides for following open source communities, track contribution funnels from reading to active participation - Education: Develop workshops on open source communication patterns, establish office hours for contribution mentoring - Developer experience: Implement searchable, archived communication channels with clear contribution pathways - Developer marketing: Document success stories of reading-first contribution approach, create content about corporate open source participation - Community management: Establish moderation guidelines for safe public communication, survey psychological safety barriers #### OSPO - Policy & Governance: Create contribution policies that start with community reading, establish charters for internal project communication - License Compliance: Review communication archiving requirements, ensure compliance in public corporate participation - Security Management: Implement secure communication channels that maintain openness, establish vulnerability disclosure for public participation - Software Inventory: Track open source projects used internally, map contribution opportunities to business value - Developer Support: Provide training on open source community engagement, establish tooling for contribution tracking - Community Engagement: Fund upstream projects teams actively read, create agreements for collaborative training materials - Strategic Alignment: Define KPIs for community participation, establish OKRs connecting reading activities to business outcomes #### Community - Maintainers: Implement communication infrastructure templates, establish governance models supporting contributor growth - Contributors: Create onboarding programs starting with community reading, establish first-issue programs for question answering - Sponsors: Develop transparent budgets for community participation time, create impact reports showing contribution ROI - Ecosystem: Coordinate cross-project communication standards, establish search and archiving capabilities #### WordPress - Core: Implement structured onboarding for reading core communications, establish mentorship for first-time contributors - Community: Develop meetup kits teaching open source participation patterns, establish WordCamp tracks on corporate contribution - Training: Create lesson plans for reading-first contribution approach, develop learning paths from user to contributor - Documentation: Audit HelpHub/DevHub for contribution pathway clarity, establish style guides for welcoming communication - Meta: Improve .org communication discoverability, implement integrated search across communication channels #### The WPCC - Programs: Establish fellowships for companies implementing InnerSource communication patterns - Projects: Fund governance clinics teaching open source communication infrastructure - Funding: Provide matched grants for corporate teams contributing to WordPress through reading-first approach #### FAIR - Technical independence: Ensure communication archiving maintains project independence from corporate influence - Policies: Develop transparency requirements for corporate participation in open projects - Governance artifacts: Create charters protecting community communication from corporate capture ## 🧪 Hypotheses - Weekly reading of open source communications leads to natural contribution progression within 4-6 weeks - Organizations implementing archived, searchable internal communication see 3x faster knowledge transfer rates - InnerSource projects with manager training achieve 2x more cross-team contributions than engineer-only training - Teams scheduling intentional relationship building time show 40% better remote collaboration metrics ### 📊 Methodology - Study design: Track contribution funnels from reading activities to active participation across multiple open source projects - Data sources: Analyze Apache mailing list archives, GitHub contribution patterns, and corporate InnerSource adoption metrics - Experiments: A/B test reading-first vs. code-first onboarding approaches, measure relationship building interventions in distributed teams ### ❓ Questions - How do psychological safety metrics correlate with successful InnerSource communication adoption? - What infrastructure investments show highest ROI for converting users to contributors in corporate environments? - Which communication patterns from small open source projects scale most effectively to large enterprise InnerSource initiatives? ### 🔮 Future Research - Longitudinal study of corporate teams transitioning from closed to open communication patterns - Cross-cultural analysis of InnerSource adoption in different organizational contexts - Integration of AI-assisted community management tools with human relationship building approaches ### 💡 Implications - Practice: Development teams should budget 5-10% time weekly for reading external communities they depend on - Policy: Corporate contribution policies should explicitly encourage and protect time for community participation - Security: Communication archiving systems need long-term data governance considering both transparency and compliance requirements - Education: Technical training programs must expand beyond engineers to include managers and product stakeholders - Funding: ROI calculations for open source participation should include learning transfer value, not just direct code contributions ### 🧠 Learning Styles Assessment Reading level estimate: Flesch-Kincaid Grade Level 9.2 #### 👀 Visual learners - Present: Presentation slides with clear diagrams of contributor funnels and communication flows - Improve: Add architecture diagrams showing communication infrastructure, visual representations of the 100:10:1 contributor ratio #### 🔊 Aural learners - Present: Live presentation with clear speaking and interactive elements - Improve: Provide audio summary of key infrastructure requirements, record Q&A session for reference #### 🗣️ Verbal learners - Present: Clear definitions of InnerSource vs open source, analogies between community participation and business operations - Improve: Add more storytelling around specific corporate transformation examples, create glossary of community management terms #### 🧩 Kinesthetic learners - Present: Interactive polling exercises, hands-on exploration of community websites during presentation - Improve: Create step-by-step checklists for implementing communication infrastructure, provide sandbox environments for testing approaches #### 🧠 Logical learners - Present: Clear progression from reading to contribution, structured requirements for communication infrastructure - Improve: Add decision trees for choosing communication tools, establish KPIs and success metrics for each implementation phase #### 🧑‍🤝‍🧑 Social learners - Present: Community-focused examples, emphasis on relationship building and collaborative training development - Improve: Create cohort guides for teams implementing InnerSource together, establish peer review processes for communication strategies #### 🧘‍♀️ Solitary learners - Present: Self-directed reading recommendations, individual reflection on current communication practices - Improve: Develop personal worksheets for assessing team communication maturity, create self-paced learning paths #### 🌿 Naturalistic learners - Present: Ecosystem thinking about contributor growth and community sustainability - Improve: Add analogies to natural community development, emphasize long-term sustainability of communication practices ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure in presentation, descriptive slide content - Improve: Provide detailed alt text for contributor funnel diagrams, ensure interactive elements have proper ARIA labels #### Keyboard navigation - Present: Standard presentation navigation available - Improve: Ensure interactive polling tools support keyboard-only navigation, provide skip links for long presentation sections #### Contrast and readability - Present: High contrast presentation slides with readable fonts - Improve: Verify 4.5:1 contrast ratio on all slide text, ensure readability at 200% zoom for detailed diagrams #### Text resizing and reflow - Present: Presentation scales appropriately across different screen sizes - Improve --- # 📄 Full Transcript *Auto-generated from YouTube captions · timestamps roughly every 30 seconds · [watch on YouTube](https://www.youtube.com/watch?v=GuHlyhQ2yX4)* **[00:06]** Thank you for the introduction and thank you for the advertisement. Very much appreciated. >> Is it now working? Yes. So, thanks again for everyone. Um, thanks for the intro and thanks for the advertisement. Um, I'm going to talk about open communication for open development. Coming from an open source background, **[00:38]** that's where I learned it. And I noticed that in Inosour, we have the same challenges. So, I can pretty much skip that. I'm a co-founder and member of the Innos Commons Foundation, member of the Apache Software Foundation, member of the European Open Source Academy and opensource strategist at OP which is just down the street 10 minutes on the other side. So if I tell you that I want to invite you to do open source, [sighs] **[01:08]** how many of you think I want you to publish all of your code? Awesome. because usually that's what people think when I talk about do more open source. Okay, hands up if you are using open source. Do I see all hands? Awesome. I see all hands. Yes. Very well. Now, the funny thing is we've just seen open sources everywhere. It's also very likely a critical part of **[01:38]** your business. Wouldn't you want to make sure that this critical part and foundation remains stable and want to have a look into what you're using there? Now, that's why I want to invite you to participate in open source. Okay. When I talk to people, what they think about when I talk about participate in open source, hands up if you think that I want you to contribute patches. Okay, everyone who has your hands up, **[02:10]** you're three steps ahead. What I really want you to do is to start by reading and following along. So, here's what I tell my colleagues and everyone I bump into. If you want to get started with open source, you look at all of the stuffs that you're using because that's what you're invested in already. And then you check out how to follow that community. You read along. you spend maybe an hour a week just to read. By reading what you see is how the community works, how they build um **[02:42]** what's on their schedule, what's on their road map. And you will notice one, two, three, four weeks into that exercise that you start answering questions because they are recurring. Suddenly there's your first contribution. So you learn along the way. You start helping others. You can become part of the team. And by the way, the learning along the way, it's also learning for stuff that you can use within your enterprise because you know, you started with what **[03:14]** you were using already. So you learn how to better use that open source. You learn which kinds of patterns they use in order to do testing, to do continuous integration, um to do quality control, to do prioritization, to do coordination in global teams that are remote first. Okay, let me play a game. You have your mobile phone with you? Good. Imagine you're Mrs. Interested cat. You use your **[03:44]** project. You have experience with the architecture because you're a good engineer. You have interest in keeping it alive and you want to pull that person in as a committer. Go to this web page. So you can also go to menty.com and enter 4559. **[04:15]** 7544. >> You shouldn't be a prison. H. Yes. [laughter] Now you enter. Imagine you're at Miss Missag Imaginary Cat. What do you need to get started? You want to start contributing to Airflow, to Super Set, to Tomcat, maybe even to HTTPD. What do you need? **[04:51]** Lots of good things there. And those who have done open source before, you can think about your journey. **[05:25]** I see documentation there in the middle. We all know that we need it when we look even in open source. How good is documentation? Good first patch maybe. [laughter] Okay, I'll break that here. This is how you're getting started for any open source project. You look for the website. You will find the link links that says community. You check **[05:55]** where does he discuss at the Apache Software Foundation is often mailing list. Sometimes it's Slack. Sometimes it's Discord or whatever your cool kids are using. You will find stuff for developers and for users. You will find the community in a semiructured chat group. And essentially what you do find is a contact point for users for developers, an issue tracker where you can leave all your uh issues, a quick chat for quick questions, and sometimes **[06:26]** even office hours for meetings. So you have clear paths for asking questions for fixing documentation proposing small changes and large changes because often those paths have to differ. So the side effect of this public communication is what Denise mentioned earlier today. It is written down. It is archived like all of the Apache mailers are being archived for for decades. You can go back all the way to **[06:58]** the 90s. You will find the discussions there. It is searchable. So you remember, wait a minute, I answered that question yesterday. You search for it and you link to it and it's linkable and by that it's persistent. Does it mean you get less questions? Nope. You get the same amount of questions, but you get faster at answering them because you can reference them back. And anyone watching you can do the same and help your answering. And that's how you pull the people in. **[07:32]** Um, that also doesn't mean that you are remote only. It means you're remote first. Every where I travel there is in a Apache mailing list which is party apache.org where you can post your um coordinates and you can say want to have a cup of tea this afternoon and very likely people will will be there and will meet with you. I was in Ireland two weeks ago and I posted a similar question to people I know in Ireland. I had no idea that the people I was **[08:03]** meeting over a not a cup of tea, over going to the zoo and having a hot chocolate came 267 kilometers one way and back. That is the level of investment you have in personal relationships. So that is something that you may not have in your company where sometimes even having people on two floors separates them. So one of the tasks that you will have as an innosource practitioner is getting **[08:34]** people to te drink tea together and even if that means bringing cookies to the office. Okay. So your goal is to turn users into contributors into committers. By the way, for each 100 uh users, you will have one contributor. For each 100 contributors, you will have one committer. That is roughly the um percentages that translates to um pulling people who are using your project into your team. That's what we had with um Mercedes earlier today where **[09:04]** it worked really really well when people use the software themselves on a daily basis to pull them in. Essentially that is based on what um generally called informed self-interest. They themselves has an issue have an issues that they have to solve and that's what gets gets them active. So in inos it's much easier, right? We're all working for the same company towards the same goals. [snorts] **[09:35]** Okay, imagine you're Mr. Curious Cat. You depend on an innosource project. They are in a different team and you want to finding common meeting times is utterly difficult. Same game as before. You still have the page open, don't you? What does Mr. Curious Cat need in order to get started? >> [snorts and laughter] **[10:09]** >> Come on. They also need the same stuff that the open source people need. It's not a trick question. You're getting ahead of me here. [laughter] I still want to see documentation very high up. But that means that I can skip one more **[10:39]** slide. Very nice of you. So essentially it means again turning contributors into committers, pulling them into your project um invoking that informed self-interest. And the tricky part is what you just shared. I will skip that. You already shared a lot of the trip wires, so I will not make you type that up again. Where does everyday communication and **[11:09]** coordination happen? Does it happen at the same desk where your contributor cannot listen in? At Apache, they are globally distributed. What didn't happen on the mailing list didn't happen. That is for the reason that everyone who wants to contribute can watch over your shoulder. You remember that uncomfortable feeling sitting in school teacher behind you while you were writing a test. That is the feeling that you need. They watch **[11:39]** you in order to get started. Where does planning and road map setting happen? Is that something that is visible for contributors or is that something that happens in the meeting room? Contributors need to know that so that they don't work on stuff that is out of scope. Where does um user experience design happen? How does your contributor know whether the customers are in focus? **[12:13]** You already know I love going to the zoo even in Ireland, but I hate having a zoo of disconnected shoes. If if what you want to do is to think about archiving conversations long term and long term meaning for the entire life cycle of the product that you're talking about. So no quickly switching tools and forgetting the history. And how many of you once bumped into a feature where you were like is it something I can throw away? Is it art or **[12:44]** what is it for? I see a lot of smiling nodding faces. just nobody daring to hand to raise their hand. Think about integrated search. In companies, we usually have different tools for issue tracking for Vicki and depending on team you have a different tool. You want to integrate that together and hide it behind one search bar. Open source has that that search bar is a public search engine. You don't want to have that. You have to build it internally. **[13:14]** You have to think about linkability. As I mentioned before, if an question comes up again, you want to link to the answer and not type it up again. And unfortunately, you have to think about permission handling. So, who gets access to this project? We had that with Bosch earlier today. Does it have any impact on line management? Mhm. So with open source I can at least **[13:44]** point to my manager and tell them look this is publicly visible you can see it as well if it's inside the corporation potentially not vis this is going to be interesting and there is another question I'm talking about communicating openly visibly for everyone how safe do your colleagues feel sharing communicating openly, making mistakes, **[14:15]** asking what they may consider dumb questions where no dumb questions exist. Work outside of their team, outside of their comfort zone with highly visible communication. So there is a certain company culture working against you. Remember the example from two different floors. We all know that this already drives teams apart. How about teams **[14:48]** that how about people that are not in the same team potentially remote first? So there's a level up in terms of trust building, in terms of communication, but also in terms of management. So what you need to make is time for relationship building. We may be remote first, but what we do is we schedule work meetings when we were in the office and not in a distributed team. Relationship building happens accidentally, incidentally, at the coffee machine, drinking a cup of **[15:19]** tea, um going out for lunch together. With remote teams, distributed teams, this doesn't happen automatically. How does it feel to schedule half an hour for a virtual cup of tea? Is that okay or is that something that is encouraged? Then we heard a lot about metrics and we heard about works councils being in the way. So you're in the way for a certain reason. Metrics are scary. Metrics sometimes can be used in order **[15:51]** to judge people. So it's vital if you roll out metrics to pull the workforce in and to make sure that you are not measuring something that could be used as like as a negative. So with that I would like to conclude that open source and innoves way beyond code. You have to start a lot more um a lot more a lot earlier. Sorry. **[16:24]** The funny thing is that openness is vital and not only for us engineers. So what I've seen in the wild is at some point it starts working at the engineering level. That is usually the point where small modifications just make it into the codebase. They are smoothless. As soon as you want to make larger modifications, trouble starts to pop up because larger modifications take take time and you only get time if you talk to your manager, to your product **[16:54]** owner, whatever. So these people also need to be in the loop. What we've done at my employer is to um have Innosource training not only for the engineers but for everyone and you can access this training at the Inosourus Commons. Um there is a learning path. It's for trusted computers for contributors. There's an introduction but there's also for people that are not directly working on GitHub, GitLab, whatever you you use internally. And the funny thing about the Inos Commons Foundation is you don't have to **[17:26]** work on these materials internally alone, but there's people from Bosch, there's people from SAP, there's people all around the room who can work together with you on these trainings and on that material and that is essentially the core of the Inosource concept and open source concept. So essentially there's more layers than you may than you may expect and it needs trust and safety to be effective. And with that, I'm happy to take questions.