 Hi, this is your host Aplim Bhartia and welcome to another episode of TFR Let's Talk. And today, we have two guests from CNCF. Caroline Vance, technical lead of Contributor Strategy and Josh Berkus, chair of Contributor Strategy, of course, at CNCF. Josh, Caroline, it's great to have you both on the show. Great, so it's great to be here. Thanks. Thanks so much for inviting us. Yeah, it's my pleasure to have you here. Let's start with the basic features. I mean, CNCF communities, you folks have, I mean, great contributors there. I think after Linux kernel, you know, CNCF has the most contributors there. Contributors there. So it's also great to see that you do have this committee like Contributor Strategy. So I want to understand what is the goal of this committee? What is it? What does the body look like? The CNCF is a nonprofit that supports and fosters a large number of cloud native projects. I think it's currently somewhere in the neighborhood of 150 projects. And the thing is a lot of these projects consist of folks for whom it is really their first open source project, at least the first one that has had any sort of serious public involvement. And one of the things that originally Paris Pittman and I realized is that these projects could use a lot of the ideas and processes and knowledge that we had generated in Kubernetes, in the Kubernetes contributor experience team. And so we started Contributor Strategy in the CNCF as a way of helping projects sort of level up. My particular focus was actually on project governance was an area that I really needed to be addressed. But there's a lot of other areas such as what we call contributor growth, which is recruiting contributors, et cetera, that Carolyn joined to help with. Yeah, a really common question a lot of projects have is that they know the code, right? They understand how to make great distributed applications and services. But when it comes to how do I find more people to work my project? How do I encourage them to engage and help design solutions and become maintainers for the project? That's where a lot of us, like all of us, even myself stumble. And that's one of the requirements of being in the CNCF is finding a diverse group of maintainers to ensure a healthy project. So something that's very important to all of us at the CNCF is crowd sourcing. I got solutions and strategies for building a healthy, inclusive contributor base and making sure that these projects are sustainable year after year. As Josh was talking about, there are a lot of folks who may have contributed to open source for the first time when they got involved with CNCF or Kubernetes. But there are also a lot of companies also in today's world, you know, almost everybody is using open source and they also want but sometimes they may not even have, you know, they don't even know how to get involved with open source. So does this group also end up helping those companies so that they can very easily come and start, you know, contributing to the very project that they rely on for their own businesses? We really only do that to the extent that we can sometimes redirect, right? Because sometimes for some reason, like we've done a presentation or been on a podcast or something and they don't actually know how to connect with the project. And so if they come to us, we'll redirect and we'll say, hey, here's how you find the maintainer list of the project. Here's how you reach out to them. And then, you know, from there, the project needs to take it in less. The maintainers come back to us and they say, hey, this has been a one company project since we joined Sandbox. This is a common problem. There's been a one company project since we joined Sandbox. And this is such a company wants to get involved with our project. What do we need to do? And that is a common question that we end up helping with. You know, a lot of it comes down to, OK, we need some rules around contributions and around who gets to make decisions and how things get reviewed, et cetera. And you'll maybe need to put a lot of stuff in writing that wasn't in writing before. I think that's the most critical piece of a lot of what we do is that it's difficult to confidently contribute and be a participant in the open source ecosystem when you don't know what the norms are, when you don't know what's expected in you. And a very large part of what we do is we document common norms in the CNCF and we encourage projects to write down how they're different and give people confidence that when they do engage with the project, they won't be embarrassed. They don't have the wrong idea of how things will work and it really just kind of smooth things out all the interactions and makes it a lot easier for you to be confident that this is going to go well. And actually, you brought a very good point. I talked to a lot of folks who contributed their project to CNCF. It's an incubation phase. And of course, everybody, hey, we want to move to graduation and everything else. And as you already said, sometimes one of the biggest contributors coming from the company, so they have to grow the community as well. So what role does the group play to kind of help them? Because once again, they're good at writing the code, but they may not be that great at building a community around the project. Yeah, so some of the things we do is we help create templates that just get you thinking about how you'd like your project and its community to work and also identify areas where you could use help. Maybe you don't need someone to write all the code for you, but maybe you do need help with project management, your roadmap, gaining adopters, putting out content materials for your project to get people excited and help your users level up with using what you have. A lot of times people need to be encouraged to kind of outline that there's more that you can do with open source than just write code. We like to emphasize non-code contributions as being incredibly valuable to the success of your project. The other thing that we do is we provide opportunities and forums like maintainer circle for projects to actually share information about what worked and what didn't, because for example, you can do quite a few different kinds of activities in order to attract contributors. And so one of the sort of important bits of sharing is, hey, what activities worked? What made them work? I mean, as an example, before she actually joined Tag Contributor Strategy, our first familiarity with Catherine was that she actually came to our tag to do a little thing about the, what do they call the program in LinkedIn? They launched a program specifically for highlighting and publicizing new contributors that really worked to get them to attract new contributors, which is really important because it started out as a single company project. So there's a lot of that because most of your cloud-native projects, the people who are in charge of them are primarily coders, they're primarily programmers, and recruiting volunteers, which is really what this sort of skill set is, is not their skill set. And so sharing a lot of information between projects about work and what didn't, maybe even collaborating on things between projects is really helpful. At what stage do you folks get involved when a company makes a contribution? Because CNCF or Linux Foundation in general, you folks also provide a lot of resources, no marketing resources are there. Also, governance projects have freedom to have their kind of own governance, but Linux Foundation, they have their own kind of model that they can follow. So talk about at which stage you enter there and how do you kind of, either it's like onboarding on help them, hey, these are the things. So I just want to understand, hey, somebody just contributed the project and how they are welcome within CNCF. Yeah, luckily it's not, you don't have to do everything all at once. So our pattern is more that we incrementally engage with projects as they mature and their needs and the scope of what they need in their project grows. When you're first onboarded onto the CNCF, we do kind of encourage you to take a look at what contributor strategy has to offer, usually around some of the documents that are required for sandbox projects, which is the very first level when you donate a project to the CNCF. So for example, you're going to need a contributing.md file in your repository when you first join and if you don't have one or you're not quite sure what would be a good one to have when you're in the CNCF, we have templates that get you going, thinking about what could be there. And so usually it's just like one or two things. But then when you submit to incubating, well, now you need to start thinking about a couple more things and then we have more ways to kind of engage with you and provide you more things to kind of chew on. But we don't try to just give you 100 things at once. So for example, we're not asking you to think about security audits or governance models to your project is much more mature. The earliest that we've ever been involved is because people are starting to know that we're around now as a committee. Sometimes projects will reach out to us before applying to sandbox because they know that the CNCF technical organizing committee expects certain things in terms of a project looking open before they join the CNCF. And so they'll reach out to us about their contributor docs or about their governance stocks to say, hey, before we officially submit this, would you mind taking a look and providing us with any feedback? That's more common when they're applying for incubating or graduating. Because incubating and graduating, there's much more serious requirements. So at the incubating level, there's requirements around having the project being open to contributors who don't work for the founders. And so that comes with a certain amount of community participation stuff. And then at graduating, the project needs to actually have a formal governance. And so we'll actually get sort of officially involved at those points. But most of the time, if people in our team are involved, it's going to be either because the project reach out to us because they feel they're at a stage where they want help. Or alternately, because we're reaching out to them around a specific activity that affects many projects, like one of our subcommittees is mentoring, which includes the people who run LFX. So they will reach out to projects specifically around mentoring initiatives. Excellent. So the whole thing is that even if there's a company, a project that considering contributing their code to CNC, if they can get your help so that they know the processes and how to. And also they can also get involved at later stages when they are planning for incubation or graduation of the project as well. So basic idea is to help them get better footing with open source and CNC. Excellent. Now, as you also said, sometimes they approach and sometimes you reach out to them. First of all, who can join the group from what I hear from you? It looks like if you're interested in contributing your project, this is the place you should get started. But what are the official guidelines? Anybody who has the time, honestly, we could really use some more volunteers. We've had a number of initiatives that people have proposed that we have not been able to follow up on because we have the sort of limited pool of volunteers. So like the other tags and tag stands for technical advisory group, I think, they're all volunteer committees. So anybody can join who wants to volunteer. And to avoid you having to have 20 years of experience, we have or divided up into subcommittees. So you can focus on one thing. There's a governance subcommittee and contributor growth and contributor tools and mentoring. And we have somebody who's once again trying to restart the diversity committee and there's maintainer circle. We just had, believe it or a new volunteer, because we haven't had a volunteer who was focused on the maintainer circle meetings, we haven't been having very many. And we just had a new volunteer join in November, who said, that's what I want to do. And so as a result, we're going to have, you know, probably, you know, three, four or five of them this year when I think we had one, two last year. So. And so there's lots of opportunities if somebody is interested in this, you know, organizing projects, helping projects be better open source projects. You know, if people have a little bit of time to put into it. Is there some kind of commitment needed also from there? You're like, hey, you know, if you're joining us, this is the amount of time we do need from you. It's not like you just joined it and you never showed up. So if somebody is like trying to join, what kind of commitment they should be like, like making so that you are benefiting from them and they are benefiting from you folks as well. I would recommend that if you're interested in being a contributor intermittently, like, you know, sometimes, you know, I have time for this weekend or whatever, but you can't say six months in the future, a really great way to contribute is to be not in a leadership position, but show up to the meetings, listen to what people are asking for help with and just pick a task and help with that one task, you know, on the weekend or a week or whatever. When you when you know I have time, I can do this and I can provide like a good chunk of work, right? But if you're interested in, say, for example, helping to lead one of the larger initiatives, I would expect that at least for the next six months, you're like, I can do an hour a week to attend the meetings and help coordinate people. For people who just have a little tiny amount of time, like any open source project, we have a repository that has a list of open issues. So I mean, you know, somebody can get involved without even directly interacting with us, just pick up one of those issues and say, Hey, you know, I did this, here's the document or here's, you know, the piece of automation code, check it out. You're talking about in the areas that you're still looking for volunteers. What are the areas where you feel that, hey, you need some volunteers in this area or it's like something because people come, keep coming and going. It's not a certain or you do feel, hey, we need some folks in this specific area. I would say that when we first started, we started actually in 2020, January of 2020, and it's been a long road for a lot of the original founding members and leads in these groups. And so for some of us, it may be a great time to transition and bring someone on with the idea that very quickly they could become one of the new leads for one of these initiatives, because obviously we always see people to help with the daily tasks and everything, but we are super keen on having more people engage with, say, the governance working group that we have or the contributor growth working group, which is some of our larger, most impactful groups at the moment and getting people to not only contribute, but eventually maybe take over running the weekly meetings and help setting our direction and roadmap for where we'd like to evolve these projects over the next year. I'm going to say a few other very specific things. So like the governance subcommittee right now is actually the people it has been for a couple of years. And so we're really looking to add a couple of new people so that rotation is possible and honestly, because more projects are asking for governance help, which is a good thing, but it means that like Dawn and I are starting to reach capacity there. And for contributor growth, the requests are kind of endless. We have a whole ton of more documentation and updating some of the old documentation and advisory and that sort of thing. As well as, if you really feel like it, working directly with projects to help them on contributor growth initiatives and then writing that up. For mentoring, a reasonably good handle on LFX, but we could really use volunteers who are dedicated to Google Summer of Code and to Outreach Eve and then somebody else who's maybe dedicated to senior mentoring. So that is instead of mentoring new contributors, mentoring existing contributors who are moving up to being like reviewers or maintainers, because that's something that projects need a lot of help with. They need a lot of help for how do we do that? And having somebody who was in mentoring, who was dedicated to that would be really good. And if you are technical and would rather write code, I think container tools has lots of to-do items. Contributor tools, contributor tools. Yeah, contributor tools just give people a little hint about what that is. Is oftentimes in order to run a large scale project and manage interacting with the community at scale, you'll see tools pop up. So for example, in the Kubernetes space, there's a tool called Prow, which helps them label issues, assign them to people, find reviewers, kick builds, all sorts of stuff. But if you're a smaller project, usually there aren't tools like that that are just available for free that work really well with the open source workflows that we have. And so we're hoping to kind of fill gaps and create little tools that a good chunk of CNCF projects would be interested in just picking up and using as a building block to help manage their community. And you two folks are in the leadership position. What kind of mentoring is also there for, you know, so that if somebody is like, or what things are in the process to hand over the bat into the next, you know, leader of the project, the group? So people moved up to leadership. Generally, the process is that you start in one of the subcommittees with whatever, you know, issue is the most interesting to you. And then you just end up showing up more and more and taking on more and more stuff. I, you know, definitely that was Catherine's route. And so that would be true for sort of anybody is, you know, first become leadership on one of the subcommittees. And this is honestly true for a lot of open source projects, right? For a lot of open source projects, right? You start out by, you know, contributing to one of the repositories of the project and then becoming a, you know, a reviewer, a maintainer on that repository. And then you learn other stuff about the project, you become a maintainer on the whole project. It's really not different. The, we haven't had enough people showing up to need any kind of formal program around that. You know, because we're only dealing with one or two folks at a time, we've just been doing the thing where, hey, we just hand them responsibility for more and more things. As, as they are able to. If you look at 23 is the beginning of the year. What are the things that you folks are looking at, you know, that, hey, in this year, this is our goal. This is what we want to achieve this year. But I know it's on my list, you know, on a personal level, is that one of the most common and most difficult asks from projects to the contributor growth working group is we're a project that was originally founded by a single company. And now we really need a more diverse group of maintainers who are being supported by other companies. So maybe, you know, like a project I started as Porter, it was originally all people from Microsoft. And then over time, like, how do we get contributors from other companies? And really that is a super difficult question that to this day, we don't really have like written guidance that says, you know, one, two, three, this is how you attract senior contributors who are at other companies who are being basically usually being paid for their time and get them to become a maintainer on the project. So this is something that we started with this survey that we put out to the CNCF contributors and tried to ask them whole sort of questions to understand where are their difficulties in joining projects? Is it coming from their employer? Is it coming from maybe problems figuring out how to contribute to the project to identify maybe somewhere the problem points that we can help projects understand that they can improve and help bring in more senior contributors. But I think the next steps is maybe doing one-on-one interviews with people and maybe some trial and error of having projects test out different strategies and share what they've done and been successful with because one of the requirements as you move along with the CNCF and move up is that you need to have more than one company essentially supporting the project so that it's healthy. And by the end of the year, I want us to have robust, vetted advice that people can rely on that isn't wishy-washy. You should be able to follow it and have some success or at least an understanding of where you should improve if it's not a prescriptive strategy. One of the sort of minor things for contributor growth is the CNCF has launched this currently beta site called Clotributor and it collects help-wanted issues from all across the CNCF projects. And so one of our sort of tactical goals is to help projects make use of that because one of the requests we've had from potential contributors for a while is to have sort of a jobs board that is... So if somebody can come in and they can say, hey, I'm just out of Rust Bootcamp and I'm a Rust contributor now and I know a little bit about databases, where can I help? So now that the tool exists to help projects actually make use of it in order to attract additional contributors. You already heard about what mentoring is looking for in those terms. And then for governance, we're looking to finish a bunch of our documentation and to more formalize. So we proposed to the TOC that a governance review be made a formal part of the graduation review. It's been an informal part for some time. And they said, yes, which means we now need to actually create the process for that formal review. And of course, do it because they said, yes, and here's a project that wants to graduate. So that's going to be sort of one thing. It would be really nice to actually seriously restart the diversity subcommittee. We keep having the issues that a lot of people are interested in that topic. They really recognize it's something that needs to happen. But we never get the dedicated volunteers with time available to actually follow through on it. Josh Kettleman, thank you so much for taking time out today and talk about this group. And as usual, I would love to have you back on the show or maybe we'll see you at KubeCon in Amsterdam. Thank you. Great, thank you so much for giving us opportunity to get the name out here. Okay, thank you.