 So let's go ahead and get started, since we do have a few people here. I am going to talk today about how to be a good corporate citizen in open source. So my talk has three sections. I'll start by talking about the dynamics of collaboration and the complex interactions between individuals, communities, and companies within open source projects before moving on to contribution strategies and plans. And then the last section will have some tips for being a good corporate citizen and then we'll wrap it all up with a few links to resources and some final thoughts. First, I'll tell you just a little bit about me. I've been in the technology industry for well over 20 years, working mostly on open source projects from within companies like Intel, Puppet, and now at VMware. I'm responsible for our open source community strategy within the open source program office. I'm also on the steering committee for the Linux Foundations to Do Group. I'm a board member of Open UK. I'm a governing board member and maintainer for the Linux Foundations Chaos Metrics Project. And I'm co-chair of the CNCF contributor strategy technical advisory group and I have a PhD from the University of Greenwich where I spent some time researching how people collaborate within the Linux kernel. Before we dive into talking about how your company and your employees should collaborate in open source projects, let's talk a little bit about how collaboration works within open source projects and the complex interactions that we see between individuals, communities, and companies. While there are a few exceptions, contributions to most open source projects are centered around the individual. Contributions come from individuals rather than companies. And when someone submits a pull request to fix a bug or updates some documentation or add a feature, the change comes from that individual. And commits usually include a name and an email address, but unless the person is using a corporate email address, you might never know where that person works. And to make this even more complicated for companies in these open source projects, the leadership positions stay with the individual if that person changes jobs. So this means that an employee can take their leadership position right with them to their next company. So companies are well-served to make sure that these open source contributors are happy, well-compensated. Now, in most open source projects, there's really no direct way for companies to participate other than dedicating time from individual employees who contribute then on behalf of that company, which is becoming increasingly common. At VMware, we have people working full-time on open source projects like Spring, RabbitMQ, Kubernetes, and a bunch of other projects. And if you aren't sure how to contribute as a company, you might be able to hire an existing contributor, or possibly even a maintainer as an employee who can help do the work within the project on your behalf. And in addition to devoting time from your employees to the project, companies are also in a position to help open source projects by providing additional resources. Open source projects need funding or in-kind sponsorships for loads of things like infrastructure, legal representation. And they also appreciate sponsorships for events and other activities. And I'll talk more about all of that later, since corporate involvement in open source is indeed the main focus for most of this presentation. Open source communities include a very wide variety of individuals who are working together within these open source projects. This includes developers, release teams, localization and translation, marketing, community managers, tech writers, users and a whole bunch of other people who contribute to the projects. And many of these people contribute as part of their day job on behalf of an employer. And others contribute in the free time and they're both really important. And all of these people are working together as one community to accomplish a common goal, to deliver on an open source project. It's important to remember that the community or the project needs have to come first. If your company has something specific that you want to contribute to an open source project, it is only going to work if it's also something that the project and the community wants. Individuals and companies can't force a project to take a contribution that goes against the direction of what the project and the community wants and the best interest of that community. It's better to find ways for your needs to align with the needs of the project. And it's important to make sure that managers and leaders within your company understand this dynamic and are supporting the needs of the community when making contributions. Part of the role of the open source program office, if you have one, can be to help everyone navigate balancing this triad through education and best practices. The various groups within your organization need to understand that they can't just push features into these open source projects unless it's something that benefits the community and the project as a whole. And when companies try to do this, it puts individual contributors into a no-win situation that impacts employee retention and employee satisfaction. And in this no-win situation, the employee can't meet the needs of the community without jeopardizing their employment. And you just don't want to put people in that situation. By making sure that managers and leaders understand this dynamic, you can make sure that your individual contributors are doing work that meets your organization's objectives while also being good corporate citizens within the community. Okay, now that we have a better idea about how collaboration works for open source projects and companies, next up, we'll talk about how to build a contribution strategy and plans for participating in open source projects. Having a solid open source strategy and plans are part of being a good corporate citizen because successful participation in open source requires a long-term commitment. The individuals and companies that we just talked about spend months and years building trust and reputations in these specific open source communities. And all of that hard work is for nothing if those people keep getting pulled off of the open source projects to work on other things. So in this section, I'll talk about how to build strategies and plans that support your business goals so that you can justify continuing to do this work over the long term. The most important part of putting together strategies and plans for your open source contributions is aligning them with the overall business goals of your company. If your open source engagements don't support the overall strategies of your organization, you will drastically reduce the chance of being successful. By taking some time and effort to make sure that you support your overall corporate strategy, then it's going to be much easier to justify continuing these efforts during the next planning cycle for your organization. On the other hand, when your goals are not clearly aligned with your overall strategy, people will look at that open source participation as something that can just be cut or starved of resources. And this will also help you make the case to senior management and company executives who aren't involved in the low level details. Explaining how your open source contributions support the goals of the company can help the exact team understand the importance of the work. Now for many of us, our organizations use so many open source projects that it's really easy to get distracted and not know where to focus. It can help to think about which open source projects are strategic in some way for your company. Maybe there are some development or deployment tools that impact your ability to release products that generate revenue for your organization. Or is there software that's important for your ability to deliver customer facing products or services? And these can help you think about where to focus your efforts. Now at VMware, I curate a list of our most strategic projects across the entire company, strategic open source projects. And we work closely with our various business units to make sure we have the right projects on those lists. And right now, the list has 18 VMware originated open source projects and another 14 third party projects. And those projects get more attention from our team than other projects. We collaborate with the project owners and stakeholders to do high level health assessments and suggest improvements for the projects. We also make connections between product strategies and open source contributions to help contributors who work in different business units work together and understand why a particular project is important to each of them so that we can avoid doing something that causes issues for another team publicly in an open source project. For everything else, we focus on scalable efforts, best practices guides, automation, a Slack channel for general open source Q and A, regular meetups with presentations and discussion time, anything that we can do to help our employees do the right thing in open source in a way that scales across the hundreds or thousands of open source projects that we have people involved in. Now after you've decided which projects to support, you need to figure out how to find people who can contribute. And as I mentioned earlier, companies contribute to open source projects by having employees participate and collaborate within those projects. So you need to figure out how many people you need for each project and what skills are required for those people. In some cases, you might have employees with the skills you need who've already contributed to open source projects in the past, which makes for a really good starting point for new contributions. But the thing to keep in mind is that contributing to open source projects requires different skills than participating in internal projects. These people need to be comfortable in really ambiguous environments where they'll receive feedback, possibly difficult or negative feedback and be expected to respond to that feedback in the public in a professional manner. And keep in mind that not every engineer wants their work to be in the public spotlight, which can feel a little like being under a microscope sometimes. And if you don't have the skills internally, you might be able to find existing contributors that you can hire. But you also need to be a little bit careful about that option too, because you don't want to get a reputation within an open source project for aggressively poaching employees from other companies. So it requires a bit of nuance to make it known that you're interested in hiring people within an open source project without aggressively hiring them away from other employers. If you make it easy for your employees to contribute, your employees are more likely to reduce technical debt by contributing patches, bug fixes, new features, back into the upstream project, where they belong. If you have too many controls and strict processes, you're probably making it a lot harder for your employees to do their work. And you should think about whether your guidelines or processes help people engage in open source projects in ways that work well for your organization. While you do need to provide guidance about things like licensing, avoiding accidental disclosure of confidential information, along with internal review processes, this can be done in an educational way. And my caution about guidelines is that they can be written in ways that discourage contributions, especially when they heavily use really scary legal jargon with an emphasis on how you're gonna punish people if they make a mistake. And instead, you're better off writing guidelines in ways that help engineers understand what you need them to do and why in language that they can easily understand. So VMware, we have a really robust set of open source guidelines and a very lightweight approval process for contributing to open source projects. And as with any good strategy and plans, the outcome and results should be measurable so that you can tell whether your efforts are successful. So I love data, so measuring open source project success is kind of a hobby for me, which maybe is a weird hobby, but it is. And it's something I'm super passionate about. So I do tend to get a lot of questions about it. And usually the questions are focused on how to decide what to measure as kind of the starting place. And I think that's kind of the wrong approach and my answer is always the same. It depends. Because what you measure depends on what you're trying to achieve, which is why the slide is in the strategy and planning section. But ultimately you need to look at your strategies and plans and come up with criteria that will help you measure whether or not you're successful. For example, if you want to improve the performance of a particular piece of open source software, counting commits is not gonna help you decide whether you were successful. You'll need to have success criteria looking at specific performance types that you're trying to improve. If you want to gain influence within an open source project, maybe you measure increases in contributions or the number of employees moving into positions of leadership. And once you figure out the criteria, you can get some data to measure it, start measuring now to get a good baseline. And there are loads of tools available to gather contribution data about open source projects. Some of the more commonly used tools can be found in the Linux Foundations chaos project. So I've included the link there at the bottom of the slide. So having this data will help you not only measure whether or not you're successful but give you ideas for other things you might want to investigate in the future. Now that you figured out what you want to do, let's talk about how to do it while being a good corporate citizen and avoid some common but embarrassing mistakes. Each project is different and what you'll need to do to join the community will vary. So you'll want to have a close look at the project documentation, especially the contribution docs. Spend whatever time it takes to fully understand the contribution guidelines, the code of conduct, and other expectations for collaboration within the project. The expectations for contributors are different for every project. So don't assume you know how to contribute even if you have experience with other open source contributions. I also strongly recommend taking time to lurk in the community and understand how people participate. I have seen way too many over eager new community members who sort of jump into the community with both feet. They make all kinds of mistakes by violating community norms, maybe talking about things that just aren't relevant and generally kind of making a mess of things. Now everybody makes mistakes at some point but some of them can be avoided by just taking some time to learn about the community. Rather than barging in and trying to be an active participant on day one. So don't be afraid to sit back while you learn from other community members. By taking the time to observe and lurk for a bit, you can learn about how people behave and get a feel for how people typically respond. And then once you have a feel for it, you can start with something small like a bug fix. Once you start participating, you should expect feedback. Now sometimes this feedback will be kind, other times it won't be. So even when the feedback is harsh, there will be things you'll need to do to rework your contribution to make it acceptable. So you should try to stay focused on what changes you need to make in your contribution. In some cases you might need to have hard discussions with people about the merits of that contribution. But you can focus on the problem, deliver it with a bit of kindness while avoiding any attacks on the other person. And this is an incredibly difficult line to walk sometimes but staying professional and being kind to other people when responding to difficult feedback can make a big difference to your personal reputation within these open source projects, but also the reputation of your employer within these communities. And in many cases, especially when you're new to a community, you should expect to iterate on the feedback. You submit a wave of changes and then you're gonna get feedback on those changes and then you're gonna submit some more changes to accommodate that feedback. So just consider it something that's going to take some time. After you get past those first few small contributions, you wanna make sure that you spend time discussing proposed changes in the community before you start making them. By talking about contributions very early in the process, you can get feedback on the way to architect those changes so they'll be consistent with the expectations of the project. You can also learn about anyone else who might be working in similar areas to hopefully avoid conflicting changes that won't work together. And these discussions also help surprising people, especially if what you're talking about making is a big change. It also helps to break those big changes into several smaller, easier to digest contributions. It's a lot easier for maintainers to provide feedback on smaller contributions and it gives you time to make corrections if anything you were doing isn't quite right. And this allows you to iterate on that feedback through several contributions, making it less likely to have bigger fundamental issues that are harder to fix. It's also important to keep in mind that you don't have any control over the other participants in this project. This is different from working within a company where you can escalate issues to managers who can work to resolve problems with non-responsive employees. In open source projects, you don't have a strict chain of command or other ways to exert control over the people you collaborate with. And instead, you should strive, again, to be kind and easy to work with since you'll need to find other ways to influence people to respond to your patches and pull requests. A lot of the work that we do in open source projects is based on the relationships we have with other people. My PhD research, which I finished just a couple of years ago, was based on collaboration within the Linux kernel. And as part of that research, I interviewed a whole bunch of kernel developers. And in all of the interviews, they talked about the importance of their relationships with other people. Almost all of them talked about how existing relationships made it easier to collaborate with others. And all of the people I interviewed mentioned in-person collaboration at conferences and meetings as something that was important, which is why I'm happy to see them coming back. But people talked about how sometimes so much easier to work through really big difficult issues at conferences where you could just talk about it with other people. And it's easier to communicate with someone online after you've met them before or maybe shared a meal or a drink or just had a nice conversation with somebody at an event. Knowing the human being on the other side of the keyboard can really make a bigger difference than what you might realize. And if your employees are working on open source projects, you should see if there are any conferences where large numbers of other community members attend. By having some key employees attend those conferences, they can build deeper lasting relationships with others that will benefit your company and your employees. I've spent a lot of time at open source conferences over the years, and I have really deep and lasting connections with people as a part of those events. And now when I need to do something new or have a question, I usually know somebody who can point me in the right direction. And I often make introductions for other employees to people outside of the company who can help us learn something new or maybe solve some tricky issue. Upstreaming your patches helps you become a good corporate citizen, but it also has quite a few internal benefits for your company. When you maintain patches internally, every time the open source project releases fixes or other updates, you need to go through the work of reapplying your patches and possibly rewriting them if it's touched the code that was updated. Now the side effect of this difficult process is that people tend to put off applying updates, which can be a real problem if those updates contain security fixes, which they probably do. And while it takes more time up front, you're better off taking the time to submit those patches into the open source project where they can be properly maintained as part of the whole and where other people can benefit from them. The easier you make it for your employees to contribute these changes back into open source projects, the better off you'll be. Understanding maintenance expectations is also a big part of being a good corporate citizen. Putting large chunks of code into an open source project, disappearing and expecting someone else to maintain it, reflects very poorly on your organization. If you fix a small bug or make a minor change, you won't be expected to maintain those because somebody's already responsible for that thing that you just fixed or tweaked. But what you really need to think about this is when you're making large contributions, like a new feature or a new driver. You need to make sure that your employees are planning to maintain that code over the long term before you contribute it to the open source project. Now if you want to open source something because it has no users, it's old, it's crusty and you just don't want to maintain it anymore, please, please don't do that. Dumping your project into the open source community and hoping that someone else will be just dying to take over and help you out is at best a wee bit naive and 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 the project is a good reason to open source it. If a project needs to integrate with a whole bunch of other technologies, open sourcing it can make it easier for people to help you integrate it with the technologies that you might be less familiar with. And your company needs to be prepared to maintain the project over the long term just as you would with something you released under a proprietary license. And this takes time and resources. So you should make sure you plan for that. Before I wrap up this talk, let me leave you with a few resources you might find useful. The to-do group has a bunch of guides that have info about all aspects of how companies work with open source projects. And if you have questions about the to-do group, I know it's right there in the middle, I've taken a picture. The CNCF contributor strategy, technical advisory group, has a governance working group and a contributor growth working group, which provide templates and guidance about contributor experience, sustainability, governance, and openness to help people develop strategies for maintaining healthy projects. The open source way guidebook is a great resource that has loads of details about building and maintaining open source projects. And these are all good starting places for understanding best practices. And I have uploaded the slides on-schedged, so you should have those links handy. The work that we do within open source communities is in the public, and it's highly visible. Other contributors and the press will talk about our behavior and our participation, which can reflect positively or negatively on our organization's brand. And being a good corporate citizen within open source projects allows us to help make sure that our participation has a positive impact on our company's brand. With that, thank you for coming to my talk, and we can open it up for questions.