Episode 120: Practitioner Guides: #5 Demonstrating Organizational Value  ## Metadata - Author: [[CHAOSScast]] - Full Title: Episode 120: Practitioner Guides: #5 Demonstrating Organizational Value - Category: #podcasts - URL: https://share.snipd.com/episode/863ff21d-9cf4-4e21-9408-ecc4cef87ac6 ## Document Notes > [!note]+ Document Notes > tags: [Open Source, OSPO, Community Health] > author: [MISSING] > source: [YouTube] > reference: [https://www.youtube.com/watch?v=jDmtVO30vFc] > date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} > > # 🏷️ Title: Episode 120: Practitioner Guides: #5 Demonstrating Organizational Value > <!-- deep-read:sections start --> ## 🧰 Action Inbox - [H2] Draft “tsunami of data” explainer for leaders — context/https://www.youtube.com/watch?v=jDmtVO30vFc&t=255 #articleseed - [H5] Build bug-to-fix KPI with external assist rate — context/https://www.youtube.com/watch?v=jDmtVO30vFc&t=555 #xref - [H6] Create “priority = criticality × health” worksheet — context/https://www.youtube.com/watch?v=jDmtVO30vFc&t=726 #articleseed - [H8] Replace vanity counts with outcome metrics — context/https://www.youtube.com/watch?v=jDmtVO30vFc&t=1100 #addendum - [H4] Prepare finance-ready revenue support estimates — context/https://www.youtube.com/watch?v=jDmtVO30vFc&t=514 #share - [H7] Curate department-specific criticality drivers — context/https://www.youtube.com/watch?v=jDmtVO30vFc&t=966 #xref - [H9] Reframe community work in business terms — context/https://www.youtube.com/watch?v=jDmtVO30vFc&t=1175 #articleseed - [H10] Pilot AI triage for OSS repos — context/https://www.youtube.com/watch?v=jDmtVO30vFc&t=1316 #articleseed ## 🧭 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 - CHAOSS Podcast episode on organizational value (YouTube). https://www.youtube.com/watch?v=jDmtVO30vFc ## 📝 Summary - The panel explains demonstrating organizational value in open source. See H1, H2. - They shift focus from raw counts to business outcomes. See H8. - A simple formula guides prioritization choices. See H6. - Bug metrics and community help show tangible returns. See H5. - Bottom line: Align OSS work to leadership goals. See H4, H7. ## 📖 Main Content - The guide addresses “data tsunamis” from OSS metrics. It proposes interpretation paths. Source: video above. - Leaders want risk, revenue, and time signals. They do not want commit counts. Source: H4, H8. - The “priority = criticality × health” framing simplifies decisions. It connects business stakes to project status. Source: H6. - Example evidence shows faster fixes via community participation. It strengthens investment cases. Source: H5. - Messaging must vary by department. Criticality differs across units. Source: H7. - Present community work as business leverage, not charity. Source: H9. ### 🗒️ Notes #### ⏱️ [00:11](https://www.youtube.com/watch?v=jDmtVO30vFc&t=11) Opening and purpose ### [H1] Podcast targets community health measurement cases > [!quote] [Episode 120](https://www.youtube.com/watch?v=jDmtVO30vFc) by an unnamed author via [[YouTube]]. Published [MISSING]. Accessed {{date:YYYY-MM-DD}}. > “We share use cases and experiences that measures open source community health.” Sets context for practical measurement focus. [view highlight](https://www.youtube.com/watch?v=jDmtVO30vFc&t=11) #xref ID:yt_0011 #### ⏱️ [02:37](https://www.youtube.com/watch?v=jDmtVO30vFc&t=157) Practitioner guides context ### [H2] Guides help interpret a metrics tsunami > [!quote] [Episode 120](https://www.youtube.com/watch?v=jDmtVO30vFc) > “We’ve made it really easy for people to collect piles and piles of metrics.” Interpretation, not collection, becomes the bottleneck. [view highlight](https://www.youtube.com/watch?v=jDmtVO30vFc&t=256) #articleseed ID:yt_0237 #### ⏱️ [04:20](https://www.youtube.com/watch?v=jDmtVO30vFc&t=260) Scope of this guide ### [H3] Demonstrating value is a complex topic > [!quote] [Episode 120](https://www.youtube.com/watch?v=jDmtVO30vFc) > “Demonstrating organizational value of your open source efforts is a really complex topic.” Depth justifies an extensive guide. [view highlight](https://www.youtube.com/watch?v=jDmtVO30vFc&t=260) #xref ID:yt_0420 #### ⏱️ [08:34](https://www.youtube.com/watch?v=jDmtVO30vFc&t=514) Leadership expectations ### [H4] Leaders ask about revenue, risk, and time > [!quote] [Episode 120](https://www.youtube.com/watch?v=jDmtVO30vFc) > “They want to know things like how much revenue is supported by this…” Frame OSS impact in business terms. [view highlight](https://www.youtube.com/watch?v=jDmtVO30vFc&t=514) #share ID:yt_0834 #### ⏱️ [09:30](https://www.youtube.com/watch?v=jDmtVO30vFc&t=570) Evidence via bug metrics ### [H5] Community fixes speed resolution and reduces toil > [!quote] [Episode 120](https://www.youtube.com/watch?v=jDmtVO30vFc) > “They had submitted 11… six of them were solved by them and five were actually solved by community members.” Show external leverage and resilience. [view highlight](https://www.youtube.com/watch?v=jDmtVO30vFc&t=585) #xref ID:yt_0930 ### [H5a] External fixes arrive faster than internal cycles > [!quote] [Episode 120](https://www.youtube.com/watch?v=jDmtVO30vFc) > “The meanantime to get a bug fixed resolve patched… was like less than 3 days” Speed supports availability and customer trust. [view highlight](https://www.youtube.com/watch?v=jDmtVO30vFc&t=603) #articleseed ID:yt_0930a #### ⏱️ [11:42](https://www.youtube.com/watch?v=jDmtVO30vFc&t=702) Prioritization framework ### [H6] Priority equals criticality times health > [!quote] [Episode 120](https://www.youtube.com/watch?v=jDmtVO30vFc) > “Priority equals criticality times health…” Use as a lightweight portfolio rubric. [view highlight](https://www.youtube.com/watch?v=jDmtVO30vFc&t=723) #articleseed ID:yt_1142 #### ⏱️ [16:12](https://www.youtube.com/watch?v=jDmtVO30vFc&t=972) Department variation ### [H7] Criticality differs across departments and goals > [!quote] [Episode 120](https://www.youtube.com/watch?v=jDmtVO30vFc) > “Criticality is going to be different for every organization and… different from department to department.” Tailor narratives to each stakeholder. [view highlight](https://www.youtube.com/watch?v=jDmtVO30vFc&t=972) #xref ID:yt_1612 #### ⏱️ [18:29](https://www.youtube.com/watch?v=jDmtVO30vFc&t=1109) Bad metrics pitfalls ### [H8] Leaders do not care about commit counts > [!quote] [Episode 120](https://www.youtube.com/watch?v=jDmtVO30vFc) > “Leadership doesn’t care how many commits you made or how many pull requests you made.” Report business outcomes instead. [view highlight](https://www.youtube.com/watch?v=jDmtVO30vFc&t=1109) #addendum ID:yt_1829 #### ⏱️ [20:13](https://www.youtube.com/watch?v=jDmtVO30vFc&t=1213) Narrative alignment ### [H9] Frame community work in leadership’s language > [!quote] [Episode 120](https://www.youtube.com/watch?v=jDmtVO30vFc) > “When you’re talking about it to leadership, you talk about it… in the values that they care about.” Translate values, then report progress. [view highlight](https://www.youtube.com/watch?v=jDmtVO30vFc&t=1213) #articleseed ID:yt_2013 #### ⏱️ [21:56](https://www.youtube.com/watch?v=jDmtVO30vFc&t=1316) Tooling note ### [H10] AI can reduce maintainer triage burdens > [!quote] [Episode 120](https://www.youtube.com/watch?v=jDmtVO30vFc) > “It does it by helping actually like with triage and toil…” Pilot carefully with clear safeguards. [view highlight](https://www.youtube.com/watch?v=jDmtVO30vFc&t=1316) #articleseed ID:yt_2156 ## 📚 References - CHAOSS Project — Community health resources (site may change; verify before citing deeply). https://chaoss.community - CNCF — Context for end user and maintainer programs. https://www.cncf.io - Episode video (primary source). https://www.youtube.com/watch?v=jDmtVO30vFc ### 🔖 Zettel Candidates #### Priority equals criticality times health - Lightweight portfolio rubric for OSS investments. Source: H6. - Links: [[OSS-Portfolio]] [[Risk-Scoring]] #### Leaders reject vanity commit metrics - Replace counts with revenue, risk, and time signals. Source: H8. - Links: [[Executive-Dashboards]] [[Outcome-Metrics]] #### Community fixes accelerate resolution - External contributors reduce bug backlog and MTTR. Source: H5. - Links: [[MTTR]] [[Ecosystem-Leverage]] #### Criticality varies across departments - Customize narratives for product, security, and marketing. Source: H7. - Links: [[Stakeholder-Mapping]] [[Message-Market-Fit]] #### Interpret the metrics tsunami - Focus on insights, not raw collection. Source: H2. - Links: [[Metric-Interpretation]] [[Signal-Noise]] ## 🗣️ Paraphrase - The episode explains a pragmatic path to show OSS value to leaders. - It promotes outcome metrics, prioritization math, and clear stakeholder narratives. ## 📰 Newsletter - Showing OSS value got easier. CHAOSS folks outline simple tools that speak CFO and CISO. Use “priority = criticality × health,” swap commit counts for MTTR and revenue-at-risk, and tailor messages by department. WordPress and OSPO friends: borrow the workbook for contributor funding and The WPCC programs. Watch: https://www.youtube.com/watch?v=jDmtVO30vFc ## ✅ Action Items #### DevRel - Publish a “from commits to outcomes” dashboard example. - Record a screen-cast on bug-to-fix storytelling with MTTR. - Run office hours on stakeholder-specific framing. #### OSPO - Stand up a quarterly priority rubric using H6. - Map top-20 OSS dependencies to revenue and risk exposure. - Track bug MTTR and external-fix ratio per project. - Define “health” inputs: releases, responsiveness, bus factor. #### Community - Share maintainer triage wins and playbooks. - Pair engineers with PMs to align critical features to roadmaps. #### WordPress - Core: report external fix assist and MTTR for key components. - Training: add “value framing” module to Learn.WordPress. - Meta: instrument bug labels for MTTR and first-response time. - Plugins: pilot AI triage with human review and opt-out paths. #### The WPCC - Fund an “OSS value workbook” for maintainers. - Offer microgrants tied to outcome metrics, not activity counts. ### FAIR - Publish a transparent scorecard template for OSS investments. - Add provenance notes for metrics and data refresh cadence. ## 🧪 Hypotheses - Reporting MTTR and revenue-at-risk increases executive support. - A priority rubric improves resource focus within two quarters. - Department-tailored narratives raise approval rates for OSS time. - AI triage shortens first-response time without lowering quality. ### 📊 Methodology - A/B executive reports: vanity counts vs outcome dashboards. - Track approval decisions and cycle times across quarters. - Measure first-response and closure times before and after AI pilots. - Survey department leads on clarity and usefulness. ### ❓ Questions - Which health indicators best correlate with outages? - How do marketing-led criticality stories shift budgets? - What guardrails keep AI triage safe and fair? ### 🔮 Future Research - Compare rubric performance across industries and stack types. - Model optimal mix of internal and community bug fixes. - Study long-term effects of outcome reporting on funding. ### 💡 Implications - Practice: report MTTR, risk, and revenue support routinely. - Policy: formalize OSS time via rubric-backed charters. - Education: teach executive storytelling to maintainers. - Funding: tie grants to outcome metrics and service levels. ### 🧠 Learning Styles Assessment - Reading level estimate: Flesch-Kincaid Grade ≈ 10. #### 👀 Visual learners - Present: formula and dashboard examples. - Improve: add rubric worksheet and flowchart. #### 🔊 Aural learners - Present: podcast format. - Improve: 3-minute audio summary and highlights reel. #### 🗣️ Verbal learners - Present: clear definitions of terms. - Improve: glossary for MTTR, criticality, health. #### 🧩 Kinesthetic learners - Present: apply rubric to a live project. - Improve: worksheet with sample data and checks. #### 🧠 Logical learners - Present: prioritization equation and metrics mapping. - Improve: decision trees for escalation. #### 🧑‍🤝‍🧑 Social learners - Present: panel perspectives. - Improve: cohort review of dashboards. #### 🧘‍♀️ Solitary learners - Present: self-paced video. - Improve: reflection prompts after each section. #### 🌿 Naturalistic learners - Present: not emphasized. - Improve: sustainability impacts of OSS health. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: YouTube player supports captions. - Improve: provide full transcript download. #### Keyboard navigation - Present: standard player controls. - Improve: timestamp chapters for key topics. #### Contrast and readability - Present: sufficient by default. - Improve: ensure slides meet 4.5:1 contrast. #### Text resizing and reflow - Present: responsive layout. - Improve: add prefers-reduced-motion support. #### Media and captions - Present: captions available. - Improve: add speaker labels and accuracy review. #### Forms and interactions - Present: comments for feedback. - Improve: accessible survey for episode insights. #### Standards reference - Map improvements to WCAG 2.2 AA criteria. ### 🌍 DEIB Assessment #### Cultural breadth - Present: global OSS relevance. - Improve: examples from varied regions and org sizes. #### Inclusive language - Present: neutral business-focused terms. - Improve: plain-language summaries and glossaries. #### Neurodiversity support - Present: structured sections and repetition. - Improve: icon+text cues and predictable patterns. #### Representation - Present: multiple roles represented. - Improve: more voices from underrepresented groups. #### Psychological safety - Present: respectful framing. - Improve: community guidelines and escalation paths. ### ✅ Logical Validity #### Strong reasoning - Inductive: Bug metrics illustrate value pathways (H5). Clear evidence-to-claim link. - Causal: Outcome metrics drive leadership support (H8). Plausible mechanism. - Heuristic: Priority rubric aids decisions (H6). Simple and transparent. #### Fallacies - Risk of hasty generalization from single org example. Mitigate with multi-project data. - Survivorship bias in “fast fixes” anecdotes. Add baselines and variance. #### Tone of voice - Practical and advisory. Focuses on clarity and action. ### 🛡️ DARVO Analysis - Deny: None observed. - Attack: None observed. - Reverse victim/offender: Not applicable in this context. ## 🎯 Conclusion - Show outcomes, not outputs. Align narratives to leadership goals. - Next steps: adopt the rubric, upgrade dashboards, and pilot AI triage. ## 🏷️ Tag Coverage #articleseed: 5 • #xref: 3 • #share: 1 • #bmf: 0 • #addendum: 1 ## 🧱 Refactor Appendix (append after 🎯 Conclusion) ### 📚 Literature Split Pad - Purpose: Stage Konik CEE units that become per-source Literature notes. - Split level: **H3**. - Include verbatim quotes under 25 words and a [view highlight] link. ### [H1] Podcast targets community health measurement cases > [!quote] [Episode 120](https://www.youtube.com/watch?v=jDmtVO30vFc) by an unnamed author via [[YouTube]]. Published [MISSING]. Accessed {{date:YYYY-MM-DD}}. > “We share use cases and experiences that measures open source community health.” Two lines: how cases translate into metrics literacy and tooling asks. [view highlight](https://www.youtube.com/watch?v=jDmtVO30vFc&t=11) #xref #articleseed ID:rw_yt0011 ### [H2] Guides help interpret a metrics tsunami > [!quote] [Episode 120](https://www.youtube.com/watch?v=jDmtVO30vFc) > “We’ve made it really easy for people to collect piles and piles of metrics.” Two lines: shift teams from collection to interpretation. [view highlight](https://www.youtube.com/watch?v=jDmtVO30vFc&t=256) #xref ID:rw_yt0256 --- ### 🔖 Atomic Split Pad (Zettel Candidates) - Purpose: Promote reusable claims into Atomic notes. - Split level: **H4**. - Each item: one idea, present tense, specific, testable. #### [Z1] Priority rubric guides OSS investments - Use criticality and health to rank projects. - Links: [[Portfolio-Management]] [[Risk-Register]] #### [Z2] Outcome metrics persuade executive stakeholders - Replace counts with MTTR, revenue-at-risk, and risk reduction. - Links: [[Executive-Reporting]] [[Metric-Design]] --- ### ✏️ Fleeting Queue (Extract by Selection) - Purpose: Capture quick actions or sparks for Fleeting notes. - Extraction: **Select one line** → “Refactor: Extract selection to new note (content only).” - Keep each line short and self-contained. - [F1] Build OSS outcome dashboard MVP — context/https://www.youtube.com/watch?v=jDmtVO30vFc #fleeting #inbox - [F2] Draft department-specific criticality prompts — context/https://www.youtube.com/watch?v=jDmtVO30vFc #fleeting #inbox - [F3] Run AI triage timeboxed pilot — context/https://www.youtube.com/watch?v=jDmtVO30vFc #fleeting #inbox <!-- deep-read:sections end --> ## Highlights - **Guides Tame The Metrics Tsunami** - CHAOSS created Practitioner Guides to help practitioners navigate the "tsunami of data" from open source metrics. - The new guide focuses on demonstrating organizational value rather than just getting started. Transcript: Dawn Foster Within the chaos project, historically, we focused a lot on defining metrics and creating software that helps people gather those metrics. So as a result of this focus on metrics and software, we've made it really easy for people to collect piles and piles of metrics, which we affectionately refer to as the tsunami of data. And what we've realized is that people need some help navigating that tsunami of data. So that was the idea behind the chaos practitioner guides. They're designed to help practitioners understand how to interpret some of the data that they have about open source projects, but not just interpret the data, but actually figure Out what improvements they need to make within the open source projects they contribute to or care about in order to make those projects healthier and more sustainable over time. So the practitioner guides really started with a getting started series. We have guides on contributor sustainability, responsiveness, organizational participation, security, how to sunset an open source project, getting started with building diverse Leadership. And so those were the guides that we've done so far. Now, this guide is actually a little bit different because it's the first guide that we've done that wasn't a getting started guide. So this guide is much more extensive. It's much more detailed because let's face it, demonstrating organizational value of your open source efforts is a really complex topic. ([Time 0:02:43](https://share.snipd.com/snip/d214e88c-bf7c-4258-90f1-017bd81711b8)) - **Talks Turned Into A Practical Guide** - Bob's KubeCon and Linux Foundation talks inspired the guide's content. - Dawn adapted much of Bob's presentation material into the detailed Practitioner Guide. Transcript: Dawn Foster Bob was the inspiration behind this guide. Bob did a talk at KubeCon broadly about demonstrating organizational value and then did another talk at the Linux Foundation Member Summit a month or two later. And I was in both of those talks. As I'm listening to Bob talk about this, I'm like, wow, this is a lot of information for a presentation. How can we turn this into a guide that people can use and take away with them? So Bob was the inspiration for this guide. I really took a lot of the stuff that was in his presentations, along with, you know, adding a few of the things that I'd done over the years. ([Time 0:04:39](https://share.snipd.com/snip/6113f889-5957-4339-838d-6c9456cdbca5)) - **ROI Ignorance Makes OSS Vulnerable** - Open source is often an early target for budget cuts because leadership doesn't see clear ROI. - The guide distills how to tell stories that make open source value obvious to decision-makers. Transcript: Bob Killen Sides of the same coin. The one at KubeCon was targeted towards maintainers and sort of how to actually like communicate value. And the other one was the towards like organizations and how to sort of like build a strategy for themselves to create that internally. But the reason why I've been so focused on this is I've spent countless hours of my career basically helping people build strategies and helping them interpret and convey the value Of their contributions to open source and how it can impact business value. One of the big things, especially these days with the macroeconomic conditions is companies are looking to cut where they think they can. And open source has been one of the first things to go because the people making those decisions don't actually know what they're getting in return for allowing like their employees To contribute. This isn't necessarily like blaming the leadership because like we haven't done a good way of communicating that value to the people that are in charge and making those decisions. ([Time 0:05:30](https://share.snipd.com/snip/284385f1-1759-4b83-9c03-489c8cac25e3)) - **Reframing Secured Leadership Buy‑In** - A maintainer team reframed their contributions in business terms and secured leadership support. - They showed revenue impact, low time investment, fast bug fixes, and community contributions to win approval. Transcript: Bob Killen When I talked to them about this, they were talking about like, hey, they're maintainers. Here are our number of contributions in a year and things like that. But like leadership doesn't understand that. They want to know things like how much revenue is supported by this or, you know, what are the risks? What are the benefits? And, you know, how much time are we investing in these things? And so when I talk them through this, we refocus things to be like, okay, first this project that you're maintainers of how many, like what is actually being supported by this? Like how much of your company is like, how critical is this project? How much time are you actually investing in this? And it turns out that like that one project was very critical to their stack, supporting, you know, hundreds of millions of dollars in terms of revenue. Then they had six maintainers that were in there. And because it was actually a more mature project, they weren't actually investing that much time. So it was only about like 10% of their employees, their time. And then the other thing that I like to use a lot is go to because bugs is something that like, it doesn't matter what level that you are in the stack. Leadership understands bugs, they understand stability and the importance of it. And so when we looked at the bugs they had submitted in the previous year, they had submitted 11, six of them were solved by them and five were actually solved by community members. And the mean time to get a bug fixed resolve patch in a patch release cut was like less than three days, which actually turned out to be much more than what they were able to deliver internally On their own internal software development lifecycle. So I had them like focus on it, they told the story to leadership, like, Hey, we're only investing about half a SWE software engineer a year in terms of time. We're getting our bugs fixed faster than we can internally. Some of them are being fixed by community members. Plus we're still getting all the features we want developed out of this. That was a compelling story. And leadership basically gave them the OK, like, you know, feel free to contribute, like legitimately more. They were getting much more of a return. ([Time 0:08:03](https://share.snipd.com/snip/65e50af0-b403-458a-9c9c-c01ed72375fb)) - **Priority = Criticality × Health** - Priority should equal criticality multiplied by health to guide investment decisions. - This frames where limited engineering resources will have the greatest organizational impact. Transcript: Bob Killen We want to figure out how can we make this stuff count in that we kind of have to think about like, what is the criticality of the project for various things? Is this critical to our stack? Is this critical to a marketing strategy? So like we need to think about first, what are the goals? How does this stuff matter to your organization? And that sort of maps into the idea of criticality. It's business risks and opportunities. And then we take a look at the health of the project. Because if you absolutely depend on this and it's supporting, again, hundreds of millions of dollars of revenue for your company and the health of the project poor, that is a risk. I like to think of all this stuff when evaluating is like priority equals criticality times health, which is priority equals some combination of the business risks and opportunities Times the health of the project. ([Time 0:11:50](https://share.snipd.com/snip/a6bc9666-3723-45db-8ee5-3d34068e5d52)) - **Focus On Critical But Unhealthy Projects** - Evaluate projects by how critical they are to your organization's mission and by their health gaps. - Invest limited resources in projects that are both critical and unhealthy to reduce business risk. Transcript: Dawn Foster Is one of the things that I think every open source group within an organization struggles with is that there are so many open source projects that you want to contribute to. The reality is you only have so many people and you only have so many resources. And so what this formula helps you do is really try to narrow it down. So looking at, you know, on the one side, looking at criticality, what are the projects that are most important for your organization? You know, at VMware, we had a strategic projects list, which was basically the list of the projects that were most critical to us as an organization. And then looking at those projects, some of them might be super healthy. They might have all the features you need. And for those projects, maybe you don't need to spend a lot of time. But on the other hand, you will have projects that are absolutely critical to your organization that do require a little bit of help. Of Kubernetes, both when I was at Pivotal and then at VMware after they acquired Pivotal, there were some features that were missing in Kubernetes that we knew our customers really Needed. So that was, you know, on the health risk, that was a big health risk for us as a company, for a project that was really critical to us as an organization. And we put a bunch of people working on, in our case, it was the cluster API ecosystem, part of Kubernetes, because we knew that there were some things that our customers needed that just Weren't there yet. And so we were able to devote people to some features that we needed because we looked at how important this was, the criticality to our organization, along with what are the risks and Parts of the project that maybe aren't as healthy. In our case, it was missing features, but it could be, you know, the health could be measured in kind of any any way. And so I think this is what helps you prioritize your limited resources is looking at which projects are so important to you and really need the help. ([Time 0:13:52](https://share.snipd.com/snip/5c3b7de3-5fe5-4792-8ec0-31bad91ed233)) - **Speak Leadership's Language** - First identify what leadership values before reporting open source impact. - Frame contributions in the organization's language—revenue, risk reduction, marketing impact—not raw counts. Transcript: Harmony Elendu Thank you. So my last focus would be having put all of this together, how do we now tend to report to leadership on the value of the open source efforts as an organization? Bob Killen Understand what is important to your business and is important to your leadership. This might change depending on your organization. For example, a lot of people will think about, we are using this in our stack reasons internally, it's important to us, but there is a CNCF and user member who actually donated projects And has been heavily invested in the projects because they leverage their open source contributions as part of their marketing strategy to assert sort of their technical acumen. And for some of them, they aren't even really using it internally in a way that supports a huge amount of businesses directly in their stack, but it's critical to their overall marketing Strategy. So you need to know first what is important to your organization and then think about how to frame your contributions and things like that in a way that they can understand. If you don't have that and you try and tell them the value of this stuff, you're just going to be speaking different languages. ([Time 0:16:50](https://share.snipd.com/snip/2482b525-d711-463d-b8e7-99975af02789)) - **Don't Sell 'Charity' To Executives** - Avoid arguing that contributions are "for the good of open source" when talking to execs. - Instead present measurable outcomes that align with company goals, such as revenue impact or faster bug fixes. Transcript: Dawn Foster To add to that, I have seen so many people do this very poorly within their organizations because what I see engineers do in too many cases is, you know, leadership asks them why they're Contributing to this project. And they're like, oh, well, it's, you know, it's great for the community and everybody uses it. And it's, you know, for the good of open source is kind of that message. And when you say that, you know, unless you have a very particular type of leadership, that's not particularly common, what leadership hears is, oh, so that sounds like charity. That sounds like something that we don't need to spend engineering time on. So the poor engineer has framed it and the thing that they're most passionate about and leadership is just like, nah, that sounds like something we shouldn't be doing. The other thing I've seen people do is, and I see this, you know, community managers, I've seen this with engineers, is they count things. Leadership asks why you're doing this, why it's important. And they come back with, well, we made, you know, this many commits and this many pull requests, you know, we have this many activities or whatever it is, but they've measured things That are easy to count that no one cares about. Leadership doesn't care how many commits you made or how many pull requests you made. What they care about are the things that tie back to that organization's value. And so this is why it really is so important to be very careful about how you talk to leadership about your open source efforts and make sure that you're always talking about it in a way That resonates with the leadership of your organization, because what you're doing in open source is supporting what you're trying to do as a company or as a business unit or something Like that. That's why it's so important. But what I will say also is the reality is you can do some other stuff too while you're doing that, while you're waiting for that pull request with that big feature to land, you can also Do some stuff in the community and you can do some things that are for the good of the community while you're also doing the things that are super important to your organization. But that's not how you talk about it to leadership. ([Time 0:18:22](https://share.snipd.com/snip/6bbf8fab-088e-4111-be64-1e3d9b08780e)) - **Triage Is A High‑Value AI Target** - Triage and toil consume maintainers' time and are ripe for AI assistance. - Tools that automate triage can free maintainers to focus on higher-value work. Transcript: Bob Killen Community contributions like growing influence in the community if you're going to be talking about them. Thank you so much Dawn and Bob for that insight. Harmony Elendu It's actually time for like our value ads and I actually can't wait to hear you guys value ads. So Dawn, let's have it. Dawn Foster I've built lots of websites over the years for you know every side project or blog or whatever and I've always defaulted to just spinning up a new WordPress instance, which is an awful Lot of work and it cost me money. And I was like, I want to try this whole GitHub pages and Jekyll thing. And it was so easy. It was fantastic. And, you know, I got to play around with a little bit of new to me technology. These are not new at all. I understand that these have been around for ages, but it was just so easy to spin something up. And with way fewer security vulnerabilities, as Bob just mentioned in our chat, I have had my WordPress sites hacked and it was absolutely no fun. So this whole static site approach is great. So I built a little website for my consulting business and it was super easy. That was my value add. That's what I'm thankful for this week. Bob Killen I'll mention dosu.dev. It's a AI thing that I actually like. It does it by helping actually with triage and toil and all the annoying parts of being an open source maintainer. A lot of the tooling out there for AI in the space is focused on code contributions and things like that. But honestly, like the thing that we can lose a lot of time to is that triage and having to spend a lot of time going through things and sorting out what's real and what's not. ([Time 0:20:33](https://share.snipd.com/snip/6ee0d1ec-f2cb-4ca7-8900-d1682354a9d5))