 Welcome to my talk about open source project governance, leadership, and company affiliation. Today, I'm going to talk about a few topics related to governance. Starting with a look at the differences between projects that are under foundations compared to projects that run out of individual companies. After that, I will talk about how governance is mostly about the roles and processes that guide how people collaborate and make decisions, including some thoughts on how to document all of this in ways that help set your project up for success. I will wrap it up with a few final thoughts and links to some useful resources. But first, I'll tell you a bit about me. I've been in the technology industry for over 20 years, working mostly on open source projects from within companies like puppet and Intel. At Pivotal, I was responsible for driving Pivotal's Kubernetes contribution strategy, and I was actively contributing to the Kubernetes contributor experience. Now I'm working in BMWare's open source program office, and I'm responsible for our open source community strategy. So lately, I've been active in the CNC app, contributor strategy SIG, in particular the governance working group, which I'll talk more about later. I'm also a board member of Open UK, which is focused on developing and sustaining leadership in open technology within the UK. I'm a governing board member and maintainer for the Linux foundations chaos project, which is focused on using metrics to evaluate the health of open source projects. And I'm on the advisory board for Patergia. I also have a PhD from the University of Greenwich here in London, where I was researching how people working at a bunch of different companies collaborate within the Linux kernel. I wanted to start by talking about why it's important to think about who owns or controls an open source project, because it's something that many of us maybe don't spend as much time thinking about as we should. Projects that are controlled by foundations and ones that are owned by individual companies can have very different dynamics and different risks associated with participating in those projects. With the recent announcement of the Open usage Commons Foundation, I've been thinking a lot about what it means for a foundation to be neutral, and why foundations can be important for collaborative leadership within open source projects. The success of Kubernetes can be attributed in part to being contributed to the cloud native computing foundation. Putting Kubernetes into a neutral foundation with representation from a bunch of different companies provided a level playing field where each of us could collaborate and innovate as equals to create something that benefits the entire ecosystem. The trick isn't figuring out whether a foundation is neutral or not. The way to tell is by looking at the trademarks for the foundation. In a neutral foundation foundation should own the trademarks associated with the name of the foundation and at least have some control over the trademarks or the projects as well. If the trademarks are owned by a company, especially a single company, that's a red flag that it's not really a neutral foundation. Let's also look at the leadership for the foundation. If the board of directors or other leadership bodies are made up of people who work at a wide range of different companies, especially competing companies, that's a good indication that it's a neutral foundation with a good balance of people who represent various aspects of the industry. If the board members are made up primarily of people either from a single company or maybe a couple of companies with very close ties, it's not likely to be a neutral foundation. And these are just a couple of the many things that you should look at when deciding if a foundation is neutral or not. In neutral foundations, our end users get access to more innovation from a diverse group of contributors while also reducing vendor lock in. For example, users of Kubernetes can consume enterprise versions from a wide variety of vendors that can run on any of the leading cloud providers. For example, with open source funders, we can contribute to foundation during projects with the confidence that no one company is in control of the project and that we can contribute as equals within the community. Open source projects that are controlled by a single company are a higher risk because they operate at the wins of that company. Under neutral foundations have a lower risk both for end users and for software vendors. When a project is done by a company, there's little recourse for outside contributors when a company decides to go in a direction that doesn't maybe align the needs or the expectations of the other participants in that community. When a project is owned or controlled by a company, consider the reputation of that company as a steward of open source projects. But always keep in mind that they can change the strategy at some later date. We've seen this with Google around the Istio and Knative projects. I'm not saying that we shouldn't participate in open source projects owned by other companies, but we should think about the risks that we're taking. In some cases, it makes a lot of sense to accept this higher risk. But we should always try to make sure that as a company, we understand the risks that we're taking. 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 gain a bit of traction with people outside of the company. For example, we've contributed Harbor and Contour to the CNCF, and we contributed Turn to the Linux Foundation's Automated Compliance Tooling Project. We've also contributed projects to the Apache Software Foundation and other foundations. While this does mean giving up some control over the project, there are a lot of benefits with advantages around community building, innovation and wider adoption. It's something that we should always consider for our open source projects. It's also important to think about when your project might be ready to contribute to a neutral foundation. If your project is very immature, foundations are unlikely to be interested in your project. Whereas a project with many users and really good traction that just maybe needs some help moving up to the next level would be much more likely to be accepted. However, companies should understand that contributing a project to a foundation is an ongoing commitment. It's not an exit strategy, and you need to be prepared to provide staff and other support over the long term, just like you would if you weren't contributing it to a foundation and we're continuing to maintain it internally. We've been doing quite a bit of work within the CNC Africa Contributor Strategy SIG and the governance working group to help document governance best practices. And this section contains some ideas, inspiration and materials that I've been working on along with people like like Josh Bergus, for example, within the working group. A lot of people like to hate on governance. It's just extra paperwork, busy work, it's politicking that gets in the way of doing the real work on the project. The reality is that governance can be found at all open source projects in one form or another to specify the processes for how people work together within that project. Ideally, it'll be clearly documented, but for some projects, especially the smaller ones, it might be a bit more ad hoc and a bit more informal. Governance helps outline expectations around roles and responsibilities along with the decision making process. So it's important to have at least the basics in place early. Since it's one of those things that you may think you don't need until you realize that you actually do. 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 to sort out. 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 leaders. But you probably should define a few basic roles like maintainer, for example, to find the process for contributing to your project, and put together some documentation on how decisions around those contributions are made. If the processes for collaboration and decision making are not clearly documented as part of the project governance, this can increase the risk of participating in or using the project by other companies because it just reduces a lot of uncertainty into the mix when people don't know what to expect. Knowing how collaboration occurs and how decisions are made is vital to being able to make contributions that are more likely to be accepted. There are a few documents that every project, even the small ones should have. It should go without saying that open source projects need the appropriate licensing documentation. I occasionally find repos with missing license files, and that's a bit more rare, but more often I see licenses not applied correctly within projects. In addition to putting on license file in your repository, some licenses require things like a notices file or license headers within each 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 implementing codes of conduct can find it intimidating because they think it's something that they need to write from scratch. But don't do that. I would encourage you to use something like the contributor covenant, which is pretty much the gold standard for codes of conduct right now. And it can be simply copied and applied to the repository. However, the bit that you do need to spend some time on is making sure that you have a plan for enforcing it. You'll need to nominate a couple of people who will be responsible for taking reports of violations and then handling them responsibly. The contributor covenant page has loads of details and links to resources for learning about implementing and enforcing a code of conduct. So it's a great resource. Your contribution docs 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 how to sign your contributor license agreement or CLA if you have one, or how to use the developer certificate of origin or DCO or signed off by process if you have that instead. And if you have strong preferences about coding style, testing documentation or other requirements. This is a good opportunity to make sure that new contributors know these upfront, which helps reduce the burden of trying to educate each individual contributor about your requirements while you're also trying to review and provide feedback on their contributions. You'll want to make sure that your contributors know what to expect and how to navigate the project while making contributions. The communication process should be clearly defined so that people know where and how to communicate in the project. Maybe you prefer mailing list discussions or Slack messages or issues for feature requests. Maybe you have separate communication channels for users and for developers. Make sure that everyone understands how people within the project communicate with each other to avoid frustrating experience for both your new contributors and your existing ones. Projects should also document the processes for reporting and then responding to security issues. Projects that take a proactive approach to addressing security issues and releasing fixes are much more likely to be secure. You should also be using some automated tools like dependabot, for example, to help identify when new versions of dependencies are available, which also helps keep on top of potential security issues. While there are no guarantees, critical security issues can sort of pop up at any time, taking a proactive approach to security reduces the likelihood of having serious security issues that will be exploited later. The project should have a security.md file or another document with details about the process, both 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. And you need these even for small projects. Large projects that are used by vendors within their commercial products 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 security issue becoming public to help them avoid being exploited as soon as the issue becomes public. So you should have some kind of documentation about your leadership. For small projects, you might just need those of maintainers in your readme file, or maybe owners or maintainers files that indicate which people are responsible for various areas within the project. So combining the roles and responsibilities for contributors, reviewers and maintainers might be enough as a first step, which can help with them with recruiting people into those roles. For bigger projects, you'll want to have more details about the specific roles and responsibilities for all of the different leadership roles, along with how others can move into leadership positions. You might have committees, working groups, special interest groups or other groups that will need leaders. And again, having this documented can really help you recruit new leaders as you grow the project and need more people to share the workload. There are quite a few different options for selecting leaders as a part of your of defining your governance. And the ideal is to have a process that provides a fair and level playing field that defines how contributors can become leaders. This should be documented so that all participants can clearly understand the criteria and the process for moving both into and then out of 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 a steering committee. At lower levels of leadership, many projects have a process where existing leaders select new ones. For example, new maintainers are often nominated by existing maintainers and then approved after either a certain number of maintainers agree or sometimes it requires a vote by other members or some members of some committee. And there are a bunch of different options for selecting leaders, and I won't try to cover them all here, but there is an entire document, which is linked to on the slide for more details and you can find that again in the CNCF contributor strategies in your governance working group documents. Your project governance should be designed to keep diversity and inclusion top of mind. Building a diverse community where all people feel welcomed 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. I talked about codes of conduct earlier, and having a code of conduct that you actively enforce helps make sure that everyone feels safe and welcome within your community. Providing an environment where everyone, including people from marginalized populations feel 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 in the project, but especially in the leadership positions. And if not, come up with some programs that help underrepresented folks get involved and then move up within your project. And finally having programs that give people opportunities for shadowing mentoring and sponsoring new potential leaders can help you grow a diverse set of people into new leaders within the project. The Kubernetes contributor experience SIG is a great place to see an example of how to implement programs for things like shadowing and mentoring. You want to make a concerted effort to bring in new people from a variety of backgrounds and have programs in place then to help them grow into leadership positions are more likely to benefit from increased innovation and more likely to have a healthy community. Diversity and inclusion can be difficult to measure, and it usually involves mostly a manual assessment. There are some metrics within the chaos projects diversity and inclusion working group that you should have a look at for ideas for measuring various aspects so that you can improve your projects diversity and inclusion. Governance is one of those things that is just never really finished. We work in a space with constant change technologies change strategies change the way we work changes everything changes. Your governance needs to evolve right along with these 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 have only a couple of maintainers is likely to be insufficient if the project grows dramatically. As your projects evolve your governance should evolve right along with them. There are so many aspects of good governance for open source projects. And I only had time to talk in detail about a few of 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 for open source projects. Governance provides a framework for setting expectations for roles, responsibilities and how people within your project should behave. But 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're going to feel within your open source community. I will wrap up this talk with a few resources that people might find useful. The to-do group has a bunch of guides that have great info about creating and managing healthy projects. And many of them talk about various aspects of governance. The CNCF contributor strategy, SEIC, which I've talked about before, has a governance working group with more details about what you need for governance and some options for leadership selection. The open source guidebook has an entire chapter on governance with loads of details and these are all great starting places for understanding how to govern your open source project. With that, thank you so much for coming to my talk.