Collaborative Leadership: Governance Beyond Company Affiliation: MBBG-3467 - events@cncf.io - Friday, November 20, 2020 3:12 PM - 30 minutes Participant: wordly [W] English (US) Transcription for wordly [W] 00:00:00 [W] Welcome to my talk about open source project governance leadership and Company affiliation. 00:00:06 [W] these 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 00:00:22 [W] Wrap it up with a few final thoughts and some links to a few useful resources. 00:00:22 [W] But first, I'll tell you a bit about me. 00:00:26 [W] 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. 00:00:38 [W] I was responsible for perverted little scooper Nettie's contribution strategy and I was actively contributing to the kubernative east. 00:00:46 [W] Experience special interest group now I'm working in VMware is open source program office and I'm responsible for our open source Community strategy So lately I've been active in the cncf contributor strategy Sig in particular the governance working 00:01:01 [W] Also a board member of open UK which is focused on developing and sustaining leadership and open technology within the UK. 00:01:08 [W] I'm a governing board member and maintainer for the Linux Foundation is chaos project which is focused on using metrics to evaluate the health of Open Source projects and I'm on The Advisory board for paternity out, which is a company that does open source Health metrics 00:01:24 [W] Health of empowerus projects and am on The Advisory board for the Giorgio is a company that does open source Health metrics. 00:01:23 [W] I also have a PhD from the University of Greenwich and London where I spent some time researching how people working at a bunch of different companies collaborate together within the Linux kernel 00:01:37 [W] 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 00:01:53 [W] 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. 00:02:08 [W] in those projects 00:02:08 [W] it is not always clear whether a foundation is neutral or not. 00:02:12 [W] I generally start by looking at the leadership for the foundation. 00:02:16 [W] If the board of directors are other leadership bodies are made up of people who work in a wide range of companies, especially competing companies. 00:02:26 [W] 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. 00:02:35 [W] 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. 00:02:45 [W] It's not likely to be a true neutral Foundation trademarks are another thing to look at in an 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 00:03:00 [W] About your owned by a company, especially a single company. 00:03:02 [W] That's a red flag. 00:03:04 [W] That's a project. The foundation is probably not neutral. 00:03:09 [W] It can also help to look at the projects under that Foundation where they originated at a single company or did they come from a variety of companies? 00:03:18 [W] Do those projects have leaders from a variety of companies. 00:03:22 [W] do they have contributor license agreements or cla's from a single company or is the CLA from the foundation the more you see references to a single company across the Project's the less likely the foundation is to be neutral. 00:03:37 [W] And these are just a few of the many things should look at when deciding if a foundation is neutral or not. 00:03:45 [W] The Apache software Foundation the cncf the Linux Foundation. 00:03:49 [W] Those are all neutral foundations examples of them. 00:03:53 [W] There are many others on the flip side. The open usage Commons is not one that I would classify as a neutral Foundation. 00:04:01 [W] the success of kubernative A's can be attributed in part to being contributed to the cloud native Computing Foundation putting kubernative use into a neutral foundation with representation from a bunch of different companies provided a Level Playing Field 00:04:16 [W] could collaborate and innovate is equals to create something that benefits the entire ecosystem with neutral foundations are and users get access to more Innovation from a diverse group of contributors 00:04:22 [W] That's two more Innovation from a diverse group of contributors while also reducing vendor lock-in for example users of kubernative can consume Enterprise versions from a wide variety of different vendors. 00:04:25 [W] it's 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 00:04:41 [W] We can all contribute as equals within the community. 00:04:46 [W] 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. 00:05:01 [W] 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 00:05:15 [W] a community 00:05:13 [W] 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. 00:05:26 [W] We've seen this with Google for example around the sto McKay native projects, and I'm not saying that we shouldn't participate in open source projects owned by other companies. 00:05:37 [W] We certainly should in a lot of cases, but we should think about the risks. 00:05:43 [W] We're taking in some cases. 00:05:45 [W] 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. 00:05:59 [W] At the end where we believe the contributing open source projects to neutral foundations is important and it's something that we do regularly for projects that we've started. 00:06:09 [W] Let's say gain a bit of traction with people outside of the company. 00:06:12 [W] For example, we've contributed Harbor and Contour to the cncf and we contributed turn to Linux foundations automated compliance tooling project. 00:06:24 [W] 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 00:06:39 [W] Nation 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. 00:06:52 [W] Nations 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. 00:07:00 [W] So as the contributing company, you should expect for more leadership transitions over time 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. 00:07:16 [W] Well, this does mean giving up some control over the project. 00:07:19 [W] There are a lot of benefits with advantages around Community Building Innovation wider adoption. 00:07:27 [W] It's something that we should at least consider for our open source projects. 00:07:32 [W] 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. 00:07:45 [W] Project where the project with many users that has good traction within the industry that just maybe need some help moving up to the next level would be much more likely to be accepted into a foundation. 00:07:58 [W] However companies should understand that contributing a project to a foundation is an ongoing commitment. 00:08:07 [W] It's not an exit strategy and you need to be prepared to provide staff and support over both. 00:08:15 [W] 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 are going to continue to maintain it internally. 00:08:32 [W] We've been doing quite a bit of work within the cncf contributor strategy saying in the governance working group to help document governance best practices and the section contains a lot of ideas inspiration and materials, but I've been working on along with 00:08:47 [W] grants for example within then this working group 00:08:52 [W] Now a lot of people like to hate on governance, it's just paperwork. 00:08:57 [W] It's busy work. 00:08:58 [W] It's politicking that gets in the way of don't way of doing the real work on the project. 00:09:03 [W] 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. 00:09:17 [W] Ideally. 00:09:19 [W] it will be clearly documented but for some prodyna 00:09:21 [W] Jack's especially the smaller ones. It might be a bit more ad hoc. And in formal governance helps outline the expectations around roles and responsibilities along with the decision-making processes. So it's 00:09:36 [W] Is 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. 00:09:43 [W] 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. 00:09:55 [W] 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 00:10:10 [W] to select leaders, but you should probably Define a few basic roles like maintainer, for example the process for contributing to your project and divide how decisions about those contributions are made 00:10:15 [W] Collaboration and decision making are not clearly documented as part of the project governance. 00:10:09 [W] 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 have decisions are made is absolutely vital to being 00:10:24 [W] Contributions that are more likely to be accepted. 00:10:27 [W] 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. 00:10:40 [W] I occasionally find Repose 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 00:10:55 [W] 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 00:11:17 [W] This is file or license headers within each source file. 00:11:21 [W] 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 00:11:36 [W] Act can find it intimidating because they think it's something that they need to write from scratch, 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 00:11:51 [W] Simply copied and added to your repository. 00:11:51 [W] There's nothing special that you need to write for the code of conduct itself. 00:11:55 [W] 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. 00:12:05 [W] You'll need to nominate a couple of people who will be responsible for taking reports from community members. 00:12:12 [W] When something's been, you know when the code of conduct has been violated and then handling those responsibly. 00:12:19 [W] 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. 00:12:27 [W] And so that can be a really good starting point. 00:12:29 [W] 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 00:12:45 [W] I'm your contributor license agreement. If you have one a CLA, or how do you use the developer certificate of origin or Source often referred to as the dco or signed off by process if you have that instead also if you have 00:12:55 [W] As about coding style testing documentation or other requirements. 00:12:51 [W] This is a good opportunity to make sure that new contributors know these up front which helps reduce the burden of trying to educate each individual contributor about your requirements while you're also trying to review their contribution. 00:13:06 [W] merits 00:13:08 [W] you'll want to make sure that your contributors know what to expect and how to navigate the project when making contributions. The communication process should also be clearly defined so that people know both where and 00:13:23 [W] Contribute to the project. Maybe you prefer mailing list of sessions or slack messages or issues for feature requests. 00:13:28 [W] Maybe you have separate communication channels for users and a different one for developers. 00:13:34 [W] 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 00:13:48 [W] project 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 much more likely to be secure. 00:14:03 [W] it also be using automated tools like depend about for example to help identify when new versions of dependencies are available, which also helps you keep on top of potential security issues it will there are no guarantees 00:14:15 [W] Already issues can just cut it up pop up at any time taking a proactive approach to security reduces the likelihood of having serious security issues that will then be exploited later. 00:14:22 [W] 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. 00:14:37 [W] And have a few people who are designated to handle those issues. 00:14:37 [W] 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 00:14:52 [W] Already 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. 00:15:00 [W] You should also have some kind of documentation about your leadership for small projects. 00:15:06 [W] You might just need a list of maintainers and you read me file or maybe owners or maintainers files that indicate which people are responsible for the various areas within the project defining the roles and responsibilities for contributors. 00:15:22 [W] Viewers and maintainers is probably enough as a first step which can help with them recruiting people into these roles for bigger projects. 00:15:29 [W] 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. 00:15:44 [W] 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. 00:15:53 [W] There are quite a few different options for selecting leaders as a part of defining your governance. 00:15:58 [W] 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. 00:16:09 [W] 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. 00:16:22 [W] Most of the bigger projects like kubernative. 00:16:24 [W] He's for example have an election process at least for the top levels of leadership like a steering committee and at the lower levels of leadership many projects have a process for the existing leaders helped select the newer leaders for example 00:16:40 [W] 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. 00:16:51 [W] It requires a vote by maintainers or maybe from a particular committee and there are a bunch of different options for selecting leaders. 00:16:48 [W] 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. 00:17:00 [W] 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 00:17:16 [W] Open 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. 00:17:26 [W] 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 welcomed and within your community. 00:17:40 [W] Providing an environment where everyone including people from marginalized populations feel safe is the first step toward building a diverse Community around your project. 00:17:53 [W] You should also look at whether you have a diverse set of people at every level within the project but especially in leadership positions. 00:18:02 [W] 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 00:18:17 [W] Ring new potential leaders can help you grow a diverse set of people into leaders within the project the kubernative contributor experience special interest group is a great place to see an 00:18:31 [W] how to implement programs for things like shadowing and mentoring 00:18:26 [W] 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. 00:18:42 [W] Diversity and inclusion can be really difficult to measure. 00:18:47 [W] 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 00:19:02 [W] Governance is one of those things that is never really finished. 00:19:06 [W] We work in a space with constant change Technologies change strategies change the way we work Changes Everything Changes in our governance needs to evolve 00:19:21 [W] 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 have only a couple of maintainers 00:19:29 [W] Sufficient when the project grows dramatically and is your projects evolve your governance should evolve right along with them and you can see some of this within the cncf requirements. 00:19:38 [W] So if you look within the cncf their projects can apply to be in sandbox, 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. 00:19:53 [W] 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 you get a real sense for how 00:20:06 [W] Into each one of those levels can help 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 kubernative for example. 00:20:19 [W] 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 00:20:34 [W] Itís 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 00:20:49 [W] 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 00:21:03 [W] Welcome, they will feel within your open source community. 00:21:07 [W] 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 00:21:22 [W] Friends 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 guide book has an entire chapter 00:21:36 [W] Our chapter on governance that has loads of details is 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 00:21:46 [W] How to govern your open source project and what you might need for your project? 00:21:53 [W] With that, I will say thank you for coming to my talk and I have left some time for questions. 00:21:58 [W] So hopefully we can answer a few of your questions now the talk is finished. So again, thank you so much. 00:22:09 [W] All right. 00:22:10 [W] Thanks everybody for attending my session. 00:22:13 [W] I do have the engineer tells me I have about eight minutes left for questions. 00:22:17 [W] So if you have questions, you can drop them here in the platform and the QA or better yet. 00:22:24 [W] You can drop them in slackware will have access to them later after the session and I will start with rani's question. So Rani says in some cases, I noticed that even though projects check all the boxes. You mentioned neutral governance. 00:22:39 [W] Our foundation documents Etc. 00:22:42 [W] It's difficult to bring that second company on board potential collaborators see contributions from only the first company which raises a red flag and they just move on so any tips for how to entice that second company. 00:22:56 [W] This is something that is super hard. 00:22:58 [W] So this is a really really great question and I do actually have some suggestions for you for bringing that second company on board and I think that the most important 00:23:08 [W] easier after that but bringing that first company, that's not the company that The Originators work for can be a little bit can be a little bit challenging one of the places I would start I would start with some of your end users other 00:23:21 [W] Sing the the project see if any of them want to contribute and actively reach out, you know, you've probably have an end user is doing something really interesting with the technology and maybe when you start getting pull requests to touch those bits 00:23:28 [W] Are getting questions maybe on the mailing list or in slack proactively reaching out to somebody who can help answer them and then people will see that other people are engaged other people are answering questions. And then it's not always everything's coming from one company 00:23:41 [W] Heard you to do is utilize your business relationships. 00:23:43 [W] So this is one of the advantages of working for our company is that you probably have probably have some Partners you have some people that you work closely with and being able to pull maybe some of those companies in and again 00:23:58 [W] To contribute in areas where you know that maybe they have some interesting expertise or they have some some knowledge that you think they should share but it really it really does take that proactive work to bring 00:24:08 [W] In and then once you've brought a second company in then other other people see that it's not it's not just you and people from your company that there are other people involved and then it does become easier to set that expectation, but I would encourage you to do this 00:24:21 [W] As you can within the project to start bringing more people on even if it's just encouraging people to answer questions on the mailing list and slack and you know, and sometimes it does require sir reaching out to individual people. 00:24:32 [W] So hey, you know, I don't know Joe Jane whoever I know you've got some interesting interesting thoughts on this. 00:24:40 [W] Why don't you answer that question and so you do really need to be proactive in order to make that to make that work and to bring in that that second company. 00:24:50 [W] So that that I think is the only question I haven't slack right now if there any other questions that come in really quickly I can go ahead and answer them. 00:25:01 [W] Oh, they're Noah has another question. Are there any other centralized lists of collateral material that you use besides the third three on the slide at the end? 00:25:11 [W] I would say that the cncf contributor strategy Sig has a ton of documentation that's being working prodyna. 00:25:20 [W] Us right now and so a lot of that material is either available now or it's going to be available soon. 00:25:27 [W] So I would encourage you to check back in that repository and that is one of the three mention at the end I know but but we are working on improving that area. 00:25:37 [W] July's lists of collateral material that you use besides the third three on the slide at the end. 00:25:39 [W] I would say that the cncf contributor strategy saying has a ton of documentation that's being working process right now. 00:25:50 [W] And so a lot of that material is either available now or it's going to be available soon. 00:25:56 [W] So I would encourage you to check back in that repository and that is one of the three mentioned at the end I know but but 00:26:03 [W] we are working on improving that area. 00:26:06 [W] So I would say that that's probably a really good one. 00:26:08 [W] There is another really good resource that I am now forgetting the name of but I'm going to I'm going to look it up and I'll post it in the slack Channel but Vicki breasts are has a site where she's been collecting a whole 00:26:47 [W] The slack Channel but Vicki breasts are has a site where she's been collecting a whole bunch of governance docks Charter docks things like that from a whole bunch of different projects and those service really really great examples. 00:27:02 [W] Two different projects and those service really really great examples. 00:27:07 [W] So I would say that that's probably another site that I would encourage people to have a look at because I do think there are a lot of really good examples there that people can use 00:27:19 [W] A question from from Carolyn. 00:27:22 [W] Do you see any difference between having unaffiliated community members on the governing board versus people paid to do it full time anything we should look out for I think it I think it kind of depends on those on the 00:27:37 [W] the one of the things that I've noticed so I've been working in open source for 20 plus years and when I first started it was it was a lot more volunteers working on projects and now it's gotten to the point where projects like like kubernative use for example 00:27:52 [W] CF projects the Linux kernel openstack projects like that are the vast majority of people are employed by companies and I actually think that that's one of the things that's really accelerated the adoption 00:28:07 [W] The contributions to open source is that you know people like me were being paid to do it. 00:28:10 [W] So we have more time than we would if we were just volunteering sort of evenings and weekends. 00:28:15 [W] So I would say that that's one of the things that that you can look out for is that you know in some cases and it works it works sort of both ways, right? 00:28:25 [W] So in some cases the people who are being paid for it are going to have more time to work on it, but in those cases to sometimes those people if 00:28:35 [W] Leave and go to another company they may or may not continue to decide to work on your project. 00:28:39 [W] They may be working on something else in the future the same thing as volunteers. They may have they may have less time to work on the project because they're not being paid to and they have other commitments on the other hand. 00:28:50 [W] They might have loads of free time on their hands. 00:28:52 [W] So I would say that it's it's less about whether somebody's Affiliated or unaffiliated and maybe more about 00:29:02 [W] How much time and you know Dedication that person has has on the project but one of the things that I do think is interesting is that you know, we we are in a position to help people 00:29:18 [W] You interesting careers and open source. 00:29:20 [W] So people who aren't Affiliated people who are volunteers who are looking to kind of kick start their career any opportunities we can give some of those people with mentoring sponsorships internships things like that where we can we can help some of those 00:29:36 [W] Start to build a career and open source. I think can be really really beneficial for a lot of people and so I think that's that's something we should keep in mind. 00:29:33 [W] I think when it comes to unaffiliated community members with that. 00:29:40 [W] I think we have exhausted the questions the engineers tell me I have less than a minute left. 00:29:46 [W] So I think this is probably a good time to wrap it up. 00:29:49 [W] I will continue to be on the slack channel for a bit so I can continue to 00:29:54 [W] to answer any of your questions there. So with that I will say thank you so much for joining me.