Is Your Open Source Project Healthy?

[00:00:04] Announcer: You’re listening to Community Signal, the podcast for online community professionals. Sponsored by Vanilla, a one-stop-shop for online community and Localist, plan, promote, and measure events for your community. Tweet with @communitysignal as you listen. Here’s your host, Patrick O’Keefe.

[00:00:25] Patrick O’Keefe: Hello, and goodness. The year is going by. We’re less than three months away from Community Signal turning five years old. I’m now thinking about how we might mark this occasion. If you have any ideas, please let me know via the contact page at communitysignal.com. On this episode, we’re talking open-source community health, governance, and metrics with Dawn Foster of VMware.

A big thanks to Carol Benovic-Bradley, Rachel Medanic, Heather Champ and all of our supporters on Patreon, who help keep our show in production. If you’re interested in joining them, please visit communitysignal.com/innercircle.

Dawn Foster is the director of open source community strategy within VMware’s Open Source Program Office. She is on the board of OpenUK, an organization committed to developing and sustaining UK leadership and open technology. Dawn is on the governing board and is a maintainer for the Linux Foundation’s CHAOSS project and is on the board of advisors for Bitergia. She has 20-plus years of experience at companies like Intel and Puppet Labs, with expertise in community building strategy, open-source software, metrics, and more. Dawn holds a PhD from the University of Greenwich, along with an MBA and Bachelors in Computer Science. She has spoken at dozens of industry events, including many Linux Foundation events, OSCON, SXSW, FOSDEM, and more. Dawn, welcome to the show.

[00:01:43] Dawn Foster: Thanks. Thanks for having me. I’m really excited to be here.

[00:01:47] Patrick O’Keefe: Part of what you do in leading the open source community strategy team at VMware is ensuring that the company is being a good open source citizen when people are participating in outside projects. What does good citizenry look like and how do you hold your key people accountable?

[00:02:03] Dawn Foster: That’s a really good question. It’s something that the Open Source Program Office as a whole is really focused on at VMware. We have a group of people primarily driven out of the engineering team within the Open Source Program Office. We have really detailed, clearly documented best practices for people to follow. We try to document as much as we can about what we think the right thing to do is when you’re either participating in external projects. Also, we have loads of what we refer to as VMware originated open source projects. We have projects that we started within VMware, we have projects that are third-party projects that we contribute to.

There are a lot of elements to being a good corporate citizen in open source projects. Some of the things that we focus on, one of them is upstreaming your contributions. From that standpoint, if you are using a tool internally and you make some changes to some bits of the code, we really encourage people to put those changes back into the upstream open source project. Not just so that everybody else can benefit from them, that’s a huge, huge benefit, but it also reduces the maintenance burden internally as well. If your patches are already in the main project, then that’s a lot less work for you every time they make a new release. That’s one of the things that we look at.

From the contributing to external projects standpoint, some of the other things that we look at are really trying to put the community first. It’s one of the things that you need to be careful about when you participate in open source projects. You’re there on behalf of the company, but you need to do the right things for the community. It’s really important to think about what the community needs and match that with what we need at VMware, some of the things that we think are important. For the most part, if you look at how we use open source projects within VMware, where we build our products on top of them, we use them in our infrastructure.

A lot of the things that we need are things that other big software vendors would also need too. I think that a lot of the contributions that we make, we focus on the stuff that is going to be important for lots of us. The other thing that we focus on too is what we, in the Kubernetes community like to call chop wood and carry water tasks. The things that get overlooked, they’re not as sexy as the hottest new feature, but some of the things that just have to happen. Like the release infrastructure, somebody has to maintain that, writing good tests, and making sure that those are good, writing documentation. Even like moderation. We have a person who’s full-time community management for Kubernetes that’s employed by VMware. He really works on stuff that’s beneficial to the whole Kubernetes project as a whole from a community standpoint. We contribute a lot of contributor experience or community resources as well. There’s really a lot to think about when it comes to being a good corporate citizen. It does boil down to considering the community first and doing what’s right for the project.

[00:05:06] Patrick O’Keefe: Having standards means that people run afoul of them. When it comes to accountability, and this could be at VMware, it could be in past jobs, when someone runs afoul of those standards, how do you typically find out, what’s the process for you learning about that and then how do you process it?

[00:05:19] Dawn Foster: That’s a really good question. There’s really no good answer to that. I wish I had this magic bullet that would be find out all of the things that you should know that people are doing in communities that might not be quite right. Generally, it comes in via some side channel. Maybe I know somebody who’s in that community and they say, “Hey, this person over here is maybe not doing something great.” It’s rarely a direct channel. It’s usually, “I heard from somebody that this was happening.”Then because all of this stuff is public, you can be like, “Oh, I heard that this is happening.” Then I can dive in. I can look at that person’s pull request issues, Slack logs, or whatever.

You can dig into the data and see what was going on firsthand, which is really nice because then it doesn’t become a he said, she said scenario. I think in most cases, it really is a matter of just education. There certainly are cases where people do things with malicious intent. Generally, when you’re talking about it, especially in employees within your company, it’s generally just a lack of knowledge about what they should be doing. This is one of the things that the best practices documents that we have internally at VMware are designed to be used for.

If we see something happening, we can send people the link to the best practice that addresses this particular behavior and say, “Hey, this is what we think you should do. This is how to do it the right way,” and provide people as much education and coaching as you possibly can. Because it usually is a matter of somebody didn’t think about how what they were doing affected other people. Maybe they didn’t realize the norms of the open source project, and it’s difficult and a little bit nuanced. Because every open source project is a little bit different.

Even though I’ve been contributing to open source projects for years and years and years, but every time I pop up in a new community, I still have to read the contribution docs because there will be something that that project does in a very specific and nuanced way that maybe the last project I worked on didn’t do. In a lot of cases, people just make mistakes and they don’t really think about what they should have been doing, and they just need a little more education, a little more knowledge.

[00:7:23] Patrick O’Keefe: Let’s take a pause to talk about our great sponsor, Localist.

Localist is an event marketing platform that aggregates, automates, and analyzes all of your virtual, in-person, and hybrid events so you can grow and engage your community. Their platform allows you to centralize your event calendar, automate email and social media promotion, and measure and analyze the ROI of your events. Localist integrates with your existing tools and you can even predict future event success using their Event Reach and Event Score features. Find out more at localist.com/communitysignal and take your event strategy virtual with Localist.

You have two people on your team. One is focused on open source project health and the other strives to, “help make connections between our third-party ecosystem contributions and our product strategies,” quoting you there. When it comes to making those connections to product strategy, is it more of a black and white thing like we have a need, and this open source project represents the most economical way for us to meet that need? Do you have people who might say to you, “Hey, this is interesting. I don’t know how it ties to our business. Can you find a connection, so we can get away with playing with it and throwing some resources at it?” What do you see most commonly?

[00:08:29] Dawn Foster: The driving force behind that particular project, which is making the connections between, at least the strategic projects that we contribute to, so VMware contributes to thousands of open source projects. What are the big top ones? How does the work that we do within that project align with what we’re trying to do as a company from a product strategy standpoint? The reason we’re focused on that is because what happens is a company the size of VMware, we’re 30,000 plus people. It’s a massive company. If I’m just some random engineer from some random business unit who has a need to contribute to Kubernetes, what they might not understand is what’s really important in Kubernetes to this other business unit, who’s building their product on top of it.

What we want to be able to make sure, and again, it’s about education, it’s about knowledge. It’s not about telling people what they can contribute to and what they can’t. It’s really about if you’re going to contribute to this project, you should understand that this other business unit relies on this other piece of technology, and we’re heavily invested in it. You should be sure to do what you can to support their work, and make sure that you don’t accidentally do something to detract from it. Because in open source projects, it’s really easy to write a competing feature to something. If we have a whole bunch of people working on something, we don’t necessarily want our employees undermining the work that we’re doing within open source projects out of just not knowing what another business unit was working on.

[00:09:58] Patrick O’Keefe: Is there a way for people to check for conflicts, say, since there are so many people in so many projects that are being contributed to, is there a lexicon or a search where they could say, “Hey, you should check this first and make sure that we’re not already doing something like this in this project”?

[00:10:13] Dawn Foster: I would say no, there’s probably not a really good way to do that. One of the ways that we do handle some of that is we do require people to get approval before they contribute to any open source project. We have some exceptions for big projects like Kubernetes, where we have loads of people contributing. If there’s a project that I want to contribute to, we have a tool internally, you’ll fill out a couple of fields. It’s really fairly lightweight when it comes to contributing to projects we’ve already contributed to. It does provide a way for us to have some sense of who’s contributing to which projects, which gets at at least being able to find people if we recognize that there’s some kind of a conflict in a project, or we need to talk to some people about our contributions.

We have the same tool, and it’s a similar process for open sourcing something from scratch within VMware. If we have a project that we want to open source, there’s a whole process for that as well, and that’s a little bit more detailed because making a one off contribution to a project is a little different than making a whole project open source. Also, once you get approved to contribute to that project, you’re approved in perpetuity to contribute to that project. It’s not like every time I need to contribute to it, it’s just you get the approval once and then you’re good to go. It gives us a way to have some sense for who’s contributing to what. At least the people who remember that they’re supposed to fill out that tool before they contribute to open source projects, which as you can imagine, a company the size of VMware is a educational challenge in and of itself.

[00:11:36] Patrick O’Keefe: No kidding. Speaking of the educational challenge and even sticking with the business strategy piece, if someone is struggling to describe open source contributions in a way that an executive sees as business relevant, what’s something that they could do to bring clarity? What are some of the things that you’ve done?

[00:11:52] Dawn Foster: That is super important. It’s something that I think a lot of engineers don’t think enough about. Those of us that have worked in open source for a really long time, it’s really obvious. You can check into these projects because it’s a way of building infrastructure across the entire ecosystem in common. You’re building on top of these industry standard open source components, and the value seems really obvious. However, when you give that pitch to an executive, it sounds an awful lot like charity. It sounds like, “I’m contributing to open source because it’s good and it’s the right thing to do.” It’s just the way that you do things, which is good.

That’s not the way executives think. Executives think about things from a strategic standpoint and from a bottom line standpoint. If you want to make the pitch to contribute to a new open source project, the closer you can tie it to the company’s business goals, the better off you’re going to be.

When I was at Pivotal, I put together our Kubernetes contributor strategy. I was basically figuring out where across the entire Kubernetes project we should be contributing and why. The way that did that was I tied everything back to, at the top highest level, I was like, “This is what Pivotal as a company is trying to achieve. These are the product strategies that support it. These are the things that we need to do within Kubernetes to support these product strategies.”

I tied everything back as much as I possibly could to product strategies. That sounds very mercenary way of doing it. It’s very VMware-centric. We need to do these things because it benefits us selfishly, but that’s sometimes the way executives see it. You make that pitch the best that you can and hope that things get approved. Then knowing that you could also do a lot of these other tasks within the project that are smaller things that just somebody needs to do. Because there will always be time when you’re waiting for your pull request to merge. You’re going back and forth on the mailing list with feedback about some particular thing that you’re trying to contribute.

There are always down times within open source projects while you’re just waiting for stuff. You can also work on documentation. You can work on the release process. There are also other things that you could do to benefit the project as a whole while you’re also doing the things that your company needs. You make the pitch to the executives based on strategy and products and what your company selfishly needs knowing that you will also encourage engineers to do some of the other things in between the work that they need to do that the company needs

[00:14:21] Patrick O’Keefe: Looking back. I’m sure you have a couple of times where that linking together product strategy with open source contribution worked out very well for you. What’s your favorite one or what’s the one that you draw back on to say like, “That’s exactly how it should work”?

[00:14:34] Dawn Foster: Honestly, it was the Kubernetes contribution strategy that I did when I was at Pivotal right before we were acquired by VMware. Because that was partly because I was really dedicated to putting that strategy together. I had lots of time to talk to product people and to talk to engineers and to talk to executives about what was important. That document got to be ridiculous. It was like 25 pages long by the end I think. It got to be a huge monstrous strategy doc. I was most proud of that because I think that was the one that I probably did the best job of tying everything together.

[00:15:10] Patrick O’Keefe: Just to back up a little bit for those that might not be familiar with Kubernetes, can you give like a quick how that made money or how that saved money business strategy example?

[00:15:20] Dawn Foster: Yes. Kubernetes is basically an infrastructure layer that allows you to manage clusters. It’s something that you can use when you have very extensive infrastructure that you need to be able to scale and use. Particularly, a lot of people use it in cloud infrastructure. It’s an infrastructure layer. What was important for us at Pivotal and now at VMware, it’s the same thing at VMware, was that we wanted an infrastructure layer that we could build all of our products on top of. When I was at Pivotal, we had products on top of various bits of infrastructure, and some of them were better than others.

As Kubernetes was taking off and starting to become more mature, one of the things that we looked at, and this was a strategic decision that was made before I even joined the company, was that we were going to shift to build all of our products on top of Kubernetes. The fact that we were involved in Kubernetes was a no-brainer. That was a strategic decision that had already been made. The part that was I think the most difficult was figuring out which bits of Kubernetes we needed to be involved in. If you think about, for example, big customers that wanted to use Kubernetes on Windows. At the time, it didn’t actually run on Windows. The Windows support just wasn’t quite there.

We had a couple of people that wrote big chunks of that along with the rest of a bunch of other people within the community basically to get it to run so that you could run Windows applications on top of Kubernetes. That was a no-brainer. We had a bunch of customers asking for it and it was something we were already working on. We continued to work on that. Then the other bit that we started to get more involved in, it’s called SIG API machinery. It’s the way that the APIs work within Kubernetes. When you’re building on top of something, you’re basically relying on lots of APIs.

We started getting somebody involved in the API group, so that we could start to better understand how it worked, and so that in the future we assumed that as we’re building on top of it, we’ll find gaps in the APIs because that part of the technology wasn’t as mature. It’s a lot more mature now. That was something that was more forward-looking. We’re like, “We’re definitely going to make heavy use of these APIs. Let’s get somebody in there to understand how they work. Then when we find some issues, gaps, bugs, we’ll have somebody who can help us figure out how to solve them.”

[00:17:36] Patrick O’Keefe: Pretty cool. Clients wanted something, it wasn’t there, you put people on it, clients gave you more money. There it is.

[00:17:43] Dawn Foster: Exactly.

[00:17:44] Patrick O’Keefe: Nailed it. Let’s take a pause to talk about our great sponsor, Vanilla. 

Vanilla provides a one-stop-shop solution that gives community leaders all the tools they need to create a thriving community. Engagement tools like ideation and gamification promote vibrant discussion and powerful moderation tools allow admins to stay on top of conversations and keep things on track. All of these features are available out of the box, and come with best-in-class technical and community support from Vanilla’s Success Team. Vanilla is trusted by King, Acer, Qualtrics, and many more leading brands. Visit vanillaforums.com.

You have a set of metrics that you look at to determine open source project health. One of them in particular caught my eye because I think it’s an interesting lens through which to look at all projects, all communities contributor risk. Can you walk me through that?

[00:18:30] Dawn Foster: Yes. This is something that I think a lot of people don’t think about when it comes to open source projects. That is that some of these big open source projects are done and maintained by fewer people than what you might think. The biggest example I can think of this was OpenSSL. There was a huge security vulnerability in OpenSSL. It’s a technology that almost every single company in the world relies on. This vulnerability was going to require a lot of time and effort to fix. What we quickly realized was that OpenSSL was maintained part-time by two people, none of whom were being paid to work on it.

We have this critical piece of technology that’s relied on by almost every single company in the world that only two people really seriously work on. In this case, the outcome was more positive. The Linux Foundation was able to put together something and basically so that these people can get paid to work on it more full-time. I think we have someone who contributes to it now. There are a lot more people working on this critical piece of technology. Some people call this the bus factor, which is if someone gets hit by a bus, what happens to the project? That’s a bit macabre. The best example I heard of this recently was somebody said that she likes to think of it as if they win the lottery, what would happen to the project?

All of a sudden they have all this money and they’re on a beach somewhere and they don’t give a crap about this little open source project. It’s something that we really need to think about as companies who are relying on these projects. It’s important to think about when you’re looking at third-party projects that you contribute to that are maintained by other people. It’s also something that I think we need to look at internally with our own open source projects. In some cases we have open source projects that really almost all of the contributions are made by a single individual. What happens if that individual wins the lottery and leaves VMware, and doesn’t want to work on this project anymore? Do we have enough people that this project could continue?

One of the things that I look at is are there several people making significant contributions to the project, so that if one of them left the company and decided not to work on it anymore, would we be able to easily continue the project? Now, it’s open source code. Realistically, anybody could pick it up and maintain it. For complex pieces of technology like OpenSSL, it’s like encryption technology. That’s pretty hardcore. Not everyone can just pick that up and run with it. In cases where we have a single person who’s working on a technology that is critical maybe to our strategy and that is relatively obscure and that not anyone could easily understand and you have one person doing that, that is something that probably needs to be addressed.

We need to bring in some more contributors, we need to mentor some people. I like to look at contributor risk as an opportunity for mentoring. I like to look at it as an opportunity for us to give other people a chance to work on a project and be mentored by an experienced contributor or experienced engineer, so that we can get more people into the project.

[00:21:42] Patrick O’Keefe: I find it really interesting because in that example, it’s like you have someone who probably thinks and can do everything. They do because they’re a doer. They make stuff, [chuckles] they’re an engineer. They just do it. It’s like a short term benefit for a long term risk because no one else is in the weeds with them. No one else understands it the same way. I think if you look at just online communities as a whole, people talk about the power of an individual contributor or people having too much influence, or even the person who started it, the community being almost a cult around the founder or around a personality.

That’s one of the ways communities can be built, but there’s also inherent risk in that you see it in a lot of different ways too because you can dominate a conversation. It’s like you can dominate a coding project or some open source project where because you do it so much, people almost are afraid to do it or feel like, “Why bother, why do it,” because they’re just going to do it anyway.

[00:22:40] Dawn Foster: That’s a really good point. You said two things that really hit home with me there. One is, and this is coaching that I provide to a lot of people, and it sounds counter intuitive, but this is especially true for open source projects that you start as a company, if every single email, every single Slack post, every single PR, every single issue is was responded to by an employee from that company, you’re setting the expectation that employees answer questions. Employees respond to pull requests, employees do code reviews. That’s not necessarily what you want to do. On the one hand, it sounds like they’re being just super responsive to everything. On the other hand, they don’t actually leave space for other people to contribute, which I think is really important. You don’t, as a company, want to dominate the entire project because if you do that, you might as well never have open sourced it. You might as well have kept it proprietary. The whole purpose of open sourcing it is you collaborate together and you innovate, and you get ideas that you wouldn’t have otherwise had as a company. I think that’s really important. You don’t want to dominate the project. That’s one of the reasons that the contributor metrics is really important.

You also several times mentioned risk, which is how I really like to frame metrics. I like to frame metrics or the interpretation of metrics as an element of looking at risk. Maybe it’s a tiny project and it’s not that it’s strategically important, and it’s not anything that somebody else couldn’t immediately pick up, it might be fine to have one person making all of those contributions. That’s a very small risk on behalf of the company. You’re taking a large risk if it’s a huge strategic project that one of your products has to have in order to function properly. Then that’s a huge risk that you’re taking as a company. I like to frame these things as just it’s an element of risk.

You can accept a higher risk if you need to, but anywhere that we can look for opportunities to minimize the risk and to mentor people and bring more people into projects, I think is a good opportunity. Especially, if you’re looking at projects that you started as a company. This contributor risk metric is really also an opportunity to bring in and mentor people from other companies. Maybe they’re companies that you work with or you’ve seen some big users of the product, it’s an opportunity to maybe bring some people in from outside your company and mentor them and grow them into being leaders within the project.

[00:24:57] Patrick O’Keefe: Thinking about this, it’s funny because I feel like the incentives that we lay out for online communities are often counter to this idea of taking a step back or allowing others to jump in. Whether it be some form of leaderboard, whether it be how solve the answers accumulate or whatever it is, there’s this game of collecting the most things. I wonder about incentives for, gosh, slowing down, which is something a lot of people wouldn’t want. There’s a documentary coming out on Netflix soon, it’s called The Social Dilemma. As a disclosure, my fiancée worked on it a very little bit and talks to people who worked at Facebook and Google and YouTube and Instagram. Tristan Harris is the main player in it, and talks about what I would say are the goals of addiction, of addicting people to your platforms and the money that was made through that. In that world, the incentives for slowing people down don’t exist. It’s a scary thing. It opens doors. I feel like they can, but again, I’m just thinking about what can we build into platforms? You can peak certain incentives at a certain rate limit, like, “You got your stuff for today. It’s time to go do something else.” Like the Nintendo Wii would tell you to go outside and get fresh air at different intervals, like, “Go outside.” I feel like it really takes some stern buy-in to say to ourselves, “This person’s on fire, but we got to throw a little water on them. We need to share that heat and let some other people feel that heat too.”

[00:26:29] Dawn Foster: I think that this is where open source communities are a little bit different than other types of more social communities. Because open source, a lot of it is more about collaboration and contribution and participation, and getting people involved and encouraging people, and getting people involved in some of those thankless tasks that nobody wants to do, like documentation and things like that. It’s one of those things that it’s a little bit different. Some of the other more social platforms, it’s just like the more social, the better. Collaboration doesn’t necessarily work that way. You don’t get more collaboration because I did more stuff. You get more collaboration because you got more people involved, and you gave them some space to contribute.

I think in a lot of cases, it’s a little bit about education. This is something that I’ve had conversations with other employees at various companies about this exact problem. I’ve had conversations where people are like, “I don’t see you answering a lot of questions in the community.” I’m like, “No, because if your community manager is answering all of your questions, it doesn’t give anyone else an opportunity.” What you don’t see behind the scenes is me pinging people on IRC, hopefully, from other companies or possibly from my own company and say, “Hey, did you see that question on the mailing list? I think you’d give a great answer to that.” As a community manager, I never wanted to be on the leaderboard, and this is very different. Some community managers want the community to be all about them, and that’s a different model than the one that I have.

It’s really about building the community as a whole. I want to be focused on helping other people participate and other people make connections. A huge chunk of when I was actively managing communities, which I’m not anymore, but I would spend so much time just making connections between people and pointing people to things. “Hey, did you see this thing? Hey, did you know that somebody else is working on this thing that you’re also working on? Maybe if the two of you work together, that would be better.” I spend a lot of time behind the scenes poking people and talking to people about how to be better within the community.

[00:28:29] Patrick O’Keefe: Let’s talk about open source governance. You told me before the show that you’ve been thinking a lot about the importance of neutral foundations and governance, and that most contributors have corporate affiliations, but that leaving the decisions in the hands of corporate affiliations often is not the right thing to do for the project. Talk about that. Talk about neutral foundations a little bit, if you could.

[00:28:48] Dawn Foster: Yes, absolutely. One of the things that’s important to think about, and again, this gets back to risk. This is a conversation that I’ve been having this conversation about governance a lot with people. VMware, we have lots of open source projects that we own, that we maintain, we own the trademarks, we control the governance. One of the things that we try to do is once a project starts getting traction and other people are contributing and a lot of people are using it and you got this community building around it and we have a lot of people, in a lot of cases we actively donate those to neutral foundations. When I say a neutral foundation, that would be something like the Linux Foundation or the Cloud Native Computing Foundation, Apache Software Foundation.

What these are, they’re nonprofits that are sponsored by a whole bunch of different companies that come together. What you get by putting a project into these neutral foundations is that you really get some assurance that everybody’s working together on a level playing field. If I want to contribute to a project and that project is a Linux Foundation project, then I can rest assured that I can participate on the same field as everybody else. Whereas, if the project is owned by a particular company and they have their own agenda that may or may not align with the community’s best interest, then they may take things in a different direction.

They may not accept your contribution because it competes with something that they have. It’s a bigger risk in general, if it’s owned by a company. We’ve seen some examples of this recently within open source communities where we’ve seen– In particular, the one that hit the press most recently was Google around the Istio project. There were two projects that were owned by Google, Istio and Knative. Both of those projects were a bunch of companies coming together and contributing code. VMware, Red Hat, IBM, other people contributed code to start these projects. Google convinced a bunch of people to contribute codes, start these projects.

What they said initially was that these projects would be donated to the Cloud Native Computing Foundation as soon as they started gaining traction. Then at some point last year, Google changed their mind and said, “No, sorry, we’re not going to do that.” What happened was a bunch of other companies had contributed code in good faith that it was going to be under a neutral foundation and that everybody is going to be on a level playing field, that just didn’t happen. There’s a bit of turmoil within some of those projects right now as people decide what to do, but it was a risk we took because it wasn’t started under a neutral foundation. It was owned by a company. Now that company’s decided not to do that. It puts people in an interesting position that we’d rather not be in.

[00:31:42] Patrick O’Keefe: You mentioned earlier there’s a form that people hopefully remember to submit for approval to contribute to an open source project. Is that a fact that that gets evaluated? Who owns the project? Is it a neutral project? Is that something that gets evaluated when determining whether or not we should contribute time and resources to it?

[00:31:58] Dawn Foster: It is one of the things that they should be taking into account. It’s complicated and nuanced. Every open source project, the new projects that we decide to contribute to those are generally, at least the big ones are approved by our chief open source officer. Our VP of open source is my boss. He runs the whole Open Source Program Office, he has to approve all of those. It also has to be approved by the business unit that’s sponsoring the engineer that’s contributing to it. The chief open source officer is Dirk Hohndel. He’s been working in open source for many decades, and he’s pretty good at looking at those things. For the most cases, it’s an element of risk. We can highlight that this is a risk. If it’s important enough, we’ll probably take that risk. I do know that it is something that he takes into account when he evaluates whether or not to approve projects.

[00:32:46] Patrick O’Keefe: Do you feel like if a project does reach traction, whatever that’s defined as, it sounds like it might be helpful to define that ahead of time so people can disagree later, but whatever that looks like, that corporations do have a, maybe this is too a strong word, but do have a responsibility to support the founding of a neutral foundation that’s beyond just their individual control?

[00:33:05] Dawn Foster: I wouldn’t say it’s founding a new foundation because I think we have plenty of existing foundations that are pretty good for it. I do think that it is a responsibility of the companies that start these open source projects to do the right thing by the project. In some cases, that might be donating it to a neutral foundation. Like I said, we certainly donate lots of projects or contribute lots of projects to open source foundations when they reach a certain level of maturity and it’s a whole ecosystem around them. In some cases, it might not make sense and that’s fine too. It’s certainly my preference. I would like to see projects under neutral foundations. Companies start projects. They have their own needs for them.

As long as they’re good stewards of those projects and they’re creating as much as they can, a level playing field for all participants, regardless of whether that person works at a competitor or your favorite company. I think companies can be good stewards of open source projects, but it’s a risky take. Companies change strategies, companies change their mind. Whereas, something like a big neutral foundation like Apache Software Foundation, the Linux Foundation, they aren’t tomorrow going to decide that they want all of their projects to go in some crazy direction that nobody likes. It wouldn’t be beneficial. They’d never get everybody on board to do that. Whereas a single company can.

[00:34:22] Patrick O’Keefe: I have some experience with open source projects. I bring the largest resource for the phpBB forum software, which at one point was a very large, top of the SourceForge’s leaderboard [chuckles] open source project. Man, the politics, goodness gracious. I just ran an unofficial resource, but the devs didn’t like me because I didn’t link to this thing that they wanted me to link to, or I didn’t link to their website enough or all of these things. It was just the thing that dominated Wikipedia talk pages, that drama. It’s like, “We shouldn’t link to them. They were involved in a book about the software.” Just the craziest, craziest stuff. Because I did that for 11 years and I had 4,500 objects of code or templates, themes, and then 1,500 developers, and they were downloaded like 35 million times. It really gave me this insight into the sometimes hyper-political world of open source projects, because it’s like anything else. Any other governance, it can get super politicized.

[00:35:21] Dawn Foster: Yes. I think you absolutely hit the nail on the head with the comment about the politics. Because this is one of the things that we struggle with about governance is that nobody wants to think about it. Engineers, they just don’t care. It’s like paperwork. “I don’t really care. I’m painting broad brushstrokes.” A lot of engineers really don’t care. They just want to work on the code. They want to solve interesting technical problems. This is part of why you get into some of these issues with governance is that you’ve got a lot of people coming together to solve interesting technical problems without putting the right governance structures in place, and then people get burned at the end because things didn’t happen the way that they thought they should.

Maybe they didn’t have the structures in place to prevent bad things from happening. I think it’s something that it does get incredibly political, and it’s something that a lot of people don’t really want to think about. It’s something we struggle a lot with. Part of the CNCF contributor strategy SIG, and we have governance working group that I’ve been contributing to, we’ve been putting together — Josh Berkus has been leading the development of what is governance document. That’s one of the things he talks about in this document, it’s like, “Nobody wants to talk about governance, and it seems like paperwork, but it’s really important for these reasons.” It’s something that open source projects, I think, struggle a little bit because it’s just something that a lot of people just don’t even want to think about. They just want to solve cool technical problems and be done.

[00:36:41] Patrick O’Keefe: That’s why companies have people like you.

[00:36:44] Dawn Foster: [chuckles] Exactly. This is the funny bit. I hate the politics, but I always seem to be the one that gets pulled into the discussions about politics. I don’t know why. It just happens. I spend a lot of time shielding engineers from politics is what I do.

[00:36:58] Patrick O’Keefe: Dawn, thank you so much for coming on the show. It’s been great to talk to you.

[00:37:01] Dawn Foster: Thank you. This is fantastic. I was super excited to do this. I’m really happy we had this discussion. It was really interesting. Thanks.

[00:37:07] Patrick O’Keefe: We’ve been talking with Dawn Foster, director of open source community strategy at VMware. Read Dawn’s blog at fastwonderblog.com, and check out VMware is open-source blog at blogs.vmware.com/opensource. On Twitter you can follow Dawn, @geekygirldawn and VMware’s open source program office, @vmwopensource.

For the transcript from this episode, plus highlights and links that we mentioned, please visit communitysignal.com. Community Signal is produced by Karn Broad, and Carol Benovic-Bradley is our editorial lead. See you next time.