Cloud Native Computing Foundation KubeCon + CloudNativeCon North America 2020 - Virtual, 4 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Collaborative Leadership: Governance Beyond Company Affiliation - Dawn Foster, VMware

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Collaborative Leadership: Governance Beyond Company Affiliation - Dawn Foster, VMware

The unbridled success of Kubernetes can be attributed in part to being in the CNCF. Putting Kubernetes under a neutral foundation provided a level playing field where each of us could contribute, collaborate and innovate as equals to create a widely adopted solution that we can all use. With advantages that include community building, innovation, and wider adoption, we should consider contributing more of our open source projects to neutral foundations, like the CNCF. This talk will cover: * Challenges of giving up control and why it might be worth it * Selecting a foundation and how to determine neutrality * Creating a fair and neutral governance structure and processes for your project * Tips for contributing and maintaining your project The audience will get practical advice about whether they should contribute their projects to neutral foundations along with how and when to do it.

https://sched.co/ekBP

A

Welcome to my talk about open source project governance, leadership and company affiliation.

A

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 are run out of individual companies.

A

After that I'll 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 set up your project for success, then I'll wrap it up with a few final thoughts and some links to a few useful resources.

A

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 a pretty wide variety of companies like puppet and intel at pivotal. I was responsible for pivotal's kubernetes contribution strategy and I was actively contributing to the kubernetes contributor experience special interest group now, I'm working in vmware's, open source program office and I'm responsible for our open source community strategy.

A

So lately I've been active in the cncf contributor strategy sig in particular the governance working group, I'm also a board member of open uk, which is focused on developing and sustaining leadership and open technology within the uk.

A

I'm a governing board member and maintainer for the linux foundation's chaos, project, which is focused on using metrics to evaluate the health of open source projects and I'm on the advisory board for petergia, which is a company that does open source health metrics.

A

I also have a phd from the university of greenwich in london, where I spent some time researching how people working at a bunch of different companies collaborate together within the linux kernel.

A

I wanted to start by talking about why it's important to think about who controls or owns an open source project, because it's something that many of us probably don't spend as much time thinking about as we should. Projects that are controlled by foundations and ones that are owned by an individual company can have very different dynamics and different risks associated with participating in those projects.

A

It isn't always clear whether a foundation is neutral or not. I generally start by looking 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 companies, especially competing companies.

A

That's a good indication that it's a neutral foundation with a good balance of people to represent different various aspects of the industry.

A

If the board members are primarily made up of people from a single company, or maybe just a couple of companies that have very close ties, it's not likely to be a true, neutral foundation.

A

Trademarks are another thing to look at and in a neutral foundation the foundation should own the trademarks associated with the name of the foundation and the projects or, if they don't own them, at least they manage them, and if the trademarks are owned by a company, especially a single company. That's it's a red flag. That's a project!

A

The foundation is probably not neutral.

A

It can also help to look at the projects under that foundation. Were they originated at a single company, or did they come from a variety of companies? Do those projects have leaders from a variety of companies? Do they have contributor license agreements or clas from a single company or is the cla from the foundation?

A

The more you see references to a single company across the projects, the less likely the foundation is to be neutral, and these are just a few of the many things you should look at when deciding if a foundation is neutral or not the apache software foundation, the cncf, the linux foundation, those are all neutral foundations, examples of them. There are many others. On the flip side, the open usage commons is not one that I would classify as a neutral foundation.

A

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 with neutral foundations. Our end users get access to more innovation from a diverse group of contributors, while also reducing vendor lock-in.

A

For example, users of kubernetes can consume enterprise versions from a wide variety of different vendors that run on any of the leading cloud providers and as software vendors, we can contribute to foundation driven projects with the confidence that no one company is in control of the project and that we can all contribute as equals within the community.

A

Open source projects that are controlled by a single company are higher risk because they operate at the whims of that company, whereas projects that are under neutral foundations have a lower risk both for end users and for software vendors.

A

When a project is owned by a company, there is little recourse for outside contributors when that company decides to go in a different direction that maybe doesn't align with the needs or the expectations of the other participants within that community, when a project is owned or controlled by a company. Consider the reputation of that company as a steward for open source projects, but keep in mind that they can change their strategy at some later date.

A

We've seen this with google, for example around the istio and k native projects, and I'm not saying that we shouldn't participate in open source projects owned by other companies. We certainly should in a lot of cases, 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 try to at least make sure that as a company, we understand the risks that we're taking.

A

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.

A

For example, we've contributed harbor and contour to the cncf, and we contributed turn to linux foundation's automated compliance, tooling project we've also contributed projects to the apache software foundation and a bunch of other foundations as well, and the challenge with contributing open source projects to foundations is that you do give up some of your control from the company to the foundation.

A

Typically, assets like the project's trademarks, repositories, websites and other things would be then transferred from the company to the foundation. Existing maintainers and leaders will usually keep their positions.

A

However, neutral foundations try to make sure that governance is set up in a way that makes it easy for people from other companies to participate and eventually then move into leadership positions. So as the contributing company, you should expect for more leadership transitions over time.

A

As you get more leaders in the project that work for other companies and as a percentage fewer than end up working for your company, while this does mean giving up some control over the project, there are a lot of benefits with advantages around community building innovation, wider adoption, it's something that we should at least consider for our open source projects.

A

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 that has good traction within the industry that just maybe needs some help. Moving up to the next level would be much more likely to be accepted into a foundation.

A

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 support over both the short term and the long term. Just like you would, if you weren't, contributing it to a foundation, and you were going to continue to maintain it internally.

A

We've been doing quite a bit of work within the cncf contributor strategy, sig in the governance working group to help document governance, best practices, and this section contains a lot of ideas, inspiration and materials that I've been working on, along with people like josh burkus, for example, within within this working group.

A

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 array of way of doing the real work on the project.

A

The reality is that 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.

A

Ideally, it will be clearly documented, but for some projects, especially the smaller ones, it might be a bit more. Ad hoc and informal governance helps outline the expectations around roles and responsibilities along with the decision making processes. 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 when something goes wrong.

A

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.

A

Your governance processes before you need them a project with only a few people will not need elaborate elections to select leaders, but you should probably define a few basic roles like maintainer, for example the process for contributing to your project and define how decisions about those contributions are made if the process for collaboration and decision making are not clearly documented as part of the project governance, this can increase the risk of participating in the project or in using the project, because it introduces a lot of uncertainty into the mix, knowing how collaboration occurs and how decisions are made is absolutely vital to being able to make contributions that are more likely to be accepted.

A

There are a few documents that every project, even the very small ones, should have it should go without saying, but open source projects need appropriate licensing documentation.

A

I occasionally find repos with missing license files, which is maybe less common, but more often I see licenses not applied correctly within projects. In addition to just putting a license file in your repository, some licenses require things like a notices file or license headers within each source file.

A

You should also have a code of conduct that people can easily find with details about how to report incidents along with them the consequences. If someone violates that 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.

A

But I would encourage you not to do that. You should just 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 added to your repository there's nothing special that you need to write for the code of conduct itself.

A

However, the bit that you do need to spend some time on is making sure that you actually have a plan for enforcing it before you need it. You'll need to nominate a couple of people who will be responsible for taking reports from community members when something's been. You know when the code of conduct has been violated and then handling those responsibly, but the contributor covenant page actually has loads of details and links to resources for learning, about how to implement and enforce a code of conduct, and so that can be a really good starting point.

A

Your contribution documents should provide enough details about the contribution process so that someone new to the project can make their very first contribution.

A

This includes details about how to sign your contributor license agreement if you have one a cla or how to use the developer certificate of origin, or it's often referred to as the dco or signed off by process.

A

If you have that, instead also, 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 their contribution for its merits.

A

You'll want to make sure that your contributors know what to expect and how to navigate the project when making contributions.

A

The communication process should also be clearly defined so that people know both where and how to contribute to the project. Maybe you prefer mailing list discussions or slack messages or issues for feature requests.

A

Maybe you have separate communication channels for users and a different one for developers, make sure that everyone understands how people within the project communicate with each other, to avoid a frustrating experience, not just for your new contributors, but also for your existing ones.

A

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 much more likely to be secure.

A

You should also be using automated tools like dependabot, for example, to help identify when new versions of dependencies are available, which also helps you keep on top of potential security issues, and while there are no guarantees and critical security issues can just sort of pop up at any time.

A

Taking a proactive approach to security reduces the likelihood of having serious security issues that will then be exploited later.

A

The project should have a security.md file or another document, with details about the process for reporting and 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.

A

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 that security issue becoming public to help them avoid being exploited. As soon as the issue becomes public and give them a little bit of time to prepare.

A

You should also have some kind of documentation about your leadership for small projects. You might just need a list of maintainers in your readme file, or maybe owners or maintainers files that indicate which people are responsible for the various areas within the project.

A

Defining the roles and responsibilities for contributors, reviewers and maintainers is probably enough as a first step, which can help with them recruiting people into these roles for bigger projects. You'll want to have a lot more details about the specific roles and responsibilities for each of the different leadership roles along with then, how other people can move into those 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.

A

You recruit new leaders as you grow the project and need more people to share the workload.

A

There are quite a few different options for selecting leaders as a 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 can eventually move up and become leaders.

A

This should be documented so that all participants can clearly understand the criteria and the process for moving both into and then again out of leadership positions. Most of the bigger projects like kubernetes, for example, have an election process, at least for the top levels of leadership. Like a steering committee, then at the lower levels of leadership, many projects have a process where the existing leaders help select the newer leaders.

A

For example, new maintainers are often nominated by existing maintainers and approved, after maybe a certain number of maintainers agree, or sometimes it requires a vote by maintainers or maybe from a particular committee, and there are a bunch of different options for selecting leaders. So I will not try to cover all of them here, but there is an entire document devoted to these various options which are available at the link on the slide for more details.

A

Your project governance should be designed to keep diversity 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.

A

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 in within your community.

A

Providing an environment where everyone, including people from marginalized populations, feel safe, is the first step toward building a diverse community around your project.

A

You should also look at whether you have a diverse set of people at every level within the project, but especially in leadership positions, and if not, you should come up with programs that help underrepresented folks get involved and then move up within your project, ideally having programs that give people opportunities for shadowing mentoring and sponsoring new potential leaders can help. You grow a diverse set of people into leaders within the project.

A

The kubernetes contributor experience special interest group is a great place to see an example of how to implement programs for things like shadowing and mentoring, 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.

A

Diversity and inclusion can be really difficult to measure and it usually involves mostly a manual assessment, but we've defined some metrics within the chaos projects, diversity and inclusion. Working group that you should have a look at for ideas about measuring various aspects, so that you can then improve your projects, diversity and inclusion.

A

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.

A

The governance processes that you need, when you have only a couple of maintainers, is likely to be insufficient when the project grows dramatically and as your projects evolve, your governance should evolve right along with them, and you can see some of this within the cncf requirements. So if you look within the cncf, their projects can apply to be in sandbox.

A

They can move up to incubating and then they can eventually move to graduated and the requirements are a little bit different for each one and they do tend to build on each other, so the cncf documentation for the guidelines for what it takes at each of those three levels and what the requirements are that you need to move into each one of those levels can help.

A

You get a real sense for how the governance does evolve within projects and what you need, when you're small versus what you need when you're a big graduated project like like kubernetes, for example,.

A

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 this slide is the common theme that drives why I think governance as a whole is so important.

A

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.

A

The more you can do to help everyone participate in meaningful ways. The more welcome they will feel within your open source, community I'll wrap up the talk with a few resources that people might find useful. The to do. Group has a bunch of guides that have great information about creating and managing healthy projects, and many of them talk about various aspects of governance.

A

The cncf contributor strategy, sig, has a governance working group with more details about what you need for governance and some options for leadership. Selection, the open source way guidebook, has an entire chapter on governance that has loads of details and it's an absolutely fantastic resource and it's a great starting point, if you're just starting to figure out governance for your project, and these are all really great starting points for understanding how to govern your open source project and what you might need for your project.

A

With that, I will say thank you for coming to my talk and I have left some time for questions. So hopefully we can answer a few of your questions. Now the talk is finished so again. Thank you. So much.