 All right, thanks everybody for coming to my talk. Today I'm going to talk about good governance for open source projects. So for those of you who aren't sure why you should care, I'll start by talking about why it's important. Before moving on to setting expectations by clearly stating your mission, values, and scope, I'll talk about roles, responsibilities, processes, and procedures, along with how you can use a contributor ladder as a path to leadership. I'll also cover how corporate ownership can impact your project, and whether a foundation might or might not be a better choice for your project. And then I'll conclude with some links to resources and final thoughts. And the slides are already uploaded on schedule for those who want them. I would start by telling you a bit about me, but Anna had a fantastic introduction. So the only thing I'll add is that I spend a fair amount of time working within the CNCF contributor strategy technical advisory group as part of the governance working group, where we put together guidance and templates for CNCF projects to use. So you'll find quite a bit of the work that we've done within that group, so it's a team effort obviously, but you'll find that's for gold throughout this presentation. So a lot of people like to hate on governance. It's just extra paperwork. It's busy work. It's politicking that gets in the way of doing the real work on the project. And this could be especially true when governance is implemented and framed as a bunch of things you're not allowed to do. But this isn't true of good governance, which is really about alignment and getting all of the various people within your community collaborating together. Governance is also one of those things that you may think you don't need until you realize you do. But by that time, it's too late because something's already gone wrong, expectations aren't aligned, and you're probably seeing some unhealthy dynamics within the community. Governance helps outline the expectations around roles and responsibilities along with decision-making processes. So it's important to have at least these basics in place early. Now 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. Now ideally, it will be clearly documented and explicit, but for some projects, especially maybe the smaller ones, it might be a bit more ad hoc and informal. Ultimately, the focus of open source project governance is on people. The roles we play are responsibilities, how we make decisions, what we should expect from each other as a part of participating in the community. It's usually easier to set expectations up front rather than realizing later that various people have very different expectations, which can take a lot of time and energy to sort out after the fact. Now, this does not 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 couple of people will not need elaborate elections to select leaders, right? But you should probably define a few basic roles, define the process for contributing to your project, and how decisions about those contributions are going to be 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 more likely to be accepted and embraced by the project. A healthy project with clear governance makes contributors happy, and it helps set your project up for future growth and long-term success. Now, I suspect that some of you are still thinking that you probably don't need to spend time documenting governance, but think about this from the perspective of the 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, 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 are made fairly based on solid information with the involvement of the people with the right expertise to make those decisions. I also want to see a clear path into leadership, either for me or maybe for my colleagues at the company 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 unbear or technically questionable and it's not clear who makes the decision or where to escalate it? This leaves community members frustrated and can cause people to lose respect for the project or the people running it, which can lead to projects becoming unviable if this dynamic continues and people aren't interested in participating. I was involved in a project recently that refused to put any sort of real governance in place. The community dynamic was fairly toxic with epic levels of bike shedding on topics even tangentially related to governance and it sucked. I hated the time I had to spend in that community and these governance issues are usually a sign of other issues in the project and that's the sultry for that project as well. But the end result is that we're recommending that our project teams, product teams, avoid this project if they possibly can. Now 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 it increases the barriers to contribution while jeopardizing the health and viability of that project. One way you can set expectations is being clear about the mission, values, scope for the project to avoid misunderstandings later and in general you can sort of think about these things as a project charter even though in reality most open source projects don't actually 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. Now the link on the slide talks more about each of these pieces with some examples from CNCF projects to get you started but I'll give you a quick intro on each one. So in most open source projects there probably isn't anything that's labeled as a mission statement but there's usually something that talks about the purpose, the advantages, 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 and why your project is important or useful and it usually includes a mention of at least a couple of key features. Now this information helps people who are coming to your project for the first time to get a quick summary and this is where they can learn more about your project and whether it might be a good fit for their 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 one of those things that I think is too often overlooked in open source projects and it is really important. This is where you can be really clear about what your project does and just as importantly what it does not do so that you can set expectations and help avoid misunderstandings. This can help avoid situations where a new user or contributor starts using your project under the assumption that they can contribute some feature that they need and then they realize that that feature is going to be out of scope possibly for very good architectural or strategic reasons but you could have saved them some time by documenting your scope in the first place. For small or immature projects you could just have a couple of sentences in your readme that talk about scope. For large or complex projects you might want to have a whole separate scope document linked from your readme with details about what functionality or features are in scope or out of scope along with details about why. Now 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. These can live in your readme file the governance documentation or a standalone document linked from your readme and governance and I've included a few examples on the slide that are commonly used in open source projects but this you know these are not a one-fits size fits all approach. They 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 or principles documented for your project you're setting yourself up for misunderstandings and for disappointed community members. Now I mentioned earlier that 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 procedures that drive the work. There are a few documents that every project even the small ones should have open source projects need appropriate licensing documentation including possibly things like a notices file or licensed headers within the source file. You should also have a code of conduct that people can easily find with details about how to report incidents along with the consequences of violating the code of conduct. Sometimes people who are new to doing this can find it intimidating because they think it's something they need to write from scratch but I would encourage you just to use something like the contributor component for example which can be simply copied and added to your repository. The bit that you do need to spend time on is making sure that you have a plan for enforcing it. You'll need to nominate a couple of people who are going to be responsible for taking reports of violations and handling those reports responsibly. The contributor covenant page has loads of details and links to resources for how to do that. Your contribution documents should provide enough details about the contribution process that someone who is brand new to the project can make their very first contribution. This includes details about contributor license agreements maybe a developer's certificate of origin process and you'll want to make sure that your contributors know what to expect and how to navigate the project when making contributions. The communication processes should also be clearly defined so that people know where and how to communicate within your project. Maybe you prefer mailing list discussions or Slack messages or issues for feature requests. Maybe you have separate communication channels for users and developers. Make sure that everyone understands how people within the project communicate with each other to avoid a frustrating experience both for new and your existing contributors. Projects should also document the processes for reporting and responding to security issues. Projects that take a proactive approach to addressing security issues and releasing fixes are a lot more likely to be secure. You should also be using some automated tools like dependabot to help identify when new versions of dependencies are available. And while there are no guarantees and critical security issues can pop up at any time but taking a proactive approach reduces the likelihood of having security issues that will be exploited later. The project should have some sort of security.md file or other document with details about the process for reporting and responding to security concerns. At a minimum you want to have a way for people to privately report security issues and have a few people who are designated to handle those issues. Project leadership is one of the key elements of good governance. So you should have some kind of documentation about your leadership. For small projects maybe you just need a list of maintainers that indicates which people are responsible for which areas within the project. 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. It can help to think about this as a ladder a contribution ladder where contributors can climb up to become reviewers and those reviewers can become maintainers. And what's important is to document and make sure that people understand how they can climb this ladder and gain more responsibility within the project. Now for bigger projects you want to have more details about the specific responsibilities for each leadership role along with how people can move into those positions. You might have committees working groups special interest groups that need leaders and having this document helps you document it helps you recruit new leaders and grow the project. And 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 a fair and level playing field that defines how contributors become leaders. This should be documented so that participants can clearly understand the criteria and the process for moving into leadership positions. Most of the bigger projects like Kubernetes for example have an election process at least for the very top levels of leadership like the steering committee. At lower levels of leadership many projects have a process where existing leaders select the new leaders. For example new maintainers are often nominated by existing maintainers and then approved after a certain number of maintainers agree or sometimes it requires a vote by maintainers. And there are loads of different options for doing this so there's a link at the bottom of the slide which has a lot more detail about leadership selection for governance. Now 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 a good time to do this. 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 the leadership positions and if not come up with programs that help the underrepresented folks get involved and then move up within your project. Ideally having programs that give opportunities for shadowing mentoring and allowing other people to sponsor new potential leaders can help you grow a diverse set of people into leaders for with your project. The contributor experiencing for Kubernetes is a great place to start. They've got some great programs in place so it's a pretty good example but projects that make a concerted effort to bring in new people 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 and DEI is something that's kind of hard to measure but I've included a link at the bottom to the chaos metrics because we've defined defined a whole bunch of metrics to help people measure whether communities are diverse and inclusive. An important aspect of governance is ownership or control over the open source project and the community. Projects that are owned by foundations and ones that are controlled by an individual company can have very different dynamics. Open source projects that are controlled by a single company can be a concern for outside contributors because they operated the whims of that company and there's 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 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. While it's not ideal I do have a lot more respect for companies and projects who are honest about how others can participate than the ones that claim to be open while still actually making all of the decisions behind the closed doors of their company. Now on the other hand we have foundations for open source projects. These foundations provide a lot of things like advocacy and marketing ownership of assets and other activities to help the project be successful which all impacts governance. Now not all foundations are created equal and some are better than others so Apache Software Foundation, Eclipse, the Cloud Native Computing Foundation, the Linux Foundation are examples of well-run neutral foundations and with neutral foundations your projects and users get access to more innovation from a diverse group of contributors while also reducing vendor lock-in. If you think about Kubernetes users of Kubernetes can consume enterprise versions from a wide variety of vendors that can run on any of the leading cloud providers and as a software vendor like VMware we can contribute to foundation driven projects with the confidence that no one company is in control of the project and that we can contribute as equals within the community. One of the reasons that Kubernetes has been so successful is because it was contributed to the Cloud Native Computing Foundation which provided a level playing field where people from a whole bunch of different companies could work together as equals to create something that benefited the entire ecosystem. Now at VMware we believe that contributing open source projects to neutral foundations is important and it's something that we do regularly for projects that we've started once they start to gain a bit of traction with people outside of the company. For example, we've contributed Harbor and Contour to the CNCF. We've also contributed projects to the Apache Software Foundation. We've contributed projects to other foundations like for example we contributed Turn to the Linux Foundation's Automated Compliance Tooling Project. Now the challenge with contributing open source projects to foundations is that you also give up some control to the foundation. Typically the projects trademark, repositories, websites and other assets are usually transferred entirely to the foundation. Now existing maintainers and leaders will usually keep their positions. However, neutral foundations so the CNCF in particular often make sure that governance is set up in a way that makes it easy for people from other companies to participate and eventually move into leadership positions. So as they contribute in company you should expect some leadership positions to eventually transition to people from other companies over the longer term. While this does mean giving up some control over the project there are a lot of benefits. There are advantages around community building, innovation, wider adoption and it's something that you should at least consider for some of your open source projects. Putting your project under a neutral foundation gives other companies more confidence that they can contribute as equals. It's also important to think about when your project might be ready to contribute to a foundation. If your project is very immature foundations are probably not likely to be interested in your project whereas a project with some users and that's starting to get some good traction that just needs some help maybe moving up to the next level would be much more likely to be accepted by a foundation. Now however we all need to remember that contributing a project to a foundation 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 and the long term just like we would for any product or any open source project that we weren't contributing to a foundation. Governance is one of those things that is never really finished. We work in a space with constant change technologies change strategies change the way we work changes everything changes and our governance needs to evolve right along with those changes in particular as open source projects become more mature and grow what they need from governance will change dramatically. The governance processes that you need when you only have a couple of maintainers is going to be insufficient if the project grows dramatically and as your project projects evolve your governance should evolve along with them and this might mean thinking about contributing your projects to foundations as they evolve. I have links to resources which are you can find in the slides on sketch. So one final well a few final thoughts there are so many aspects of good governance for open source projects. I only had time to talk in detail about the ones that I think are the most important 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 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 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 people will feel within your open source community. With that thank you for coming to my talk and I will open it up for questions. I know I'm a little over time and I'm standing between y'all and lunch but are there any questions? No people are just really hungry I'm pretty hungry too not gonna lie okay no questions but I will be around the whole rest of the day so feel free to track me down later. Yeah thanks thank you so much