 Today, I'm gonna talk about good governance for CNCF projects. For those of you who aren't sure why you should even care, I'll start by talking about why it's important. Then I'll cover the CNCF requirements and the templates we have to help you. I'll talk about setting expectations by clearly stating your mission, your values, your scope for the project. I'll talk about roles, responsibilities, processes, and procedures, along with how you can use a contributor ladder as a path into leadership. I'll also cover how corporate ownership can impact your project, and whether contributing your project to the CNCF might or might not be a better choice for your project than keeping it internally. Then I'll conclude with links to some resources and a few final thoughts. But first, I'll start by telling you just a teeny bit about me. I have been in the technology industry for well over 20 years, working mostly on open source projects from within companies like Intel and Puppet. And now at VMware, I'm responsible for our open source community strategy within the open source program office. I'm also on the steering committee for the Linux Foundations to Do group. I'm a board member at Open UK. I'm a governing board member and maintainer for the Linux Foundations Chaos Metrics project. And I have a PhD that I got by researching how people collaborate within the Linux kernel. So you can call me Dr. Don. I spend a fair amount of time as part of my work as co-chair within the CNCF contributor strategy technical advisory group, so tag contributor strategy, especially as part of the governance working group. Where we put together guidance and templates for CNCF projects. So quite a bit of the work that we've done collectively as a part of that group is the foundation for this presentation. And you'll see loads of links just sort of sprinkled throughout the presentation to some of our resources. Now a lot of people like to hate on governance. It's just paperwork, it's busy work, it's politicking that gets in the way of doing the real work on the project. But this isn't true of good governance. Which is really about getting your ducks in a row, just like the slide, to generate alignment and get all of the various people within your community actually collaborating together. Governance is also one of those things that you may think you don't need. Until you realize that you do, because by that time I might be too late, right? Because something's already gone wrong, expectations aren't aligned, and you're probably seeing some unhealthy dynamics within the community. Now governance helps outline the expectations around roles and responsibilities along with the decision-making processes. So it's important to have these in place early. Governance can be found in all open source projects in one form or another to specify the processes for how people work together within the project. Ideally it will be clearly documented and explicit. Ultimately the focus of open source governance is on people, the roles we play, our responsibilities, how we make decisions, and what we should expect from each other as part of participating in the community. It's usually easier to set clear expectations up front rather than realizing later that various people have very different expectations, which can take a lot more time and energy to sort out after the fact. This doesn't mean that you need to specify everything up front, and I would discourage you from over-engineering your governance processes before you need them. A project with only a few people will not need elaborate elections to select your maintainers or leaders, but you should probably define a few basic roles, the process for contributing to your project, and how decisions about those contributions are made. The goal should be to make the processes for participation as obvious as possible, even for people who are brand new to the community. Having clear rules about how collaboration occurs and how decisions are made helps community members make contributions that are likely to be accepted and embraced by the project. A healthy project with clear governance helps keep your contributors happy and helps set your project up for future growth and long-term success. Now, I suspect that some of you are still thinking that you really don't need governance. You don't need to spend that time documenting it, but if you think about this from the perspective of the brand new user, the brand new contributor, it's much more difficult to participate in a community if you don't know anything about the role you might play, the expectations, the key players, or the rules for participating. Explicit documented governance gives new and existing contributors a clear path to help guide them through your project. When I start contributing to a new open source project, I want to know how decisions are made and who makes those decisions, which helps me understand whether decisions might be made fairly based on solid information with the involvement of the right people with the right expertise to make those decisions. I also want to see a clear path into leadership for me or for my colleagues if we decide to embrace the project over the long term. Undocumented or vague governance creates an unhealthy dynamic within open source communities. What happens when a decision seems unfair or technically questionable and it's not clear who made that decision or where to escalate it? This leaves community members frustrated and can cause people to lose respect for the project and also lose respect for the people who are running the project, which can lead to projects becoming unviable if that dynamic continues and people aren't interested in participating. The bottom line is that if the processes for collaboration and decision making are not clearly documented as part of the project governance, it introduces a lot of uncertainty into the mix and increases the barriers to contribution while also jeopardizing the health and the viability of that project. Now the good news is that TAG contributor strategy and other CNCF groups are here to help you. We have loads of resources for you to use to make it easier to get started with leadership selection and other governance documentation, including several governance templates that any project can use. But first, let's start with the requirements. By the time a project graduates, the CNCF requires that each project have explicitly defined project governance and a committer process. This is preferably laid out in a governance.md file that references owner's files showing the current and emeritus contributors or committers and you must have at least committers from at least two organizations. However, we do not recommend waiting until you get close to graduating. Having clearly documented governance model from the start, even before you apply to Sandbox with something really simple, will make your application even stronger as you move through Sandbox and into incubating. For the incubating stage, the CNCF requires that the project have a healthy number of committers as defined as someone who can accept contributions into some or all of the project. While a governance.md and owner's files aren't explicitly required at the incubating stage, you will find it very difficult during the due diligence process to prove that you have a healthy number of committers without a documented governance model. So we really recommend that you have it way before you start the process to become an incubating project. Now we provide several templates to help you put all of these pieces together and make it easy to set up a basic governance model for your project. For most projects, the maintainer template is the right place to start because it's relatively simple. It's pretty easy to get it all set up. And the way it works is that existing maintainers get to select or approve any new maintainers. And this can be done in a variety of different ways. And you can build on this with our contributor ladder template, which lays out several different types of roles so that contributors can move into positions of increasing responsibility, like reviewer or maintainer. And we have a reviewing template to help projects define a process for reviewing full requests. These two contributor templates are really designed to be used along with our governance templates. Since one of the main purposes of having a governance model is that it should facilitate contributor growth to allow people to become leaders and help spread the load to avoid burning people out. The other governance templates are really useful in certain situations for larger projects. A small project, as I said before, does not need elections. But when you start to get a lot of contributions from people working at a wide variety of organizations, an elected steering committee or technical oversight committees can really help you ensure that the project is governed in a neutral way that doesn't bias the project toward a single company. We also have a subprojects template, which is a little bit niche and is only used in cases where you have a larger umbrella project with smaller subprojects underneath that operate mostly independently. It takes some ideas from the Prometheus governance and has been used by Convayer, which is currently applying to the CNCF. Now, the rest of the presentation is going to dive into more details about how to set up governance and related processes for your project. But I wanted to mention that the maintainer section of the CNCF contributor website is where you can find a whole bunch of these resources. The governance section has an overview with more details about what governance is and why it's important. The charter section talks about defining your mission, scope, values and principles. And finally, the leadership selection section gives a bunch of examples of different ways to select leaders for your project. But as I mentioned earlier, community and contributor growth are also very important as a part of your overall approach to governance, which is, after all, again, about the people. So you'll find useful governance information kind of spread out across all sections of the contributor website. I mentioned earlier that governance is all about alignment and getting all of the various people within your community collaborating together. And setting clear expectations helps facilitate that alignment. One way you can set expectations is by being clear about the mission values and scope for the project to avoid misunderstandings later. In general, you can think about these things as a project charter, even though most open source projects don't necessarily label them as a charter. You should also plan for your mission scope and values to evolve over time as your project grows and changes. And the link on the slide talks more about each of these pieces with examples from CNCF projects to get you started. Now, in most open source projects, there isn't anything labeled as a mission statement, but there's usually something that talks about the purpose, the advantages, and the key features for your project. It's usually a couple of sentences near the top of the readme file that helps people understand what your project does, why your project is important or useful, and usually includes a mention of at least a couple of the key features for your project. And this information helps people who are coming to your project for the first time get a quick summary. And this is where they can learn about your project and whether it might be a good fit for their particular needs. So I usually recommend that this information be in the first paragraph of your readme where people can really easily find it. The project scope is another one of those things that's too often overlooked in open source projects, and it is really, really important. The overall cloud-native ecosystem is complex and many projects have overlapping functionality. Documenting your scope can help end users understand how your project fits into this whole overall ecosystem and how it compares to some of the other alternatives. And this is where you can be really clear about what your project does and just as importantly does not do so that you can set expectations and help avoid misunderstandings. This can avoid situations where some new user or contributor starts using your project under the assumption that they can contribute some feature that's key to their business or that they absolutely need. And then they realize it's gonna be out of scope, possibly for very good architectural reasons or whatever, but you could have saved them some time by documenting your scope to help set those expectations. The scope documentation should cover what your project does or does not do. While your values or principles help people understand how you work as a project and as a community. And the values are included in all three of the governance templates, but they can live in your read me file, the governance documentation, or as a standalone document that you link from your read me and governance files. I've included a few examples that are commonly used in open source projects, but these are not a repeat not a one size fits all approach. They do need to be customized to reflect how you work within your project. And they should be realistic and achievable. If you can't actually live up to the values of principles documented for your project, you're setting yourselves up for misunderstandings and disappointed community members and contributors. I mentioned a few times earlier the governance is about people, defining the roles and responsibilities for the people in your project is an important part of governance along with defining the processes and the procedures that drive that work. There are a few documents that every project, even the small ones should have. You should have a code of conduct that people can easily find with details about how to report incidents along with the consequences of what happens when people violate that code of conduct. Your contribution documents should provide enough details about the contribution process so that someone new to the project can make their very first contribution. This includes details about any contributor license agreements or developer certificate of origin processes that you might have. And if you have strong preferences about things like coding style, testing, documentation or other requirements, this is a good opportunity to make sure that new contributors know these up front to make it easier for them to participate and reduce work or reduce rework. You wanna make sure that your contributors know what to expect and how to navigate the project when they're making their contributions. The communication process should be clearly defined so that people know where and how to communicate with the project. Maybe you prefer mailing this discussions or Slack messages or issues for feature requests. Maybe you prefer, maybe you have separate communication channels for users and developers. Make sure that everyone understands how people within the community, within the project communicate with each other to avoid a frustrating experience both for new and the existing contributors. Well, not strictly governance related. Security is kind of a related topic and I wanted to mention that TAG Security has a bunch of templates and links to resources to help CNCF projects create a robust security policy for their projects. You should be using some automated tools like Dependabot, for example, to help keep up on top of potential security issues. The project should have a security.md file along with possibly other documentation with details about the process for reporting and then responding to security concerns. At a minimum, you'll want to have a way for people to privately report security issues and have a few people who are designated to handle those issues. Projects that are used by vendors within their commercial products or with other people who are end users who are adopting your projects should also have things like embargo lists where you can provide information to vendors and give them time to prepare their security fixes for their products in advance of the issue becoming public and to help them avoid being exploited. Project leadership is one of the key elements of good governance. So you have some kind of documentation about your leadership. For small projects, you might just need a list of maintainers that indicates which people are responsible for various areas within your project and how new maintainers are selected. Defining the roles and responsibilities for contributors, reviewers, and maintainers is probably enough as a first step which can help with recruiting people into these roles. And I talked about the contributor ladder earlier and it's important to make sure that people understand how they can climb this ladder and gain responsibility within your project. For bigger projects, you'll want to have more details about the specific responsibilities for each leadership role along with how people can move into various different types of leadership positions. You might have committees, working groups, special interest groups, or other groups that will need leaders. And again, having this all documented, can really help you recruit new leaders as you grow the project and need more people to share the workload because you will need more people to share that workload. There are quite a few different options for selecting leaders as part of defining your governance. And the ideal is to have a process that provides some sort of level, fair and level playing field that defines how contributors can become leaders. This should be documented again so that all participants can clearly understand the criteria and the process for moving both into and then also out of leadership positions. Most of the bigger projects like Kubernetes, Knative have an election process, at least for the top levels of leadership like the steering committee or technical oversight committees. At lower levels of leadership, most projects have a process where existing leaders get to select new leaders. So for example, new maintainers are often nominated by existing maintainers and approved after a certain percentage or number of maintainers agree. There are a bunch of different options for selecting leaders so I'm not gonna try to cover all of them here but this link at the bottom, there's an entire document devoted to these various options so you can visit that link and get more. And also I should mention the slides are already up on schedule so if you need the links, they're already there. Your project governance should be designed to keep diversity, equity and inclusion top of mind. Building a diverse community where all people feel welcome and included does not just happen. It requires putting work and thought into it. And when you're starting a project and thinking about governance, this is the perfect time to do that. Providing an environment where everyone, including people from marginalized populations, feels safe is the first step toward building a diverse community around your project. You should also look at whether you have a diverse set of people at every level within your project but especially in those leadership positions. And if not, come up with programs that help underrepresented folks get involved and then move up within the project. Ideally having programs that provide opportunities for things like shadowing, mentoring and sponsoring new potential leaders can help you grow a diverse set of new leaders within your project. The Kubernetes contributor experience special interest group is a great place to see examples for how to implement programs for things like shadowing and mentoring. Projects that make a concerted effort to actually bring new people in from a variety of backgrounds and have programs in place to help them grow into leadership positions are more likely to benefit from increased innovation and have a healthier community. Now diversity and inclusion can also be difficult to measure. But we've defined a bunch of metrics, you see the link here, within the KS projects diversity and inclusion working group. So you can have a look at that for ideas about how you can measure various aspects of your project so that you can improve your project's diversity, equity and inclusion. An important aspect of governance is ownership or control over the open source project and the community. So projects that are owned by foundations and ones that are controlled by an individual company have very different dynamics. So I wanted to end by talking a bit more about the decision to put your project into the CNCF. Open source projects that are controlled by a single company can be a concern for outside contributors because they operate at the whims of that company. And there's very little recourse for those of us on the outside when that company decides to go in a direction that doesn't align with the expectations of the other participants within the community. And this is why governance documentation is particularly important for these projects. If the project is truly open, the governance should specify how people can move into leadership positions with the assumption that you'll eventually have maintainers from outside of your company. On the flip side, if you actually have no intention of allowing people from outside of your company to move into leadership positions or make decisions, then you should just be clear about that in your governance stocks. And you should continue to own it within your company since these projects aren't really candidates for neutral foundations like the CNCF. And while it's not ideal, I actually have a lot more respect for companies who are honest about how others can participate than ones that claim to be open while still making all the decisions behind closed doors within their company. Now with neutral foundations like the CNCF, your projects and users get access to increased innovation from a whole diverse set of contributors. One of the reasons that Kubernetes has been so successful is because it was contributed to the CNCF. Putting Kubernetes into a neutral foundation provided a level playing field where people from a whole bunch of different companies could work together as equals to create something that benefits all of us, the entire ecosystem. At VMware, we believe that contributing open source projects to neutral foundations is important. And it's something that we do regularly for projects once they start to get a bit of traction from people outside of our company. Now the challenge with contributing projects to the CNCF is that you also give up some of your control. Existing maintainers will usually keep their positions. However, as we talked about earlier, the CNCF will want to make sure that it's easy for people from other companies to participate and move into leadership positions. So as the contributing company, you should expect for some leadership positions to transition to people from other companies, at least over the longer term. Well, this does mean giving up some control over your project. Putting your project into the CNCF gives others more confidence that they can contribute as equals. However, we all need to remember that contributing a project to the CNCF is an ongoing commitment. It is not an exit strategy. And we need to be prepared to provide staff and other support over both the short term and the long term for this project, just like we would if we weren't contributing it to the CNCF. The CNCF will expect you to do the hard work of building a community, growing your contributor base, getting adopters and all of the other hard work that comes with building a healthy and successful open source project. Now this means that while contributing a project to the CNCF gives you benefits, it is likely going to be actually more work than keeping it inside of your company. So you just need to be prepared to give your employees the time to do that work. Governance is one of those things that it's never finished, right? So we work in a space with constant change, technologies change, strategies change, the whole way we work changes. Everything changes and our governance needs to evolve right along with these changes. In particular, open source projects as they become more mature and grow, what they need from governance will change pretty dramatically. The governance process as you need when you have a single or only a couple of maintainers is likely to be insufficient if the project grows dramatically. So as your projects evolve, your governance should evolve right along with them. Before I wrap up this talk, let me leave you with a few resources that you might find useful. So you've seen the links from the contributor strategy tags sprinkled throughout the presentation. The open source way guidebook has an entire chapter on governance along with loads of other details about open source projects. The Jadoo Group has a bunch of guides about creating and managing open source projects and these are all great starting points. Now I've talked a lot about tag contributor strategy today and here's where you can find us to get help for your project or to volunteer to help us to build new resources. We're pretty active on Slack and that's a good way to reach all of us. The mailing list is relatively low volume and it's a great way to get notified about meetings and other tag activities. As I mentioned earlier, you can drop into our meetings to get advice or to join us. And I encourage CNCF maintainers to participate in our maintainer circle meetings. If you need a resource that doesn't exist, there's a good chance that someone else needs it too. So we encourage you to join us and help us build new resources. Now we've only been around for a little over two years and we have loads of ideas on our backlog but only so many people to work on them. Anyone can drop into our meetings if you'd like to join us and build something together or just to let us know what you need. Tech Conservator Strategy is more than a place to develop resources. We're creating a cross-project community of maintainers that can connect, exchange ideas and support each other. Managing an open-source project can be challenging but a supportive community can provide resources, advice or maybe just listen when you're struggling with something. So you can drop in for advice about any aspect of contributor strategy for your CNCF projects and we are here to help you. And when you use our resources, please let people know, join our community, meet our team and get involved with the tag. There are so many aspects of good governance for open-source projects and I only had time to talk in detail about some pieces of them. But taking a step back and looking at the big picture what I have here on the slide is the common theme that drives why I think that governance as a whole is so important. Governance provides a framework for setting expectations for roles, responsibilities and how people within your project should behave. By clearly documenting these expectations you can reduce uncertainty and make it easier for people to know how to participate in your project. The more you can do to help everyone participate in meaningful ways, the more welcome they'll feel within your open-source community. With that, thank you for coming to my talk and we can open it up for questions. I think we have about five minutes for questions, six minutes maybe. You can step up to the mic. I see Celeste making a move for it. I love this talk because I am a technical writer and basically the summary of this talk was you need to write documentation on dot, dot, dot. So my question for you from a maintenance perspective and for somebody who has quite a bit of experience in open-source is what have you seen go wrong as a result of people not writing their governance down? Tell me the horror stories, Don. Yeah, so I have a recent one. I'll leave the community unnamed but it was something that we wanted to participate so we wanted to use it at VMware within some of our products and it's owned by a single vendor. We tried to get kind of involved in that community. I had lots of governance discussions on their forums about how we could set up something just really simple just like let's document some maintainers, let's document how this process works and I just got epic levels of bike shedding and just really frankly toxic behavior. To the point where I left the community, gave up on them ever having good governance and we're not recommending that products use them within VMware. It's important to hear, but thank you for the wonderful answer. Yeah, it was awful. It was a terrible place to be. I'm just gonna say that it's awful. Thank you. You're welcome. Any other questions? Yeah, step up to the mic. Hello. Hello. So open-source communities need people on their time. I'm just wondering does the advice you give reach out, extend to strategies about convincing companies to allow their engineers to contribute to open-source and how you convince them that it's worth their while? Yeah, so that could be a whole other talk. That can be hard, right? And we see that even internally in various bits within VMware. We have different business units that are really great at giving people time to work on open-source. Others that we're continuing to work with to help them understand why it's important. But one of the things that can really help is by being able to justify the work that you're doing in open-source and tie it somehow back to something that is important strategically for your company's business. So for VMware in particular, it's a pretty easy sell for us to get people involved in the CNCF cloud-native projects like Kubernetes because we're building entire product lines on top of these technologies. So we can make a case that it's strategic and it's important for VMware for us to be there. For other projects, it's always harder to make that case. But generally, the case that it's the right thing to do, it's charity, it's a good thing for the community, those generally don't fly with executives. So I always try to find something a little more tangible that's like, this thing is strategically important for us as a company. And here's how my work within this community will help us do that. So what you're saying is people are lazy and self-interested. Something like that, yes. I guess just a final, so is that kind of within the remit of the contributor strategy sig or is that a perhaps different topic for a different part of the CNCF? No, we do talk about that a lot within the contributor strategy sig, for sure. We actually have another working group that's called the contributor growth working group that tends to dive more deeply into that particular, particular topic. So if you're part of a CNCF project and your challenge is trying to get people involved in your project, you can come hang out with us and chat with us. You can talk to us on Slack, you can drop into one of our meetings, we're happy to help people, at least for CNCF projects. Growth, okay, I'll remember that. Thank you. All right, thanks. Next question. Hello, hi, thank you for the talk. I wanted to ask if once a project is part of CNCF, is there a framework that the CNCF kind of holds the projects accountable if that they are sticking to the contributor guidelines or being more inclusive? Is there a framework around that that the CNCF implements in terms of licenses as well, in terms of people who, in terms of giving up control and letting other people join the project? So I would say that the CNCF puts together a lot of resources to help projects do that, but the CNCF doesn't really get involved in the day-to-day operation of the individual projects, so that's generally up to the projects themselves. However, there are things like annual reports that projects report out on and how they're doing, and so the CNCF sees those, and then there's also the process of moving from sandbox to incubating to graduated, which is another sort of checkpoint. So I would say the CNCF has checkpoints for projects, and we provide guidance and help and information, but we do kind of leave it up to the individual projects to build their own communities, get their own adopters, and put together things like governance, documentation. Okay, and to the other part of the question, like does CNCF has some restrictions on the type of licenses that these projects should have? They have preferred licenses, and I know that they have legal processes for that, so I'm on more of the community governance side. I don't get involved in licensing. I don't know if anybody has an answer for that, but Josh has an answer for that, of course. Okay, so the answer to that was they ask you to use Apache 2 for code, Creative Commons for documentation, and if you need to use something else for whatever reason, you have to get an exception from the governing board. Any last questions? I have 20 seconds, otherwise I'll just turn it over to I think Celeste has the talk and this next talk in this room. Oh, your talk is at 5.30? Yeah, it's a bit of a break. Oh. Y'all can sit here and have a bit more about how to do that. But I do think my time is up, so then we have no more questions, so thank you everybody for coming.