 Welcome to my talk about growing participation in your company's open source projects. First, I'll tell you a bit more about me. I've spent more than 20 years working in the technology industry. And most of that time, I've been working on open source projects from within a wide variety of different companies. I've been the director of community at Puppet and community lead for Intel's open source technology center. I also have a PhD from the University of Greenwich in London that I got by researching how people working at many different companies collaborate within the Linux kernel. I'm currently working in VMware's open source program office and I'm responsible for our open source community strategy. I'm also a board member for Open UK, which is focused on developing and sustaining leadership and open technology within the UK. 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 also on the advisory board for Preturgia, which is a company that builds dashboards for project health for open source communities. Now, my work with an open source software has been focused on both growing participation in company-driven open source projects like at Puppet and also in helping our employees collaborate within large foundation-driven projects like the work that I was doing recently at FIFITOL within the Kubernetes project. In this talk, I'll focus mostly on building community for your company's open source projects. Building a community around your company's open source project is hard. If it was easy, you would already have an amazing community and none of you would be bothering to watch this talk. The reality is that we, as humans, are not mindless automatons. Humans have feelings. We have bad days. We can be squishy and unpredictable and irrational, but you can't have a community without the people. So you need to find ways to encourage people to participate. Sometimes it can be really difficult to get people to contribute to your project. And unfortunately, there is no magic bullet or one-size-fits-all solution for me to offer to you today. So instead, I'll focus on some things that you can do or not do to increase the chances of successfully building a community for your project. Before we dive into things, let me talk for a minute about how I look at different types of open source projects, how they're different, and the type of project that this particular presentation focuses on. Now, keep in mind that these are loose ideas with quite a lot of overlap, and not every project fits cleanly into just one of these. So think about this as more of a loose guideline. First, you have what I would call grassroots open source projects. These tend to have more people who contribute out of a personal interest in the project. They usually have independent foundations with elected governance to help with the coordination of the project. And I would put projects like GNOME and Debian in this category. Then you have what I think of as ecosystem projects, which also tend to be under neutral foundations for governance, but those foundations often look more like collections of companies, and a large percentage of the contributors are usually participating as part of their day jobs. This would include most of the Linux Foundation and CNCF projects like Kubernetes, for example. Now, this last category company is the focus of this particular presentation. So these are open source projects that are controlled by a company rather than being under a foundation. These projects are typically started by a company where most of the initial contributions come from employees, and the governance is usually solely or mostly controlled by the company who started it. So when I worked at Puppet, that was one example of this. As I mentioned earlier, there was also a lot of overlap. For example, you see open source projects being started by a company and then later moved under a foundation. And some of these projects have governance structures that keep the company or the companies that started them in control of most of the decision making. Other times they donate these to a foundation and the company doesn't have control over them anymore. So it kind of depends. And these sit somewhere between what I'm calling ecosystem and company projects, but think of it as not as three separate buckets, but as kind of a continuum of types of projects and they tend to fall somewhere within these lines. Before we get into how to get people to participate, I want to talk about some of the good and bad reasons to open source your corporate project. If you want to open source a project because it has no users, it's old, it's crusty and you don't want to maintain it anymore, please, please, please just don't do that. Dumping your project into the open source community and hoping that someone else would be just dying to take it over and help you out is at best, a wee bit naive, and it generally makes your company look bad. So make sure that you're open sourcing the project for the right reasons. For example, a desire to collaborate with other people and innovate on your project is a good reason to open source it. Open sourcing a project to drive greater adoption by incorporating more diverse use cases is another good reason. If a project will need to integrate with other technologies, open sourcing it can make it easier for people to help you integrate it with technologies that maybe you're less familiar with. But the catch here is that your company needs to be prepared to maintain the project over the long term, just as you would do with something you released under a proprietary license. So open sourcing a project is really no different. You still have to support it. It'll take time, it'll take resources and you need to plan for how you're going to support it over time. It is so easy to use internal meetings and tools within your company for communication and decision-making since people may be used to doing this for your other proprietary projects but this makes it much less likely for other people to participate. It really helps to have discussions and make decisions in a public forum like a mailing list or in public meetings that anyone can join or watch later. As a community member outside of the company, I want to be able to have input and to influence decisions in the project. A really good starting point is to use a public issue tracker that contains all and I mean all of the bugs and features that are currently being worked on and for your team to use pull requests and the same processes as any other community member when making contributions. These bi-directional communication channels give users, contributors and maintainers a place where everyone can get together to discuss use cases, to get direct feedback on features and just to talk about the project which can really help build your contributor funnel to help you turn some users into contributors and then those contributors into project leaders over time. Governance is a key part of building a community and it's directly related to what I was just saying about communication. If you want people to contribute to your company's open-source project, transparency and openness are really important. It's important to document who makes the decisions along with how and where those decisions are made. As an external community member, I might eventually want to move into a leadership position so I can help to document the process for becoming a leader. Now this doesn't necessarily mean that every leadership position is available to anyone who wants it but it should be fairly easy to move people into maintainership positions for your corporate project where they're responsible for some component or you can give them commit access or maybe access to do approvals within the project but ultimately if people feel shut out or constantly surprised by new directions or changes within the project they are a lot less likely to stick around which is why having clearly documented open and transparent governance processes is so important for your projects. In some cases, having documented governance that is open and transparent involves being really honest with yourselves and with the community. For example, you may want to keep the leadership for certain key roles within the company but by being transparent about your reasons and documenting this, people can understand why and avoid being frustrated about it later. There may also be areas where you prefer to have contributions and areas that are harder for people to contribute to. Put this in the documentation and make sure that you're encouraging people to contribute in the areas where their contributions are desired and more likely to be accepted. Make sure that you don't encourage people to contribute in areas where you're less likely to accept those outside contributions. You should really take a close look at anything that might be a barrier to contribution. For example, are all of your project meetings in a single time zone that isn't likely to work for people in other locations? Is it hard to find information about contributing? Having amazing contribution documentation, training and mentorship can also reduce information barriers and make it easier to contribute. Do you have a contributor license agreement process or a CLA process? If so, does it make it too difficult for contributors? Or on the other hand, is the process difficult for your engineers which can make it hard to accept contributions? And if the company doesn't like your, or if the community doesn't like your company's CLA, then it can pretty much kill the entire project and you never really get a chance. I was talking to a friend who worked at a big company with a particularly difficult CLA. And the projects they had with that CLA tended to fail from a community standpoint, but projects they sponsored that did not have their CLA tended to do well. Now, if you're stuck with a CLA and many of you are, then generous CLA exceptions for obvious or minor fixes that are built into your CLA bot can really help. One of the first things I did when I was hired at Puppet was to fix our CLA process, which was horribly broken and it was not integrated into GitHub at all, which made it nearly impossible for our engineers to determine if the person submitting the full request had actually signed the CLA, which resulted in a lot of neglected contributions. I tried to get rid of the CLA entirely actually and moved to a developer certificate of origin or signed off by process, which is also called a DCO. And those are a great option to reduce the barrier to entry for your project if that's a possibility for you. Now, I just talked a little bit about contributor license agreements or CLAs versus developer certificate of origin or signed off by also called DCOs and you probably want to have one or the other, but this decision should be done in context of the license. A few licenses like Apache 2.0 have some protections built into the license, so they tend to pair nicely with a DCO or developer certificate of origin process. It also helps to select the license that companies tend to like so that they're more likely to allow contributions from their employees. Apache, BSD and MIT licenses all tend to be pretty popular with companies. Whatever you do, whatever you do, do not try to make up your own license. There are a whole bunch of OSI approved licenses and your needs are not so special that you can't make one with those existing licenses work for you. I'm not a lawyer, I don't even play one on TV, so you do need to talk to your legal team and make a business decision about what type of license is best for you, but I encourage you to do your own research to understand how your licensing and other legal decisions will impact your efforts to build a community around your project. Just like Ricky Ensley convinced me to run my first and only marathon a couple of years ago in Scotland, it can take a bit of encouragement to help people participate in your project in a way that allows them to become successful contributors. You should make sure that you're proactive about helping community members contribute in meaningful ways. One good way to do this is by marking non-urgent and easy to solve issues as good first issues that new contributors can pick up. You can also use help wanted labels for issues that your team might not have the expertise or the time to fix right away. Now these two are also, these are a bit different. Help wanted issues usually requires some project expertise and they might take quite a bit more time to solve. On the other hand, good first issues should have easy and quick solutions that someone brand new to the community could easily tackle. The key here is in making sure that your employees actually leave these for other people to work on. You can also ping specific people who are involved in the community but who work outside your company and ask them to provide feedback in an area where they have expertise which helps people see that you want their feedback and hopefully encourages them to proactively offer it the next time around. One of the things that I see way too often is over eager employees who jump in to immediately answer every question or reply to every single post. At first glance, this just seems super responsive and proactive, but it has a real downside. It can inadvertently set the expectation that employees will always be the ones answering questions and always be the ones making decisions. You need to give the people who aren't working on this full time at your company the opportunity to participate and leave space for them to contribute. You'll also need to find ways to promote your project. This is an area where company driven open source projects might actually have a slight advantage. Companies have existing marketing channels and people who can help. So don't try to do all of the promotion yourself. Marketing may look easy but I've learned the hard way personally that I'm kind of terrible at doing marketing and it is way harder than it looks. The marketing team is not your enemy and they aren't evil. The really amazing marketing folks will take the time to partner with you. They'll learn about what you're trying to achieve and work jointly with you to come up with solid ideas for how to promote your project in a way that resonates with your particular audience. Your marketing team can help you take advantage of all of the many things that they're already doing for the company as a whole. They can help you get information about your project into newsletters, blog posts, social media and all kinds of things you would never think of on your own. This is one of the things, planning and product management that company driven open source projects struggle with the most. Most companies have established product planning processes and whole teams of product managers who use those processes to plan for new and upcoming releases. In a lot of companies, the product managers are in a separate product team outside of engineering and some of those product managers may never have actually worked in open source communities. So moving to a transparent process in the open with tools that allow anyone to participate is a big change for some teams and it might require some extra training, some mentoring and some practice for your product managers and your teams internally to get it right. The goal is to move away from using your internal tools and private meetings to make the product decisions by moving as much as possible to things like public issue trackers and GitHub projects where anyone can see and contribute to the features that are planned for upcoming releases. Where I see companies underestimate the amount of effort required is usually related to the time it takes to collaborate with the community. You need to have people available to answer questions, to discuss new features and to provide feedback on new contributions. Every company I have ever worked for has at one point or another struggled to manage incoming pull requests for open source projects since it takes quite a bit of time to evaluate those contributions and provide feedback on them. One of the problems is simply time, right? It takes time to thoughtfully reply and coach people through making improvements to their contributions. However, it isn't just about time. The people working on pull requests need to be comfortable providing tough feedback. The reality is that some pull requests will contain poor quality code or possibly never be merged because of fundamental conflicts with the direction of the project or the architecture. And it's important that employees respond to these in a way that's clear about the future of that contribution but also shows empathy and appreciation for the hard work that someone put into that contribution. Providing feedback is a skill and your employees might not magically just have those skills. They may need some training and some mentoring to help them provide the constructive feedback that they'll need to provide to community members. One of the benefits of working on corporate open source projects is that your company probably has close working relationships with partners and customers already. I think that sometimes we feel that participation in open source projects has to only grow organically and while organic growth is great, don't get me wrong, it's not the only option. Some of the companies you work closely with might have employees with relevant expertise or they may be interested in using and later contributing to your project. So don't be afraid to use your corporate connections to reach out to people who can contribute and work with some of these other companies and partners that your company has existing relationships and try to get their employees involved in the project as much as possible. I talked about a lot of things in this presentation but if you remember just a couple of things it's the importance of running your project in the open with as much transparency as possible. Without openness and transparency, it will be really difficult to get people to take you seriously as an open source project and will make it less likely that others will actually contribute. The other thing to remember is that it can be hard to build a community. So you should expect to have to actively encourage people to participate. They aren't just going to magically come and appear because you've released something into the open but you also need to make sure that you're supportive and encouraging while also leaving space and giving other people opportunities to contribute to your project. With that, here are a few resources that people might find useful. The to-do group, which is this track that the stock is a part of, they of course have a bunch of guides that are really useful for open source program offices and they have specific guides for starting open source projects and recruiting developers. GitHub also has a bunch of really good guides and these are not guides for using GitHub. They have guides about starting open source projects about building welcoming communities about best practices for maintainers. OpenSource.com also has a bunch of frequently asked questions and guides including how to promote your project, building community and licensing. And these are all great starting places for getting ideas about how to improve your company's open source projects. And with that, I will say thank you for coming and I look forward to seeing you in person at some future event when we're allowed to do that again. Thanks everybody, bye. Okay, but I am still here and available for questions if anybody has them. I think I have just over two minutes for questions. So not a lot of time, but I will be lurking in the community leadership Ospo track channel in the Slack all week. So we'll release Monday through Wednesday. So feel free to ask me questions there anytime you'd like. I also have questions that I've been answering in the chat for the talk and it looks like a couple more are coming in now. So I'll go ahead and answer those. And then when I'm done, I will be also in the VMware booth. So if you wanna come and hang out and ask me more questions, that's where I'll be after this talk. So a couple of the questions from the chat. Javier Perez asks, what do you recommend? Any tips to get my code or PRs accepted into those corporate governed open source projects? That's, it depends a lot on the project is the answer to that. So it depends a lot on how the project is, how the project is governed, how it's run. I would say start with the contributor guide for sure to see how they accept into their, how they accept PRs into their project. And it's worth also chatting with some of those people and seeing what priorities are important for them because a lot of the PRs that I see get rejected from corporate open source projects are PRs that really aren't well aligned with where the company wants to go with that project. So it can be a little bit difficult to get things accepted if they're not, if you're not aligned with their priorities. So that'd be my biggest recommendation is figure out what their priorities are and how you can contribute in that way. There's another question here about, from Rodrigo Zacara says he's working for a financial company. And right now we're discussing about having projects open on GitHub. The problem is that some directors want to create an internal pipeline for employee contributions, which looks like a terrible idea. The question was, is there any articles or content that demonstrates that the approach isn't good? I would say ask that question in the Slack channel because you might get some good resources and that's a much easier place to share links. I agree with you, that's probably not a great idea and it's gonna take some work to convince them out of it. But I think that the more work you can do in the open, the more likely it is that you're gonna get other people to contribute into your project, which I know is hard and that's a hard sell and it's not an easy problem. But maybe we can find some links for you to some other resources that will help you do that. I think some of the to-do groups has some good stuff on that. With that, they're telling me that my time is up and that I am done. So thank you everybody for coming to my session and I look forward to seeing you all at the next one. Take care, bye.