 fantastic sponsors. So here we are, our closing keynotes of the day. I really appreciate everybody being here and I would like you all to please put your hands together and give a very very warm welcome to Dawn Foster, Dr. Dawn Foster, who will be the first of our two closing keynotes for today. Please welcome Dorth. Okay, thank you all for for saying. I know that Cheryl and I are between you and drinks so I'll just keep this moving. My talk today has three sections. So I'll start by talking about the dynamics of collaboration within open-source projects between individuals, companies, and communities before moving on to talk about contribution strategies and plans. And then in the last section we'll have some tips for sustaining your contributions over the long term. And then we'll wrap it up with links to resources and then a few final thoughts. I'll start by telling 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 a board member of Open UK. I'm a governing board member and maintainer for the Linux Foundation's chaos metrics project. I'm co-chair of the CNCF contributor strategy technical advisory group and I have a PhD where I researched how people work together within the Linux kernel. Now, before we dive into talking about leadership and the importance of having a solid strategy, let's talk a little bit about how collaboration works within open source projects and the complex interactions between individuals, companies, and communities. While there are some exceptions, contributions to most open-source projects are centered around the individual. Contributions come from individuals, not companies. When someone submits a pull request to fix a bug, add a feature, maybe update some documentation in an open-source project, those changes come from an individual. Commits include a name and an email address, but in a lot of cases, unless the person uses their corporate email address, you really can't even tell where that person works. To make this even more complicated for companies, in most open-source projects, the leadership positions stay with the individual if that person changes jobs. So this means that an employee will take their leadership position with them if they change jobs. So since the employee can take their leadership position in a project, right with them to the next job, companies are well-served to make sure that we are happy and well-compensated as open-source contributors. Now, in most projects, there is no direct way for companies to participate, other than dedicating time from individual employees who contribute on behalf of the company, which is pretty common, right? At VMware, we have loads of people working full-time on open-source projects like Spring, RabbitMQ, Kubernetes. 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 to... Sorry, this isn't my computer and things aren't working quite as expected. That's right. So open-source projects need funding and all kinds of things, like in-kind sponsorships and things like legal representation. And they also appreciate lots of other support from companies. Open-source communities include a wide variety of individuals who are working together within open-source projects. And this includes developers, release teams, localization and translation, marketing, community managers, tech writers, users and lots of other people who contribute to these projects. And some of these people contribute as part of their day job on behalf of an employer. Others contribute in their free time. And they're all important. And all of these people are working together as one community to accomplish a common goal, right? To deliver on an open-source project. And it's important to remember that the community or project needs have to come first. And your strategies have to take this into account. So an approach that maybe dictates a specific solution might not be accepted by a project. So your strategies really need to include flexible ways of approaching resolving issues or creating new features so that you can find ways to work jointly with the community to find solutions that work for everybody. Now part of the role of an open-source program office, if you happen to have one, can be to help everyone navigate balancing these individual company and community needs. The various groups within your organization really need to understand that individuals need to be able to collaborate and build consensus within the community to come up with innovative solutions for anything that your company needs. Trying to force something into an open-source project can impact employee satisfaction and retention for the individuals who are contributing. Since the employee, if you put that situation where an employee can't meet the needs of the community without jeopardizing their employment, this just isn't a good situation for anyone to be in. And I've been in that situation, it sucks. But by taking this dynamic into account when building your open-source strategies and best practices, you can help managers and leaders within your organization understand this dynamic so that your employees can meet your organization's objectives while also being good corporate citizens within the community. Now that we have a better idea about how collaboration works for open-source projects and communities, next up, let's 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 important because successful participation in open-source communities requires a long-term commitment. The individuals and companies that we just talked about, they spend months and years building trust and reputations within 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 work on this 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 for your company. If your open-source engagements don't support the overall strategies of your organization, you'll drastically reduce the chance of being successful. By taking some time and effort to make sure that you support the overall corporate strategy, then it'll be much easier to justify continuing these efforts during the next planning cycle for your organization or the next economic downturn, for example. But on the other hand, when your goals are not clearly aligned with the overall strategy, people will look at that open-source participation as something that can be cut entirely or just starved of resources until it goes away on its own. And this will also help you make the case to senior management and company executives who aren't involved in any of the low level details. Explaining how your open-source contributions support the goals of the company can help the executive team understand the strategic importance of this work. Now, most of 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 projects that your operations team uses to run some of your critical business infrastructure. Or maybe there are some development and deployment tools that impact your ability to release the products that generate revenue for your organization. Maybe there's other software that's important for your ability to deliver those customer-facing products and services. And all of these can help you think about where to focus your open-source efforts. And these strategic projects should get more attention than other maybe less important projects. And these strategic projects should be a big part of building your open-source strategies by showcasing how you use certain open-source projects and the products and services you deliver to customers and how it relies on those projects. You can use these strategic projects to help frame some of your strategies in a way that leadership will understand how important it is to continue this work over the long term. A obligatory XKCD comic. It's important to think about risk as part of your company and product strategies. Evaluating risk is important because your business could be disrupted in ways that impact your employees, your customers, even the broader ecosystem. It's also important to think about risk as being on a continuum. So like with most things in life, there are no sure bets, right? There's no project or technology that's completely without risk. There are only projects with more or less risk across a variety of categories. And whether you accept that risk is a business decision and a strategic decision that should also take how you're using the project into account. We don't want to build a key product on top of some really risky open-source technology, right? So it's important to think about what elements of an open-source project might introduce risk for us and how we can watch out for warning signs and mitigate potential risks. But this is bigger than just thinking about individual projects, right? It's absolutely critical for all of us to be thinking about security and risk holistically across our entire software supply chain, including every little package that goes into our products, our infrastructure. A potential vulnerability or malicious attack can be in any link in the chain where it can go unnoticed if you don't actually have processes and tools in place to detect it as early as possible. And your company's open-source strategy should incorporate some thinking about how you can detect potential issues and mitigate the risks associated with them. Most of us have some combination of projects that we've open-sourced within our company and other open-source projects that we contribute to. Now, this is also a decision that benefits from a strategic approach. In some cases, it can totally make sense to release a brand new open-source project. And other times, the best solution would be to contribute to an existing open-source project in ways that would help it meet some of your needs over the long term. And there's no right or wrong answer to making this decision, but I encourage you to look hard at your company's strategies and plans for the future to make sure that whatever decision you make is aligned with what your organization's likely to need over the next few years rather than just thinking about the easiest thing to do right now. As part of your open-source strategies and plans, you need to figure out how to find people who can make the contributions that you need on behalf of your company. Now, as I mentioned earlier, companies contribute to open-source projects by having employees participate and then collaborate within those projects. So you need to figure out how many people you need, what skills are required. In some cases, you might actually have the employees with the skills you need who have already contributed to some of these projects, which is a great starting point. But it's really important to keep in mind 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're going to receive feedback, likely at some point difficult or negative feedback, and they're going to 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, so, which, I mean, let's be honest, can feel like being under a microscope sometimes. But if you don't have the skills internally, you might be able to find existing contributors that you can hire. This is a pretty common path, but you 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 to work on an open-source project without actually aggressively poaching 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, and new features back into the upstream projects where they actually belong. 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. Well, you do need to provide guidance about things like licensing, disclosing confidential information, and any internal processes. This can be done in an educational way. So my caution about the guidelines and processes is that they can be written in ways that discourage contributions back into the upstream project, especially when they make heavy use of really scary legal jargon where you talk about how you're going to punish people when something goes wrong. So instead, you're better off writing those in ways that help engineers understand what you need them to do and why and language that they can easily understand. Now, as with any good strategies and plans, the outcome and results should be measurable so that you can tell whether your results were successful or not. Now, I love data and this sounds kind of weird, but measuring open-source project success is kind of a hobby of mine. And it's something I'm pretty passionate about. So I do get a lot of questions and usually the questions kind of start out with, you know, what do I measure? And it's, I think that's kind of the wrong approach because it depends. What you measure depends on what you're trying to achieve, which is why this slide is in the strategy and planning section. 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. So for example, if you want to improve the performance of a particular piece of open-source software, you'll want to have success criteria and measurement based on that specific type of performance. Counting numbers of commits won't tell you anything about whether you improve the performance of a piece of software. So, you know, on the other hand, 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 influence. And once you figure out the criteria, you need to make sure that you can get the data required to measure it and start measuring it now to get a good baseline. And there are loads of tools available to gather contribution data about open-source projects. Some of the commonly used tools can be found in the Linux Foundation's Chaos Metrics project. And many big projects already have dashboards using these tools and others to display contribution data for the project. I also recommend maybe overmeasuring a bit so that you have a little more data so that is your strategy shifts. You're more likely to have some good data to start out with. And this can help you investigate maybe other areas that you might want to improve in your projects. Now, in this next section, we'll talk about a few tips to help you sustain those contributions over the long term. Upstreaming your patches is one of the most important things you can do as you work toward... Can you still hear me? Did the microphone cut out? No? I'm still good. Okay. So, upstreaming your patches is one of obviously the most important things you can do as you work toward taking a long-term strategic approach to your open-source contributions. Maintaining open-source patches internally is easier in the short term, right? Because you just make that patch and then you move on to do some other work. But it creates technical debt and more work for your project over the long term. And this can create security vulnerabilities for your company and your customers. If your employees put off this difficult work of reapplying or possibly rewriting some of your patches every time the open source project releases fixes or other updates. When you have patches that can be submitted back upstream, it gives your employees a solid starting point for contributing to an open-source project. Especially in cases where you have small patches to fix bugs that would benefit the entire community. The project's likely to welcome those types of changes. And it gives you something you can use to engage in the community. And these early interactions can help you build and grow those into long-term strategic participation in those projects and build relationships that allow you to contribute in more significant ways over time. You want to make sure that you spend time discussing your proposed changes in the community before you start making them. By talking about contributions really early in the process, you can get feedback on ways to architect those changes so that 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 when they're merged into the project. And these discussions also avoid surprising people, especially for something new or big changes. It can also help to break those changes and do smaller, easier to digest contributions. It is way easier for maintainers to find the time to provide feedback on smaller contributions, and it gives you time to make corrections or changes if something you're doing isn't quite right. By participating in open-source projects over the long term, your employees can build trust within a community and build the relationships needed to eventually move into leadership positions and increasing responsibility. By moving into leadership positions, people gain additional insights into the future of the project and have increased influence into the direction of the project. These people are more likely to know how to approach new features and other changes in ways they're already aligned with the direction of the project and can be easily merged into the upstream project. And you can rely on these open-source leaders to help you refine your strategies since they will likely have ideas for what can be done within a project and how to best approach your work within that project. And these leaders can also help mentor and provide guidance for other employees when you decide maybe that you need more contributors within a project, which can help you build more open-source skills within your company. A lot of the work that we do in open-source projects is based on the relationships we have with other people. So my PhD research was based on collaboration in Linux kernel. And as part of that research, I interviewed a 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 those existing relationships made it easier to collaborate with others. All of the people I interviewed mentioned in person collaboration at conferences and other meetings is something that was really important. People talked about how it was sometimes easier to work through really difficult big issues at conferences. It's easier to communicate with someone online if you've met them before, maybe you shared a meal or a drink or just had a nice conversation with them at an event. And 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, like this one, like QCD Amsterdam, where large numbers of the community members attend. By having some key employees attend these 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've deep and lasting connections with the people that I've met at those events. And now when I need to do something new or have a question, I usually know someone who can point me in the right direction from the community. 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. You also need to take maintenance expectations into account when building your open-source strategies, putting large chunks of code into an open-source project, disappearing and expecting someone else to maintain it for you reflects poorly on your organization. So you need to think about how you're planning to maintain those contributions that you're making. Now if you fix a small bug or make some small change, someone else is probably responsible for maintaining it. So you're off the hook there but where you really need to think about this is when you're making large contributions, like a new feature or in the case of the kernel a new driver. And you need to make sure that you have a plan for how your employees are going to maintain that code over the long term before you contribute it into the open-source project. Now 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 just don't do that. Dumping your project into the open-source community and hoping that someone else will be just dying to take over this piece of crap that you don't want, at best is naive and generally makes your company look bad, right? So make sure you're open-sourcing a project for the right reasons. For example, wanting to collaborate and innovate with other people. That's a good reason to open-source it. If you're working on a project that's going to need to integrate with a bunch of other technologies, open-sourcing it can make it easier for other people to help you integrate it with technologies that maybe you're less familiar with. But again, your company needs to be prepared to maintain that project over the longer term, just as you would with something you put under a proprietary license. It takes time and resources. You should take that into account when building your strategies. Before I wrap up this talk, let me leave you with a few resources you might find useful. The to-do group has loads of guides that have great info about all aspects of how companies work in open-source projects. The CNCF contributor strategy tag has governance working group and a contributor growth working group. And we provide templates and guidance about contributor experience, contributor sustainability, governance and other things to help people develop strategies for maintaining healthy projects. The open-source way guidebook has loads of details about building and maintaining open-source projects. And the chaos project has loads of metrics to help you measure open-source project health and whether you're successfully achieving your strategies. And these are all great starting places for understanding best practices for open-source projects. In open-source projects, relationships and trust facilitate collaboration and allow your employees to more easily contribute to the projects that are important for your organization. And then move into leadership positions within those important projects. These relationships and trust networks are built over time and require a long-term commitment. Thinking strategically about which projects are most important for your organization and then allocating people to work on those projects over the long-term lets you maximize the impact that your open-source work will have for your organization. With that, thank you so much for coming to my talk and I don't know, do we have time for questions? Or should I let Cheryl set up? Of course we do. Do we have any questions for our friend on? Yes? We do have one question? Good, I'm losing my voice. Oh, Sal, hello. So on this, so just like with my maintainer hat on, right? And when you get these feature requests from companies that would take you 11 months to deliver and they don't want to pay you for it. Little irritated with that. So we've got the process of here if you're a new contributor, go and find like great first contributions. Something that I'd like to see more roadmaps offering is like suggested corporate sponsored features because those are the features that require longevity, right? Yeah. It's not the bus problem, it's the vacation problem. Like do you have enough maintainers in a project that you can go on vacation and it still works? You need a corporate sponsorship for those. Is there anything like that? Not that I've seen. I mean, I think probably the best way to address it is what you kind of mentioned, which is with roadmaps and having some roadmaps and being clear about what the existing maintainers actually have time and space to do. But the things that you actually really want that no one really has time for and try to get some people to pick those up. And then in some cases those come from the other direction as well. Like there are things that companies need. One of the things that VMware worked a lot on was cluster API, for example, because it was something that we needed and so we put a whole bunch of people on it and helped out as much as we could with kind of building out some of that infrastructure. So it's kind of both ways, but I would love to see more projects have detailed roadmaps for things that they want but don't have time to work on and then, you know, try to recruit corporates, corporatites to work on those. But it's a hard problem, right? Like finding enough contributors and sustaining that over time when maintainers are already burnt out and tired is a big problem right now. It's something we talk about a lot in the CNCF. Any other questions? Down front. I was at FOSDM two weeks ago and there were presentations by the Free Software Foundation in Europe. And they were like not very friendly towards the CNCF and their big company, Megacorps, they were really and I don't understand where this negativity comes from. Maybe you can help me. I am not stepping into that landmine. The CNCF and the Free Software Foundation in Europe are very different types of organizations and I think they serve different purposes. Like I don't like to think of those as like one being better than the other. I tend to think of them as both being good for sort of different things. Like CNCF is good for getting a whole bunch of companies together to do some stuff. You know Free Software Foundation in Europe I think is really good at getting individual people together to do some stuff and I think that those are both really valuable parts of the open source community. So I'm not going to pick one over the other. So done. Well my very first contribution to open source was with a project that probably nobody knows is open mosaics, high performance computing and I did a mess of it. The whole contribution was took three months to get into the patch, the kernel patch. I wish I had this before. I wish I know how I had to handle the whole thing before. Thank you very much. Yeah, thank you. Thank you very much. Thanks.