 As it is just about time and this is a much longer deck than I anticipated. I'm just going to dig right into it Hello My name is Bob Killen. I am known as mr. Bobby tables across all the things I am currently a OSS programming manager at Google's Ospo I come from an academic background where I was there honestly far too long but for this I am currently a member of the community steering and former chair of kermase sig contributor experience and For all this though, probably the more relevant thing is like I have been a you know an end user consumer I've been a hobby contributor I've been a maintainer and now a corporate contributor and I feel like on the stamp card of roles in open source The only thing I'm missing is like being in a VC startup Which I don't necessarily want but I bring this up Because I have spent a lot of time wearing these different hats and have had to justify my own involvement or Especially as you know a steering committee member in contrabix help others justify theirs sorry it has given me a Better understanding of the various like issues and various dynamics at play and sort of the ecosystem how all these things come together and More importantly how we surface value Now I generally like to say value over business value because there is so much sort of like say Unrealized potential in products that just exists already It's just not being surface. Well but You know as we can sort of see here most of the contributor base at least within the CNCF is Contributing on behalf of an organization I It might not necessarily be the case like they might my policy where they have to you know do stuff with their work email But in general it that is sort of the case also I'm sorry for the green with the VMware thing that was auto chosen color by Google slides I tried to make it clear Anyway, the interesting thing about this distribution is that it surprisingly carries over to the maintainers to I honestly wasn't expecting this for like the CNCF contributions To be so close to the percentage of maintainers. They're both roughly 95 percent and This trend also extends beyond the CNCF a bit to general open source these days in a 2023 study asking what brings people to open source 52% Contributed in both work and personal time 30 percent contributed in professional time only and Only 18% contributed in personal time only. I know it's not a perfect representation of The you know doing it for work doing it for personal balance, but it's still you know a pretty good decent that like approximate Still it means you know 82% of contributions are doing at least some contributions as On behalf of their employer So the TLDR and all this is so most Contributors are contributing on behalf of their organization And while this is anecdotal. I know there are studies out there that have backed this up Don I should have asked you for them Most contributors like contributing to OSS and which they could just you know spend more time doing it and Ideally that means they're also getting paid to do it. It doesn't necessarily mean Being a full-time maintainer, but at least getting some time and recognition for their work in open source You know, we we also know That the businesses behind these projects, you know for them to succeed We want them to succeed so they can continue to pay Maintainers and ideally hire more The hard part and all this is giving the business justification for it So trying to explain business value can Feel like trying to connect a bunch of random dots together and lots of fuzzy, you know connections and correlations and the people listening to you, you know, honestly might think you're a bit crazy Most of what we know is how to convey is like the general benefits Like influence, you know reduction of risk You know the other benefits like retaining and attracting talent But that is not what most of businesses employers are looking for They are looking, you know, how it works to support the business and the business's goals They're a little more okay with letting people do OSS and you know have those fuzzy connections To value when times are good, but times like now Where people are having to reprioritize and with cuts being made open source will be one of the first things to go unless you can actually convey how it supports the business and I'm going to tie like the upstream work to value and for this there's really like Two standout areas that can kind of help those are data enablement and communication It could be, you know presentation and just sort of more so how we actually convey the information But anyway, let's get on with the data enablement so The big problem is insufficient data in all of this and I can I you know, I know some people might grow in at this But seriously, have you ever been pressed to give like more information about a project and You start looking at it and find it's friggin impossible to do without like a lot of manual collating of data I've been through a lot of these, you know fire drills where it's like we're presenting the leadership tomorrow Get us the data and you know if the project hasn't been Dilligent with their triage their labels and milestones that request Can go from, you know a couple of hours of work to I'm brewing multiple pots of coffee and pulling an all-nighter in the state That state of you know insufficient data is sadly much more common than you would think So I looked at 12 cncf projects at random. I literally random number generator And chose four projects from each tier and frankly it wasn't great Six actually labeled their issues consistently only two labeled their PRs and only seven used milestones By the way when I say it labeled here I'm talking like even basic labels like bug and feature or enhancement, you know And I I made sure to ignore things like depend a bot and all that And things that you know would auto merge You know what makes this even worse is I originally was only doing three projects from each tier But literally didn't have any projects in the first nine that labeled their PRs I'm sorry if my frustration is coming through a bit, but seriously like it's hard to produce data in this kind of state like It's maddening trying to go through like PR PR PR PR by PR issue by issue trying to get an idea of what it actually is and These kind of labels these things It's a big portion of the stuff that's being used by businesses to justify investing in a project And you know ideally giving their employees more time to work in it and more time for them to be maintainers I did jump like on a little bit on like labels and milestones without explaining why But I want to sort of like set the stage a bit before you know really you know exploring them Truly though, I can't emphasize this enough Consistent and descriptive labels provide context right off the bat They help you prioritize and for you know this discussion really help you track trends that are important to you and your organization Fundamentally, they will help you answer questions and express change And with that, let's actually take a look at a couple examples really quick So with labels, you know we can ask how many bugs were in the Kubernetes 1.30 release boom simple query Is PR has a label kind bug and is in the milestone 1.30 get up returns a quick You know answer of 180 another example how are we progressing on cleaning up tech debt in sig node and add the label sig node and kind cleanup for labels and 71 right there Now imagine trying to cross a whole bunch of things and trying to figure out manually this these things gives us things that we can track and Tracking is how we can show impact In this question has you know Kubernetes stability improved over the past six releases or two years I ran the query for each version On here to get you know the number of you know bug PRs You know let's say you know whoever Google whoever made a strong push to pay down bugs After the rise in the you know 1.27 release. Well The line going down is a nicely. We can actually show that they have made an impact and have paid things down To continue with this like what if you if you want to specifically like target regressions easy enough add a label or Bugs for the API server at a label Well, let's say you're you know working on the team that owns cube proxy boom easy at a label I'm sure you're getting tired of hearing this, but you have a metric you can use and show change and show impact When you've heard me talk about the label first all able but So now if you can really imagine doing all that work crawling, you know Thousands of issues and thousands of PRs trying to do all that without labels and having to actually look at those things No, just no In general you won't and you have to fall back to overall, you know number like a PR is velocity But the thing is like that information is so much less meaningful when trying to show you know change in specific areas Change when you've made specific investments or initiatives in an area And you can combine, you know all the label filters with you know say author to get things you have you know personally done for you To show your work or if like you have a small enough team You can actually combine, you know multiple authors in there and show the work done by the team and show it over time And that is incredibly helpful The next thing You've already seen me use them, but really that's milestones Sorry, I don't want to spend too much time on milestones But I do want to highlight it You know essentially they're a logical grouping of issues and PRs When doing milestones Say by release, it's incredibly easy to you know quickly query the items that have gone into it You can sort of you know You can potentially replace that with date range In a github query But you're going to get everything and usually there's going to be multiple issues and PRs That are going to be targeting different releases or branches or whatever and it's it's not going to give you you know Accurate data you get everything So generally as you might guess I'm I'm a pretty big fan of milestones So part of this is you know, it begs the question if labels and milestones are so useful Why don't more projects use them? It's largely triage issues And a lot of projects They just don't do it or they don't do it consistently that they'll do it for a little bit And then someone might get busy and you have this big stream of stuff that comes in and it doesn't get triaged But really like I've spoken to a bunch of different people about why it must have it boiled down to like a few things First in like ye olde github days They did not have a role for triage to add labels and milestones the person had to be granted right access to a repo and You want to be very restrictive with that So kind of understand why it you know, they just didn't know didn't progress The next one I think is an issue with sort of like understanding how they can actually be used You know, some of the maintainers They don't think this stuff actually matters If they have a you know perception that no one uses them They aren't useful and just take you know more work for them to manage why bother You know, even if adding a label or milestone takes a few seconds tops It can just feel completely unnecessary and a lot of work when you're burned out Like I know we've all been there at one point in our lives like where something stupid and trivial is You know would actually be helpful to you But first for some reason it is a mountain of work for you to actually get yourself to do it and That is that is a problem But the last one is you know They thought their project was small them the maintainers of it were you know, they all had enough context and You know that can work But what happens when they start to grow? And they start to actually need this stuff. Well a lot of those old patterns of not Labeling or milestoneing anything just carry over and it it becomes harder And they get in the state of like why isn't anyone helping? Why isn't anyone seeing this stuff? Well, it's hard to actually surface that information Now all this said there are some tools that can actually help make things easier Get up actions has created a nice like ecosystem of things that can you know, you can reuse I have on here Three actions that can help with labeling Copy issue labels syncs issue labels to PRs following like if someone says like fixed issue, whatever It will copy the labels from the issue over to the PR You can also adjust keywords that way. It doesn't actually follow closed ones Or you know fixed fixes some of those and uses your own keyword You can sort of customize your own pull request labor alert that labor will automatically apply labels based on glob patterns Say you're working out on a project with like different languages and you have different people triaging those You can have it label things like dot py with python or you know dot go it go Or you know sub directories Label sinker is just a nice little thing. They kind of copied the what Kubernetes uses for Keeping track of all its labels over the place like copy At least the the style format of them, but it allows you to consistently have the same labels across like all your repos and The last one on here is you know add to get a projects Talking about projects a little bit more later. It is very flexible. It can help you create and manage multiple boards for your own like triage purposes and We'll yeah, we'll explore those a little bit more in a bit. I definitely remind checking it out though The the next thing for those of you that aren't familiar prow is the CI system for Kubernetes It's also pretty much 100% label driven in one thing like any project that I found randomly That was using prow they were labeling everything correctly. So it's just sort of like that pattern carried over There's also a prow GitHub action that Basically copies a mimics a subset of the prow commands without having to actually run an instance of prow so You can use you know the milestones little milestones stuff and labels for things It can also use a proven LGTM to so he forces people to have to reviews before it merges Oh Pretty useful stuff Now one other point on here that I don't have a slide for but I want to mention is Triage is an excellent thing to actually like recruit people with a good knowledge of the project But you know might not have much coding skills To help with they're usually have enough knowledge to be able to go through things and you know figure out like is this And what the root cause of the problem is at least get it to the right team Think like you know sys admins, it's it's also like it's a very good Non-code type role that you can use to recruit people and if you do recruit some Make sure that they actually feel recognized as a member of the project is this There's a lot of people that don't think that this kind of work is you know necessarily important But frankly getting this stuff labeled is the way you get to justify your job And you continue to work on a project. So like to me that's pretty important now the Problem for most of this especially for corporate maintainers is why bother They don't get recognition for their work management doesn't understand. They're told You know to spend less time on the project, but still deliver features Why should they bother? Why should they triage and the problem is that this can help them explain or justify their work And get that recognition You know, I understand why they don't they've lost sight of the fact that you know certain groups in their org want this kind of info and The thing is is like the people that want that kind of info are usually the ones that can make resource adjustments They're the ones that can help with headcount or allocate more time and If you're you know presenting the leadership that you're you know various things like your time to resolve bugs is going Say up along with the bug count and it's taking longer to deliver your features Especially it's like, you know critical to your software stack you start to you know increase the risk and you have you know Potential justification for more time and or more people to help work on the project especially again, especially if it's critical to your infrastructure Let's see the other thing with all this especially if they're giving you more time or assigning more people They want to know that those extra resources Were actually helpful Impactful they want to know in six months that the bug count is going down or the state of the feature has gone from you know Red to green you need some way of showing that information and just telling them that like yep It's good now or you know, we need more resources Isn't going to cut it. You have to give them data and this can give you some nice raw data to back up Okay, I've I've ranted about labels enough Let's dig into the second part of all this and that is communication Matrix is great. I can give you some solid numbers to back up your org's investment But your impact will likely go unrecognized if you don't provide some context and Communicate it in the right way to the right audience So explaining things explaining things in a way that they care about So to sort of like get this section started off I kind of want to go over a few of the players or you know personas that we kind of see in all this You know, we have our Open source enthusiast They're the ones who know how to navigate the you know ecosystem. They could be a contributor. They could be a sysadmin the developer They could be doing it for work or hobby purposes they're you know, happy to talk shop and get into technical discussions about stuff and Honestly, probably a large portion of us here today are probably fall into this category Then we have our maintainer They're like the OSS enthusiast They could be doing this as part of a job or hobby But a good chunk of them are tired under pressure to deliver Some will spend, you know all hours of the day working on the project because they care about them and most of them in my experience I Don't want to sound bad, but like aren't too keen on the whole project management type work They like coding and doing more of that, you know deep technical work Okay so Next Next we have our other sort of four big players you know Leadership the VPs, SVPs, see whatever They're concerned with resources and the overall health of the company Or you know greater org They care about the health of the business. They're looking for opportunities and risks And they are looking for return on investment and they're also the least technical We also have product managers who you know prioritize making the best product They're skilled at conveying technical details in user-friendly fashions But and they desire, you know customer user feedback But tend to be like a lot of them don't know open source very well However, I will say there has been some amazing open source PMs that I've been lucky to know Next we have our managers and leans who are you know concerned about their employees and meeting, you know, their okay ours Better understanding they have a better understanding of tech than like leadership But they have you know good idea the teams and prioritizing, you know a smaller set of objectives, sorry Then we have our end users and you know, they are Prior prioritizing how tools features things like that work for them, you know, what what can they use in their environment? There's a diverse of technical skills, but still, you know, we're we're we're all at a point in our lives where we Where a lot of things are going for our attention So you you you really need to if you want to like attract users or reach them Well to you know talk about things in a very clear concise manner Tldr everything The big thing with like all of this and going forward is if it takes like unnecessary cognitive overhead to actually like Understand the basic terms of what a project does Find your roadmap Or like, you know, look at the various like initiatives you're working on and know what Parts of the project the features and initiatives are at risk You are losing out Significantly you are losing potential users future contributors and you are making it more difficult for yourself To justify further investment of resources So I want to talk I want to go over a few examples of this kind of language stuff that I'm talking about So please raise your hand if you understand what this is about I'll give another minute exactly This was the user-friendly version by the way and then the description of this feature But you know, who would understand that enough on first reading to know, you know, you To try it out and provide feedback now try giving that description to like, you know your VP That's you know, not gonna go over very well So this is the final person actually made it on the public website and You know actually who has a better idea of what this does now, please raise your hand Yeah significantly better So This this is honestly actually where you know pms can be very helpful in trying to break down the technical version of That mess and get it into a more user-friendly fashion The other thing is like with all this it's yeah Part of the way to like encourage pms to work on this stuff is like getting feedback in the OSS version is earlier than you know trying to get in the you know product that you're delivering So there's a chance to actually get things better done the line So let's look at the next example so I'm not going to bother asking people to raise your hand on this one, but You get the idea again. This is the user-friendly version And this is the version that I wrote after after reading this These are both from kubernetes. I don't want to throw shade towards you know other projects But when showing these examples, I can promise you it's it's not an uncommon thing I saw examples like this in every project I looked at So A lot of stuff is actually you know really targeted towards other maintainers and other technical people but The problem is is these people also desire feedback from users also if early on of early on in all this You know when you know features are alpha when they think they can actually make changes I'm sorry, but very few users are ever going to provide feedback if you're giving them these kinds of descriptions Another thing is like if you're having to report On the status of this thing internally to say multiple groups Which is going to be easier to understand by that larger group of people Okay. Yeah, now it's the other thing is like it's not just how we say this stuff But also how we surface this information So in including the you know projects I like randomly selected I did look at others and only a tiny handful of them had like easily discoverable information about What the project was working on things like design proposals or even you know feature tag issues Like there's some blog posts and links There were a few roadmaps that I found but like it if it takes me more than 15 minutes of digging and me being an experienced Person in all this that's a problem so This isn't just a like user problem But if I or a p.m. You know one to give a status update on you know in trying to dig this stuff out and put it together That's a problem And I'm not here to just complain. I there are some options to you know make this better like Publishing a release report with a bunch of information or an annual report But let me actually tell you about my favorite thing that I've really come to know and love. That's github project boards Thanks. Kubernetes Enhancements board. I I really like the new github project boards for surfacing information in friendly flexible ways because Also like these days, I never look at the Kanban version. I only ever look at the table version They're very easy to automate and can have you know selective Field population based off, you know label or milestone You can have different views of the data to cater to like different groups in your project for you know general consumption and You know the the most important thing to like p.m.'s managers, whoever is it's actually exportable to TSV And it's very easy than to import into Into like essentially like Excel or sheets. Okay. I need to speed this along I'm sorry So You can also use them at like as a roadmap to get like a general status update. I just use this as an example It's very easy. So like you can have a published view parse a field in your issue template and Populate that that description with that, you know, actually user-friendly version that I showed and Being able to put all this information in one place in a very consumable way It's very Very like I don't want to say impactful, but like it's very useful You can give users access to it. It's one roadmap And like just being able to import it. You can relate it to like internal initiatives really easily Honestly, it's really nice I Do want to cover about talking to leadership a little bit, but I think most of this will actually be covered in the Examples that I'm gonna cover here in a sec and I want to talk about those so I'm going to fast-forward through this slide I'm sorry. Oh my notes are in here. I will show that after the class Same thing with this. Okay. So now the fun part These are a couple stories based on true events These are based off discussions that I've had. I fudge some of the numbers a little bit But to keep just to keep it like generally anonymous, but they're close enough and the actual outcomes are real So let's talk about the trouble to end user I Was connected with a end user company that was contributing to several open-source projects. They were even maintainers of a hue But they were you know getting significant pressure from above them to basically cut back and drop Either drop their contributions fully or cut back Significantly because they couldn't show the impact of their work So I had a long talk with them I asked them, you know, what they had done previously and what they reported a leadership They list out, you know, what they used what they contributed to they pulled some stuff from like dev stats like Their presence their contributions things like that. They also, you know included a list of you know The features and things that they were driving upstream and using But they were not giving leadership what they actually wanted This is a trap I see people fall into often they can you know give them, you know Information that's easily to get like from dev stats, which is generally great and easy to for us to like produce But they didn't think about what the driving motivator was behind this and didn't think about what you know Didn't think they could gather the kind of information that leadership actually wanted So we went back and talked about like risks and opportunities We need to think about stuff from leadership's point of view They need to provide them With how is the project benefiting the company? Is it critical to their stack? What is the risk if the project goes? You know un-maintained What is the company getting from its people being maintainers? How much time are they actually investing in these projects and that is the kind of information that You know leadership wants they they don't necessarily care too much about the technical details They want to know like sweet hours and things like that So this is the stats from one of the projects they weren't maintaining I like bug fixes a lot because it relates to overall stability and something like everyone understands So in the previous year there were 55 total bugs 11 of them were submitted by this team only six of the 11 were fixed by people of the same team and The mean time for those fixes to be reviewed and merged was three days Which was actually much shorter than the time was to get things merged internally and like that's pretty freaking fast especially Yep with almost half the bugs that aren't actually getting fixed by you So we knew leadership was concerned with sweet time so I asked them seriously how much time do they spend on the project In a given month it turns out actually wasn't a lot about 10% the reason for this is like a lot of Small amounts where like they might have like one part where they're doing four to an eight-hour block So essentially for you know the cost of half a sweep They got the features. They wanted delivered. They had they had their bugs fixed and They did this like that This is the kind of thing that they you know really really liked and they did this kind of You know analysis for a bunch of their projects In the end they gave leadership big spreadsheet. They included, you know, critical criticality They had their sues estimate time per project and you know, it's not great, but they tried Leadership really liked it and from their view in Investing in overall small amount of yearly sweet time was ensuring the service stayed up and stable Bugs could be fixed quickly and honestly from the bugs fixed features delivered and looking at overall activity versus their investment It was a very good ROI, which is what they want And it's that kind of messaging that has landed with leadership Every time I have been in one of these engagements where I've talked to a group and tried to help them go through this kind of problem We are very much out of time so I'm just going to Like jump over this really quick. There was a struggling maintainer. They were the only one left They never surfaced the problem helped them surface that problem to You know a lot put issue template PR template Actually went out and talked to like their boss and other companies that had an investment We're able to get those other companies to you know help Sorry invest people time into it because We were able to get the maintainer block time to Actually, you know mentor these people into becoming new maintainers and one of the the great outcomes in all this is that Once the the maintainers company understood the risk and then they had a single point of failure They actually put another person in this whole mentoring cohort thing So they actually like it was enough of a motivator for them to add another person and and like again De-risk their own usage by getting rid of a single point of failure as well as you know bootstrapping a bunch of other people so This is really only the tip of the iceberg There's a lot more to thinking about the you know business value of open source and how to justify these things Like I haven't touched on KTLO keep the lights on fitting overall project health into this Justifying improvements to documentation other non-code work, but it's a start again. I've had to cram this into 35 minutes I'm already going over time. I'm sorry But you know we can encourage more users and larger diverse pool pools of Contributors if we can surface the innate value that already exists in these projects We can help organizations understand the impact of their contributions impact of their investments by being able to convey Explain the impact of these investments. It creates The business justification to contribute to hire contributors to grow more maintainers and create more sustainable ecosystems Okay, thank you for listening be like ramble on for 30 minutes If you'd like to chat I can be reached by Yep reach my email LinkedIn, whatever Also, they happy to chat after this Last thing and you know metrics related if you could Please leave feedback. I've spoken to a lot of people about this topic. This is actually the first time I put a deck together I already know I kind of need to cut this down to fit it into this time slot To be a bit more effective, but yeah, please let me know if there's anything you think I could do better. Thanks