Slide 1

Slide 1 text

Why is this so Bob Killen @mrbobbytables [email protected] Conveying the Business Value of Open Source HARD!

Slide 2

Slide 2 text

● Program Manager @ Google OSPO ● Previously Academia (16 years) ● Kubernetes Steering Committee Member ● Former Chair of Kubernetes SIG Contributor Experience Bob Killen @mrbobbytables 👋 Hi.

Slide 3

Slide 3 text

👋 Hi. ● Program Manager @ Google OSPO ● Previously Academia (16 years) ● Kubernetes Steering Committee Member ● Former Chair of Kubernetes SIG Contributor Experience Corporate Contributor Maintainer Hobby Contributor End User Bob Killen @mrbobbytables

Slide 4

Slide 4 text

Why is this so Conveying the Business of Open Source HARD! Value Bob Killen @mrbobbytables [email protected]

Slide 5

Slide 5 text

CNCF Contributions CNCF Devstats - Companies Table (All Projects - 1yr) 95.8% Affiliated 4.2% Independent Other Organizations (not VMware)

Slide 6

Slide 6 text

CNCF Contributions CNCF Devstats - Companies Table (All Projects - 1yr) 95.8% Affiliated 4.2% Independent Contributions Maintainers 94.7% Affiliated 5.3% Unaffiliated CNCF project-maintainers.csv Other Organizations (not VMware)

Slide 7

Slide 7 text

52% Contributed in both personal and professional time. 30% Contributed in professional time only. What brings you to open source? - August 2023 Personal or Professional? 18% Contributed in personal time only.

Slide 8

Slide 8 text

TL;DR MOST contributors are contributing on behalf of an organization. MOST contributors LIKE and WANT to contribute more to OSS.

Slide 9

Slide 9 text

TL;DR MOST contributors are contributing on behalf of an organization. MOST contributors LIKE and WANT to contribute more to OSS. And more importantly… To get PAID for it!

Slide 10

Slide 10 text

Explaining the Business Value Trying to make a bunch of random connections about influence, reducing risk of use, and trying to attract/retain talent… Can Feel Like…

Slide 11

Slide 11 text

Explaining the Business Value Trying to make a bunch of random connections about influence, reducing risk of use, and trying to attract/retain talent… Can Feel Like… ...but that frequently doesn’t hold up when pressed for why you should contribute vs. focusing on other initiatives.

Slide 12

Slide 12 text

Data-Enablement Communication Ensuring the right data is available to support OSS investments. Providing context in a human-friendly manner & telling the story of the data.

Slide 13

Slide 13 text

Data Enablement aka label all the things

Slide 14

Slide 14 text

Insufficient Data The Problem with

Slide 15

Slide 15 text

Insufficient Data 50% Labeled Issues Consistently 17% Labeled PRs Consistently 58% Used Milestones Source: ● 12 random CNCF projects ● 4 from maturity tier

Slide 16

Slide 16 text

The Importance of Labels Labels can ● Provide context ● Prioritization ● Scope ● State ● … Answer Questions & Track Trends

Slide 17

Slide 17 text

Examples Question: How many bugs were in the 1.30 Kubernetes release? Query: is:pr label:kind/bug milestone:v1.30 Answer: 180 Question: How are we progressing on tech-debt in SIG-Node? Query: label:kind/cleanup label:sig/node milestone:v1.30 Answer: 71

Slide 18

Slide 18 text

Example: Bug Trends is:pr label:kind/bug milestone:v1.XX Question: Has Kubernetes Stability improved over the past 6 releases? (2 years)

Slide 19

Slide 19 text

Example: Bug Trends is:pr label:kind/bug label:kind/regression milestone:v1.XX Question: Have there been fewer regressions in newer Kubernetes releases?

Slide 20

Slide 20 text

Example: Bug Trends is:pr label:kind/bug label:kind/api-change milestone:v1.XX Question: Have there been fewer regressions in newer Kubernetes releases?

Slide 21

Slide 21 text

Example: Bug Trends is:pr label:kind/bug label:area/kube-proxy milestone:v1.XX Question: Have there been fewer regressions in newer Kubernetes releases?

Slide 22

Slide 22 text

Which is easier?

Slide 23

Slide 23 text

Milestones Milestones offer an incredibly convenient way to associate issues/PRs into a logical grouping (e.g. releases). milestone:v1.30 created:2024-03-01..2024-03-05 VS Items opted into milestone Glob, queries everything between date range

Slide 24

Slide 24 text

Why Projects Don’t Triage Why are so many projects inconsistent with labels and milestones? ● Unaware of GitHub Triage role and believe write access is still required to apply labels & milestones. ● Don’t think they actually matter and are just another piece of “overhead” ● Too small a project to matter or warrant use.

Slide 25

Slide 25 text

Helpful Triage Actions Label Actions ● Copy Issue Label - Sync issue label to PR following “fixed”, “solved” etc. ● Pull Request Labeler - Applies labels to PRs based on glob patterns. ● Label Syncer - Declarative way to ensure labels are consistent across repos/orgs Project Actions ● Add To GitHub Projects - Automatically adds Issues / PRs to project boards based on labels used.

Slide 26

Slide 26 text

Triage With Prow Prow Prow fundamentally encourages label use, and can auto-apply labels via OWNERS files. Prow-github-actions Utilities action that mimics Prow functionality. Example Functions ● /milestone ● /kind ● /area ● /label ● /approve & /lgtm

Slide 27

Slide 27 text

Data Conclusions Consistent data from labels & milestones is crucial for surfacing the state of a project and enabling both contributors and businesses to evaluate the impact of investment. Data provides the evidence to back up your messaging to leadership. Recruiting people to help with triage and using tools to automate the process can ensure things are properly labeled and milestoned.

Slide 28

Slide 28 text

Communication Back to first principles

Slide 29

Slide 29 text

OSS Enthusiast ● Knows how to navigate OSS Ecosystem & projects well ● Does not mind diving deep into technical details ● May be participating as a hobby or as part of their job duties

Slide 30

Slide 30 text

OSS Enthusiast (Maintainer) ● Knows how to navigate OSS Ecosystem well projects well ● Does not mind diving deep into technical details ● May be participating as a hobby or as part of their job duties ● Burned Out, does not understand why more people don’t contribute ● Does “Hero” work to keep project(s) going ● …does not like to do project management / non-code type work …generally

Slide 31

Slide 31 text

Leadership (VPs, SVPs, C*Os) Concerned with resources, health and growth of company. Focused on Health of business, opportunities & risks. Prioritizes Return of Investment. Least technical. Product Managers Prioritizes making the best product. Skilled at conveying technical details in user friendly fashions. Desires customer/user feedback. End User Prioritizing how tools, features, etc can benefit them / their organization. Diverse range of technical skill. Bombarded by options. Managers / Leads Concerned about employees and meeting org objectives. Better understanding of tech and knowledge of what team is working on. Intermediary between team and leadership.

Slide 32

Slide 32 text

Limiting growth If it takes unnecessary additional cognitive overhead to: - Understand in basic terms what that feature does - Find your roadmap or the features & initiatives you’re working on - Know what parts of the project/feature/initiative are at risk You are losing potential users, future contributors, and making it more difficult to justify further investment of resources (e.g. headcount)

Slide 33

Slide 33 text

Example 1 Before: “This KEP proposes an automatic topology aware hinting mechanism that would provide a way for EndpointSlice producers to indicate where consumers should use specific endpoints.”

Slide 34

Slide 34 text

Example 1 Before: “This KEP proposes an automatic topology aware hinting mechanism that would provide a way for EndpointSlice producers to indicate where consumers should use specific endpoints.”

Slide 35

Slide 35 text

Example 1 After: “Topology Aware Routing adjusts routing behavior to prefer keeping traffic in the zone it originated from. In some cases this can help reduce costs or improve network performance.” Before: “This KEP proposes an automatic topology aware hinting mechanism that would provide a way for EndpointSlice producers to indicate where consumers should use specific endpoints.”

Slide 36

Slide 36 text

Example 2 Before: “This KEP proposes to allow mutating spec.completions for Indexed job if spec.completions equals to spec.parallelism before and after the update, meaning that spec.completions is mutable only in tandem with spec.parallelism.”

Slide 37

Slide 37 text

Example 2 After: “Enables autoscaling for Indexed Jobs” Before: “This KEP proposes to allow mutating spec.completions for Indexed job if spec.completions equals to spec.parallelism before and after the update, meaning that spec.completions is mutable only in tandem with spec.parallelism.” I can get behind that!

Slide 38

Slide 38 text

Surfacing Information Information regarding roadmaps, features, and their state should be easily accessible and written for a wide audience. ● Regular Project Reports / Blog posts ● Roadmap on website ● GitHub Project Board

Slide 39

Slide 39 text

Project Boards ● Project Boards are highly automatable via graphQL API ● Support for multiple views ● Exportable as tsv Kubernetes Release Team Board Automation Scripts

Slide 40

Slide 40 text

Status & Roadmap Issue Description Status Notes Target Tracking Issue - “Friendly” short description. - Parsed from tracking issue body - Alpha/Beta/Stable - Red/Yellow/Green - Optional notes to describe status - Parsed from tracking issue body Target Release ● Discoverable and easy to link to ● Provides just enough information to convey feature / initiative state & target release ● Status field can be used to signal things that are at risk ● Easily mappable to internal tracking information

Slide 41

Slide 41 text

Talking to Leadership ● How critical is the project? Can you associate $$ or level of risk with it. ● How many SWE hours are being spent? ● What is the business getting in return for those SWE hours? What happens if you stop? ○ List features, bugs - both driven by you, and ones that your org uses that you influenced, and others that were completely developed by others. ○ Try to associate with anything internal and $$ Leadership (VPs, SVPs, C*Os) Concerned with resources, health and growth of company. Focused on Health of business, opportunities & risks. Prioritizes Return of Investment. Least technical.

Slide 42

Slide 42 text

Managers & Users ● What is the roadmap? ● What is the status of items on the roadmap? And the things directly impacting us. ● What features / things are at risk? ○ If at risk, what is needed? ● What are the blockers / bugs? ● Managers: what is my team involved in?

Slide 43

Slide 43 text

Communication Summary How you communicate value is just as important as the metrics you use to back it up. They are complimentary, and should be used together. Understanding your audience and communicating with them in terms & language they are accustomed to can help you maximize the impact of what you are presenting. GitHub project boards are an excellent tool to use to for triage and sharing information about the status of enhancements, or used as a roadmap.

Slide 44

Slide 44 text

Based on True Events

Slide 45

Slide 45 text

Based on True Events The Troubled End User

Slide 46

Slide 46 text

The Troubled End User ● CNCF End User Company with historically very pro Open Source stance. ● Company’s Software Engineers & SysAdmins actively contribute multiple Open Source Projects. ● Portion of staff are maintainers of several projects that are used in the Company’s stack. ● Recently undergoing significant pressure from leadership to drop / cut back OSS to focus internal initiatives to deliver more “impact” to organization.

Slide 47

Slide 47 text

Understanding the problem Managers/Tech Leads generated a report for leadership about their open source presence. ● Overview of what was used internally in their stack. ● Included stats about influence and “work” done such as: % contributions, # of maintainers, commits. ● Included information about what features being developed upstream were being driven by company.

Slide 48

Slide 48 text

Understanding the problem Managers/Tech Leads generated a report for leadership about their open source presence. ● Overview of what was used internally in their stack. ● Included stats about influence and “work” done such as: % contributions, # of maintainers, commits. ● Included information about what features being developed upstream were being driven by company. Not giving leadership what they want

Slide 49

Slide 49 text

Understanding the problem - What is the criticality of the projects they are maintaining? - What are we getting out of contributing to the project? - How much SWE time is ACTUALLY being spent on maintaining the projects?

Slide 50

Slide 50 text

Bug Fix Stats (prev. year) Bug Statistics (prev. year) Total bugs 55 Submitted by Company members 11 Company bugs fixed by Company members 6 Mean time to fix Company member bugs 3~ days GitHub Query: is:issue closed:2023-01-01..2023-12-31 label:kind/bug ● Filter for company contributors: author:...author: ● Used GitHub API to query created_at and closed_at for each issue created by compantry contributors. ● Scriptable to generate regular report using GitHub GraphQL API.

Slide 51

Slide 51 text

Company Activity (prev. year) Company SWEs: 6 Average SWE time allocation: 10% Total SWE allocation: .6 Company Activity vs Others Project Committers: 54 Total Project Contributions: 4663 Company Contributions: 633 % Company Contributions: 14%

Slide 52

Slide 52 text

Outcomes & Lessons Learned Presenting information to leadership in ways they understand and align with the kind of decisions they were making, worked very well. Tying projects to their stack, and what services it enabled. Let leadership understand the criticality of those projects, and something to “weigh” the SWE investment.

Slide 53

Slide 53 text

Based on True Events The Struggling Maintainer

Slide 54

Slide 54 text

Struggling Maintainer ● Struggling maintainer was the only active maintainer left, others all drifted away from project. ● Could not adequately stay on top of issues/PRs. ● Pressure from $dayjob to spend time elsewhere. Project

Slide 55

Slide 55 text

Understanding the Problem ● No easily discernible way to see state of project. ● No easy way to follow up if someone could commit serious resources.

Slide 56

Slide 56 text

Understanding the Problem Not communicating the problem! ● No easily discernible way to see state of project. ● No easy way to follow up if someone could commit serious resources.

Slide 57

Slide 57 text

Actions Taken ● Updated Issue/PR template, and repo README communicating project is down to 1 maintainer and is at risk of going unmaintained. ● Reached out to known users/companies that have a dependency on project and highlighted risks & opportunities. ● Offered mentoring to those that could commit resources to become future maintainers.

Slide 58

Slide 58 text

Focus: Outreach Reached out to known users/companies that have a dependency on project and highlighted risks & opportunities. ● # of open bugs + rate of being addressed ● Looked at open feature requests ● Drafted “job description” for maintainer role ● Estimated weekly SWE hours for “maintenance” once onboarded ● Proposed mentorship to onboard if they can commit resources.

Slide 59

Slide 59 text

Focus: Mentoring Offered mentoring to those that could commit resources to become future maintainers. ● Convinced maintainer’s employer to let them spend more time on the project for a short period of time to on-ramp others to de-risk their continued usage of the project and let them spend more time on other things long-term. ● 3 month mentor cohort of 8~ people that met “job description” from various vendors and users with the goal of getting 3~ people who could take on maintainer duties.

Slide 60

Slide 60 text

Outcomes & Lessons Learned Framing the problem around what’s important to the company, and conveying it in a way those not “close” to the project understand was essential to getting buy-in. Providing some base metrics (bugs, issues etc) as a starting point, ensured everyone had a way to follow progress and track success.

Slide 61

Slide 61 text

Putting it all Together There is significant unrealized value in Open Source Software. Projects can begin to surface that value by following good triage practices and surfacing information about their state in more accessible ways to support the maintainers and the businesses behind them to justify their investments.

Slide 62

Slide 62 text

Thanks for listening to me ramble for 30min <3 Want to follow up? [email protected] @mrbobbytables https://mrbobbytabl.es Plz may I have some feedback 🙏