speaker-0: Hey everyone, this is Rachel Ramilliotis from Punch Tape. Welcome to the second episode of Contribute Beyond the Code. This time we're mostly talking about OSPOs, those oftentimes tiny but very mighty institutions within companies, big and small, in the technology sector and outside of it. They are often responsible for policy, communication, helping people to use open source technology. within the company and also how to contribute to open source technology without it. We're actually going to have a punch tape that is, is going to have an event on April 9th called the OSPO virtual event, which I would love for you all to attend. All you have to do is go to www.punch-tape.com. We are going to have a lot of great people speaking and it should be a good time. What I've found. Basically in my looking for speakers and talking through some of the issues that OSPOS have had is that they are little islands in all these different companies. And it would be great to convene everyone together to share best practices, to talk about how, what they're doing, how they're doing it. And in a lot of places outside of the technology sector, this is still very new. I've talked to people in banking and automotive, and it's really interesting to hear about how they're pulling up their sleeves and really getting to it. It is really, really important to companies that use open source, which is most of them. So without further ado, we're going to talk to this time Dawn Foster, who is a prolific speaker and writer, and she's been doing some great. writing about OSPOs recently, some of which I'll put in the discussion. A couple that I liked specifically were OSPO information at scale, which we do touch upon in the interview. And then another thing we touch upon is OSPO contribution strategies to demonstrate value, which is really important in a time when we're seeing layoffs just across the board, tough times out there. So I wanted to tell you those are at fast wander blog, although again, I will put them in the description. Dawn is also the newest Todo ambassador, which is great. And Todo has lots of great valuable content for people in OSPOS and not in OSPOS, frankly. So Dawn is an ⁓ open source strategic consultant, and she's also the director of data science at the Chaos Project. We had a great conversation, and I want to thank her for joining us. And ⁓ onto the interview. you Hey, Dawn, thank you for being with us here today.
speaker-1: Yeah, thanks so much for having me.
speaker-0: Okay, so you've written a lot about OSPOs recently and I think it's been lots of really great stuff. So we're gonna be asking you about OSPOs today. So you've said that one of the most underestimated skills in open source is demonstrating the value of an OSPO. I agree. Talk to me about why that is so difficult.
speaker-1: Yeah, part of the reason that that's so difficult for a lot of people is that the value of your OSPO depends almost entirely on what your organization is trying to achieve. So different companies care about different things. They have different strategies. They have different objectives, different, you know, mission and values. And so what one company feels is valuable about contributions to open source isn't something that another one cares about. And likewise, what that one cares about, maybe another one doesn't. So demonstrating the value of an OSPO, you really have to look at what's important for your overall organization. And then you have to be able to tie the work that you're doing within your OSPO to what your company or your organization actually cares about. And that's hard.
speaker-0: Would you also say it's about, this is taking even a step back, about the importance of open source or gosh, you hope that they get that by time they have an Ospo.
speaker-1: Yeah, it depends. It depends a lot on that individual company. think we've gotten to a point now. So when I first started in open source, I worked at Intel back in 2000 and all of our conversations around open source were about how it's not scary. It's okay. It's, you know, it's good to use. And people generally then were pretty terrified of open source, but now people generally understand the value of open source. And so I feel like A lot of companies, by the time they get to the point where they have an OSPO, they should generally understand the value of open source. But that doesn't mean that the value of open source is understood at the same level across the organization. So what sometimes happens is you get maybe a CEO or a CTO that really cares about open source and they spin up an OSPO and... A year later, when they've moved on to another company, you have a new set of executives or a new set of management, and they might not have the same views on open source. So you do, even with companies that have an OSPO, not all of them really understand the value of open source or understand the holistic value of open source. They might understand one piece of it, but maybe not another.
speaker-0: And so a follow on question is sort of, I think it's kind of along the lines of what you said already is obviously right now we're going through a time where we're seeing lots of layoffs and cutbacks and stuff like that. So when a company is cutting budgets and it looks, it's looking around, are their specific, specific things that can determine whether an Ospo survives? realizing its value and making that clear is important. Are there other? other accompanying things that can help there.
speaker-1: depends a lot. again, that's an answer to a lot of questions I have to say. But yeah, so being able to demonstrate the value. If the company understands the value and how the work that you're doing in an OSPO helps the overall organization achieve whatever it is they're trying to achieve, then that's your best bet. But I would say, you know, the bits that companies tend to always care about are things like licensing and compliance. So those are the things that keep a company out of legal hot water, for example. And so those are the things that they tend to care about. Now, I also think that those are the things that it's like base level, all of the OSPO's should have that. But the real value actually comes in the other stuff on top of it. And so being able to demonstrate that value means that you need to do more interesting things in open source that are going to have a greater benefit, I think, to your company. Right. Because compliance and licensing is all about risk management, which is important. But one of the real values that you get in open source is contributing back to the products that you rely on, for example. And if your executives don't see the value of that and they've let go of all of the people who do that, then I think that that's a short-term thinking from an organizational perspective.
speaker-0: Totally agree, of course. I've talked to a bunch of different people in OSPO's across different industries. And one thing I found is that sometimes to your point, it's all about the compliance and stuff and it sits with the legal department. Sometimes it's in an engineering department. What does that tell you? Like, depending on where the OSPO is sitting, what does that tell you? Does that tell you anything about how the company either values or thinks about open source?
speaker-1: It tells you a lot about what aspects of open source that organization cares about. if it's under the legal team, then they probably mostly only care about licensing and compliance. I'm sure there are exceptions, but that's a pretty good indicator to me that that's what they care about is risk management. Whereas from my perspective, I actually think the best place to have an OSPO is under the CTO, the Chief Technology Officer. Because their remit is generally across the whole organization. They can look more holistically across business units, across functions. And that's where we sat when I worked at VMware. That's where the OSPO was, was under the office of the CTO. And I think that works. I think that works quite well because you tend to be able to do a lot of good for the company because you get to work in lots of different places and you're not sort of pigeonholed into individual things. The worst place. I think for an OSPO is marketing because that tends to be, if you're focused on marketing for your open source efforts, I don't think that tends to work very well long-term because you're looking for generally kind of short-term gains. And I think it's not the right fit for an OSPO, but it sometimes gets put there because some organizations look at the value of OSPO as primarily developer relations. And that's when you see it get put into a marketing organization.
speaker-0: Yeah, I agree. I mean, I think it can be ⁓ a good thing, certainly, to talk about what you're doing in open source, but that can't be the core. Are there any sort of best practices in sort of how to put together an OSPO? Like in terms of, you're probably going to say it depends. Do you know what I mean? Like, should it be some portion of like legal, engineering, marketing, like, you know, three legs of the stool or whatever?
speaker-1: Yeah, I would say that the to-do group has loads of resources and putting together an OSPO. So I would say that, you know, if, for example, if you're working in an organization and you're interested in creating an OSPO, I do think that that's probably a really good place to start because they have loads of guides for how to do it. And a lot of, you know, it's interesting to look at a lot of OSPO's. A lot of OSPO's start with compliance because that's something that you kind of need to have as an organization. You need to make sure that you're you're complying with with licenses and that you're keeping track of everything that you need to keep track of from an open source perspective. So a lot of them start with that. And then you see a lot of them spin out into other areas. So a lot of OSPOs you see having a lot of program managers. they're running individual, running things programmatically. So they're putting together, you know, maybe somebody who's responsible for best practice documents, maybe.
speaker-0: Mm.
speaker-1: You have a program manager who's responsible for helping maintainers or putting together programs for mentoring for maintainers, things like that. A lot of different functions. And so. Yeah.
speaker-0: No, it's. That's I mean. Yeah, so it's just interesting. So yes, so I agree though, the to-do group has lots of good things to your teeth into. When I was preparing this, so of course you were at VMware previously, and it seemed like you had a really strong setup there, right? You did have best practice docs. You did have a Wiki and you had like a Slack Q &A channel. All things that I think are great. And if you're spinning up an Ospo, look into that. How, I have opinions on this because I was involved at Intel a couple of years ago with the, or less than a couple of years ago with the Ospo, but like how important is internal enablement versus external visibility?
speaker-1: think they're both important, but I do think that a lot of the role of an OSPO is actually internal enablement. And so that's what we spent a lot of our time on was helping people internally understand how to do open source and be a good corporate citizen as they were doing it. And so like you said, we had these whole loads of best practice documents, which were ⁓ on the OSPO Wiki for anybody within the company to use. And we had a Slack channel where they could ask any questions. And there was a lot of Also a lot of peer support. So it wasn't people asking questions of the OSPO, it was people asking questions. And there were people outside of the OSPO who'd run into, you know, maybe that same issue or had an answer to that question. And so we got a lot of community around that. And so I think an OSPO can really help you build that community of open source contributors, maintainers, practitioners within the organization. And so for us, the OSPO was really a lot of of internal work. But we also had a whole engineering team that was focused on upstream contributions to projects that we cared about. So we had somebody contributing to Kubernetes. We had some people contributing to some ⁓ machine learning projects. had people contributing to things that we thought were going to be strategic, but that maybe our product units didn't care about yet. And so we also had all of these people doing contributions to upstream open source projects and also going out and giving talks about it. I was responsible for the community strategy team within the OSPO. So I also did a lot of talks at conferences about some of the work that we were doing or things that I was interested in, best practices, stuff like that. So I think it is kind of an internal function, but it can also be external. And for us though, think for VMware, probably, because so many of our products and our product lines were deeply dependent on certain open source projects. We had loads of people from the business units who worked on product teams who were contributing back upstream to open source projects and running running booths at KubeCon and going out and giving talks about it. So we certainly had lots of people outside of the OSPO also evangelizing some of the open source work that we were doing within the company.
speaker-0: Yeah, I love that. Did you periodically, because VMware is huge, obviously, right? Were you updating the people internally? Do you know what I mean? That seems like a good idea to me, too. Obviously, you had a Wiki and a Slack channel. And I'm sure there were a certain group of people that were active, active, right? Did you also have a biweekly newsletter or let people know? Because I feel like you do a lot of work, right? Like with an Ospo and... going out and speaking about things and, you know, contributing. How did you communicate that? I feel like that's that sort of like drip, drip, drip communication is also part of the life. We're here, we're important. What's going on?
speaker-1: Yeah, no, we did have an internal newsletter that was run by, actually I think it was run out of our engineering team who had a technical writer, content specialist who did a lot of that. We also had a really excellent PR person and she did a lot of the communication even internally and helped with some of that and we had. materials that were, she had materials that were provided to salespeople so that they could communicate things. we had, I guess at different times we had different things. also for a while had some kind of OSPO meetings where anybody could join and we'd have guest presenters, not always OSPO folks, but lots of other people talking about a specific topic. So how do you do technical documentation for an open source project? How do you... do this?" And we would have sort of guest lectures, I guess, on various open source topics. And we promoted that pretty broadly. The other thing we did, we also had what we call the strategic projects list. And so we had a list of projects and we had two lists actually. We had one for VMware-owned open source projects and another one for projects that were owned by other people that we contributed to that were really important to us. So think things like Kubernetes, for example, and a few other cloud native projects. And so we had this strategic projects list and we also had somebody who updated details about each of those projects. So who's contributing right now? What are they focused on? What's going on in that project? ⁓ Have there been releases? We had this whole big thing that we updated, I think about once a quarter, maybe every other month. And that actually got emailed out to all of our executives. So, and to the people who contributed to it. So the people who were working in organizations that were contributing and also some of the executives where we would blast this out every two to three months and say, this is what's going on. And it was also a way for us to coordinate some of that work internally because of course we would have, we had multiple business units contributing to Kubernetes. And that's really nice that they know that each other exists and they know what each business unit's focused on.
speaker-0: Yeah, ⁓ I think it's super valuable, right? Because I think there's some people, like I said, they'll be super active. Then there's like executives who may or may not be super into open source, but should be aware of it, right? think that education and communication, a huge part of it, as you know. I think that's a good best practice, honestly, right? Like making sure that you're, I mean, that you're tracking what you're doing. Like that's probably good for anybody, whoever's doing it. whatever they're doing, but I just think that's, it's good to be able to point to that. Or I know too, like there would often be someone would come in and be like, I need these stats. Look, if you have those, that's always. Well, how about hard conversations where you were talking to product teams, whether this is at VMware or elsewhere around, you know, starting something up or deciding to go open source or shutting something down. How did you approach those types of conversations?
speaker-1: Yeah. Yeah, those are really difficult conversations. I would say that the two biggest ones that we used to have at VMware that happened kind of over and over. One was a hard conversation around whether to donate a project to the CNCF. so you would get, because we did a lot of cloud native. And so you'd get a lot of product teams that really what they wanted was to get a marketing boost. So if I donate this to the CNC app, it's going to get lots of attention. That would be great. That's not a good reason to contribute something to a foundation. There are good reasons to contribute something to a foundation. There are some people who are interested in contributing from other companies who have been a little reluctant because it's owned by VMware, and it's a good way to build out more of an ecosystem around the contributions to a project. That's a great way to... to help scale a project if you've gotten it to a certain level and you really just need some more participation. And so there are good reasons and bad reasons. And so those were really difficult conversations when you get a team that's really excited because they're going to contribute this to the CNCF and you kind of have to tell them, no, that's not a good idea. The other hard conversations we had were companies change strategy. So we would have an open source project that we were using that we had incorporated into product lines. we, that we had encouraged customers to use. then at some point we decided to go in a different direction and want to shut that down. And so teams would come to us and be like, Hey, can you archive this for us? You'd be like, yes, eventually, but not today because you've got some communication you need to do and you need to continue to provide security updates as you know, to give people time to transition to something else. And so putting together, helping teams put together those transition plans. for things that they wanted to archive that were still in use. Those were really hard conversations because you've got a team that really has already moved on. They've already picked some other technology. They're already working on it. And they're really not happy to have to be doing things like security updates on something they don't care about anymore. And so those were also really hard conversations.
speaker-0: Yeah, I mean, I bet, but that's definitely part of the education. And I'm sure in some place in their mind, they knew they were going to do this, but they're already thinking forward. So a couple more questions. So if you were advising a group of people or an individual that was going to start up an Ospo today, what are the three main things that you would do? to make sure that it started out healthy, had a nice long life, and was really successful in integrating into whichever kind of company it was integrating into.
speaker-1: Yeah, the advice that I would provide would be to start by talking to people, to start by talking to the executives within the company to understand what their expectations were for an OSPO, talk to the products that have incorporated a bunch of open source technologies into the products, talk to those product teams about how they're using open source, what they're doing, what their processes look like now. to really understand what's going on within the company now to be able to decide what to do next. And then the what to do next should probably include some aspect of compliance, because I do think that's a key function for an open source program office. And then one of the other things that I would think about doing is putting together some best practices, especially for company-specific things, because different companies have different licenses that they're OK with or not OK with. different expectations around what types of projects should be open-sourced and shouldn't. And I would put in place some approval processes for open-sourcing technologies. And not something heavy, like in a lot of cases, if there's something you want to open-source that is kind of a no-brainer, then that should not take long. If you've got something that has some, maybe some unique intellectual property or trademark requirements, then maybe that requires a bit more work. to open source it or something that has been developed internally that's going to require some scrubbing of commits before it gets put externally. So putting together a process that handles that in a way that is focused on making it easy for people to open source things, but to do it in a way that makes sense for the organization. So you want to make it easy, but you want to have some kind of process that, with the process being designed in mind for helping people do this, not preventing people from doing this.
speaker-0: I agree with that because I think once you're seen as sort of like an onerous part of the process, that's bad. It's going to be value add, partnership. So I think those are all.
speaker-1: One of the things that, you know, don't know, those of us have been kind of in and around OSPO's for a long time is you don't want people to think of the OSPO as the office of no. And you can easily get into that situation where people are asking the OSPO things, the OSPO always says no, and then people get frustrated and go around the OSPO instead of working with the OSPO to do things in a way that makes sense for the company.
speaker-0: Yeah, exactly. Okay. So we're a new podcast, but we've already started a tradition. ⁓ It basically Contribute is about everything around open source that isn't necessarily like super code focused. And so we want to celebrate and give a shout out to an individual project group of people that is really making open source possible, right? In their own way, but wouldn't necessarily be like. called out for it. And so I'd love to give you the floor to give a shout out to someone.
speaker-1: Yeah. So my shout out is to Emma Irwin and her open source software wishlist. So she's been putting together, it's basically a platform where she can match maintainers who need funding with people who are willing to do funding with practitioners who can help them with various aspects of their project where they need help. So this is something that is just getting off the ground. She's in the process of trying to collect enough enough wishes and enough sponsors that she can start to do some of that matching. So it's something that's early in its infancy, but I would say, you know, if you're a maintainer, if you're someone who's interested in funding some things, I would have a look at ⁓ OSS Wishlist.
speaker-0: That sounds awesome. We'll make sure that we, we too, in our marketing of the episode, give a shout out. It sounds like a great idea. But I want to thank you as well, of course, for all the work that you do and for taking some time to share all of the wisdom that you have around OSPO's and beyond.
speaker-1: Yeah, thank you so much for having me on the podcast. This has been a lot of fun.
speaker-0: Take care.
speaker-1: Thanks.
speaker-0: you ⁓
speaker-1: you
speaker-1: Yeah, thanks so much for having me.
speaker-0: Okay, so you've written a lot about OSPOs recently and I think it's been lots of really great stuff. So we're gonna be asking you about OSPOs today. So you've said that one of the most underestimated skills in open source is demonstrating the value of an OSPO. I agree. Talk to me about why that is so difficult.
speaker-1: Yeah, part of the reason that that's so difficult for a lot of people is that the value of your OSPO depends almost entirely on what your organization is trying to achieve. So different companies care about different things. They have different strategies. They have different objectives, different, you know, mission and values. And so what one company feels is valuable about contributions to open source isn't something that another one cares about. And likewise, what that one cares about, maybe another one doesn't. So demonstrating the value of an OSPO, you really have to look at what's important for your overall organization. And then you have to be able to tie the work that you're doing within your OSPO to what your company or your organization actually cares about. And that's hard.
speaker-0: Would you also say it's about, this is taking even a step back, about the importance of open source or gosh, you hope that they get that by time they have an Ospo.
speaker-1: Yeah, it depends. It depends a lot on that individual company. think we've gotten to a point now. So when I first started in open source, I worked at Intel back in 2000 and all of our conversations around open source were about how it's not scary. It's okay. It's, you know, it's good to use. And people generally then were pretty terrified of open source, but now people generally understand the value of open source. And so I feel like A lot of companies, by the time they get to the point where they have an OSPO, they should generally understand the value of open source. But that doesn't mean that the value of open source is understood at the same level across the organization. So what sometimes happens is you get maybe a CEO or a CTO that really cares about open source and they spin up an OSPO and... A year later, when they've moved on to another company, you have a new set of executives or a new set of management, and they might not have the same views on open source. So you do, even with companies that have an OSPO, not all of them really understand the value of open source or understand the holistic value of open source. They might understand one piece of it, but maybe not another.
speaker-0: And so a follow on question is sort of, I think it's kind of along the lines of what you said already is obviously right now we're going through a time where we're seeing lots of layoffs and cutbacks and stuff like that. So when a company is cutting budgets and it looks, it's looking around, are their specific, specific things that can determine whether an Ospo survives? realizing its value and making that clear is important. Are there other? other accompanying things that can help there.
speaker-1: depends a lot. again, that's an answer to a lot of questions I have to say. But yeah, so being able to demonstrate the value. If the company understands the value and how the work that you're doing in an OSPO helps the overall organization achieve whatever it is they're trying to achieve, then that's your best bet. But I would say, you know, the bits that companies tend to always care about are things like licensing and compliance. So those are the things that keep a company out of legal hot water, for example. And so those are the things that they tend to care about. Now, I also think that those are the things that it's like base level, all of the OSPO's should have that. But the real value actually comes in the other stuff on top of it. And so being able to demonstrate that value means that you need to do more interesting things in open source that are going to have a greater benefit, I think, to your company. Right. Because compliance and licensing is all about risk management, which is important. But one of the real values that you get in open source is contributing back to the products that you rely on, for example. And if your executives don't see the value of that and they've let go of all of the people who do that, then I think that that's a short-term thinking from an organizational perspective.
speaker-0: Totally agree, of course. I've talked to a bunch of different people in OSPO's across different industries. And one thing I found is that sometimes to your point, it's all about the compliance and stuff and it sits with the legal department. Sometimes it's in an engineering department. What does that tell you? Like, depending on where the OSPO is sitting, what does that tell you? Does that tell you anything about how the company either values or thinks about open source?
speaker-1: It tells you a lot about what aspects of open source that organization cares about. if it's under the legal team, then they probably mostly only care about licensing and compliance. I'm sure there are exceptions, but that's a pretty good indicator to me that that's what they care about is risk management. Whereas from my perspective, I actually think the best place to have an OSPO is under the CTO, the Chief Technology Officer. Because their remit is generally across the whole organization. They can look more holistically across business units, across functions. And that's where we sat when I worked at VMware. That's where the OSPO was, was under the office of the CTO. And I think that works. I think that works quite well because you tend to be able to do a lot of good for the company because you get to work in lots of different places and you're not sort of pigeonholed into individual things. The worst place. I think for an OSPO is marketing because that tends to be, if you're focused on marketing for your open source efforts, I don't think that tends to work very well long-term because you're looking for generally kind of short-term gains. And I think it's not the right fit for an OSPO, but it sometimes gets put there because some organizations look at the value of OSPO as primarily developer relations. And that's when you see it get put into a marketing organization.
speaker-0: Yeah, I agree. I mean, I think it can be ⁓ a good thing, certainly, to talk about what you're doing in open source, but that can't be the core. Are there any sort of best practices in sort of how to put together an OSPO? Like in terms of, you're probably going to say it depends. Do you know what I mean? Like, should it be some portion of like legal, engineering, marketing, like, you know, three legs of the stool or whatever?
speaker-1: Yeah, I would say that the to-do group has loads of resources and putting together an OSPO. So I would say that, you know, if, for example, if you're working in an organization and you're interested in creating an OSPO, I do think that that's probably a really good place to start because they have loads of guides for how to do it. And a lot of, you know, it's interesting to look at a lot of OSPO's. A lot of OSPO's start with compliance because that's something that you kind of need to have as an organization. You need to make sure that you're you're complying with with licenses and that you're keeping track of everything that you need to keep track of from an open source perspective. So a lot of them start with that. And then you see a lot of them spin out into other areas. So a lot of OSPOs you see having a lot of program managers. they're running individual, running things programmatically. So they're putting together, you know, maybe somebody who's responsible for best practice documents, maybe.
speaker-0: Mm.
speaker-1: You have a program manager who's responsible for helping maintainers or putting together programs for mentoring for maintainers, things like that. A lot of different functions. And so. Yeah.
speaker-0: No, it's. That's I mean. Yeah, so it's just interesting. So yes, so I agree though, the to-do group has lots of good things to your teeth into. When I was preparing this, so of course you were at VMware previously, and it seemed like you had a really strong setup there, right? You did have best practice docs. You did have a Wiki and you had like a Slack Q &A channel. All things that I think are great. And if you're spinning up an Ospo, look into that. How, I have opinions on this because I was involved at Intel a couple of years ago with the, or less than a couple of years ago with the Ospo, but like how important is internal enablement versus external visibility?
speaker-1: think they're both important, but I do think that a lot of the role of an OSPO is actually internal enablement. And so that's what we spent a lot of our time on was helping people internally understand how to do open source and be a good corporate citizen as they were doing it. And so like you said, we had these whole loads of best practice documents, which were ⁓ on the OSPO Wiki for anybody within the company to use. And we had a Slack channel where they could ask any questions. And there was a lot of Also a lot of peer support. So it wasn't people asking questions of the OSPO, it was people asking questions. And there were people outside of the OSPO who'd run into, you know, maybe that same issue or had an answer to that question. And so we got a lot of community around that. And so I think an OSPO can really help you build that community of open source contributors, maintainers, practitioners within the organization. And so for us, the OSPO was really a lot of of internal work. But we also had a whole engineering team that was focused on upstream contributions to projects that we cared about. So we had somebody contributing to Kubernetes. We had some people contributing to some ⁓ machine learning projects. had people contributing to things that we thought were going to be strategic, but that maybe our product units didn't care about yet. And so we also had all of these people doing contributions to upstream open source projects and also going out and giving talks about it. I was responsible for the community strategy team within the OSPO. So I also did a lot of talks at conferences about some of the work that we were doing or things that I was interested in, best practices, stuff like that. So I think it is kind of an internal function, but it can also be external. And for us though, think for VMware, probably, because so many of our products and our product lines were deeply dependent on certain open source projects. We had loads of people from the business units who worked on product teams who were contributing back upstream to open source projects and running running booths at KubeCon and going out and giving talks about it. So we certainly had lots of people outside of the OSPO also evangelizing some of the open source work that we were doing within the company.
speaker-0: Yeah, I love that. Did you periodically, because VMware is huge, obviously, right? Were you updating the people internally? Do you know what I mean? That seems like a good idea to me, too. Obviously, you had a Wiki and a Slack channel. And I'm sure there were a certain group of people that were active, active, right? Did you also have a biweekly newsletter or let people know? Because I feel like you do a lot of work, right? Like with an Ospo and... going out and speaking about things and, you know, contributing. How did you communicate that? I feel like that's that sort of like drip, drip, drip communication is also part of the life. We're here, we're important. What's going on?
speaker-1: Yeah, no, we did have an internal newsletter that was run by, actually I think it was run out of our engineering team who had a technical writer, content specialist who did a lot of that. We also had a really excellent PR person and she did a lot of the communication even internally and helped with some of that and we had. materials that were, she had materials that were provided to salespeople so that they could communicate things. we had, I guess at different times we had different things. also for a while had some kind of OSPO meetings where anybody could join and we'd have guest presenters, not always OSPO folks, but lots of other people talking about a specific topic. So how do you do technical documentation for an open source project? How do you... do this?" And we would have sort of guest lectures, I guess, on various open source topics. And we promoted that pretty broadly. The other thing we did, we also had what we call the strategic projects list. And so we had a list of projects and we had two lists actually. We had one for VMware-owned open source projects and another one for projects that were owned by other people that we contributed to that were really important to us. So think things like Kubernetes, for example, and a few other cloud native projects. And so we had this strategic projects list and we also had somebody who updated details about each of those projects. So who's contributing right now? What are they focused on? What's going on in that project? ⁓ Have there been releases? We had this whole big thing that we updated, I think about once a quarter, maybe every other month. And that actually got emailed out to all of our executives. So, and to the people who contributed to it. So the people who were working in organizations that were contributing and also some of the executives where we would blast this out every two to three months and say, this is what's going on. And it was also a way for us to coordinate some of that work internally because of course we would have, we had multiple business units contributing to Kubernetes. And that's really nice that they know that each other exists and they know what each business unit's focused on.
speaker-0: Yeah, ⁓ I think it's super valuable, right? Because I think there's some people, like I said, they'll be super active. Then there's like executives who may or may not be super into open source, but should be aware of it, right? think that education and communication, a huge part of it, as you know. I think that's a good best practice, honestly, right? Like making sure that you're, I mean, that you're tracking what you're doing. Like that's probably good for anybody, whoever's doing it. whatever they're doing, but I just think that's, it's good to be able to point to that. Or I know too, like there would often be someone would come in and be like, I need these stats. Look, if you have those, that's always. Well, how about hard conversations where you were talking to product teams, whether this is at VMware or elsewhere around, you know, starting something up or deciding to go open source or shutting something down. How did you approach those types of conversations?
speaker-1: Yeah. Yeah, those are really difficult conversations. I would say that the two biggest ones that we used to have at VMware that happened kind of over and over. One was a hard conversation around whether to donate a project to the CNCF. so you would get, because we did a lot of cloud native. And so you'd get a lot of product teams that really what they wanted was to get a marketing boost. So if I donate this to the CNC app, it's going to get lots of attention. That would be great. That's not a good reason to contribute something to a foundation. There are good reasons to contribute something to a foundation. There are some people who are interested in contributing from other companies who have been a little reluctant because it's owned by VMware, and it's a good way to build out more of an ecosystem around the contributions to a project. That's a great way to... to help scale a project if you've gotten it to a certain level and you really just need some more participation. And so there are good reasons and bad reasons. And so those were really difficult conversations when you get a team that's really excited because they're going to contribute this to the CNCF and you kind of have to tell them, no, that's not a good idea. The other hard conversations we had were companies change strategy. So we would have an open source project that we were using that we had incorporated into product lines. we, that we had encouraged customers to use. then at some point we decided to go in a different direction and want to shut that down. And so teams would come to us and be like, Hey, can you archive this for us? You'd be like, yes, eventually, but not today because you've got some communication you need to do and you need to continue to provide security updates as you know, to give people time to transition to something else. And so putting together, helping teams put together those transition plans. for things that they wanted to archive that were still in use. Those were really hard conversations because you've got a team that really has already moved on. They've already picked some other technology. They're already working on it. And they're really not happy to have to be doing things like security updates on something they don't care about anymore. And so those were also really hard conversations.
speaker-0: Yeah, I mean, I bet, but that's definitely part of the education. And I'm sure in some place in their mind, they knew they were going to do this, but they're already thinking forward. So a couple more questions. So if you were advising a group of people or an individual that was going to start up an Ospo today, what are the three main things that you would do? to make sure that it started out healthy, had a nice long life, and was really successful in integrating into whichever kind of company it was integrating into.
speaker-1: Yeah, the advice that I would provide would be to start by talking to people, to start by talking to the executives within the company to understand what their expectations were for an OSPO, talk to the products that have incorporated a bunch of open source technologies into the products, talk to those product teams about how they're using open source, what they're doing, what their processes look like now. to really understand what's going on within the company now to be able to decide what to do next. And then the what to do next should probably include some aspect of compliance, because I do think that's a key function for an open source program office. And then one of the other things that I would think about doing is putting together some best practices, especially for company-specific things, because different companies have different licenses that they're OK with or not OK with. different expectations around what types of projects should be open-sourced and shouldn't. And I would put in place some approval processes for open-sourcing technologies. And not something heavy, like in a lot of cases, if there's something you want to open-source that is kind of a no-brainer, then that should not take long. If you've got something that has some, maybe some unique intellectual property or trademark requirements, then maybe that requires a bit more work. to open source it or something that has been developed internally that's going to require some scrubbing of commits before it gets put externally. So putting together a process that handles that in a way that is focused on making it easy for people to open source things, but to do it in a way that makes sense for the organization. So you want to make it easy, but you want to have some kind of process that, with the process being designed in mind for helping people do this, not preventing people from doing this.
speaker-0: I agree with that because I think once you're seen as sort of like an onerous part of the process, that's bad. It's going to be value add, partnership. So I think those are all.
speaker-1: One of the things that, you know, don't know, those of us have been kind of in and around OSPO's for a long time is you don't want people to think of the OSPO as the office of no. And you can easily get into that situation where people are asking the OSPO things, the OSPO always says no, and then people get frustrated and go around the OSPO instead of working with the OSPO to do things in a way that makes sense for the company.
speaker-0: Yeah, exactly. Okay. So we're a new podcast, but we've already started a tradition. ⁓ It basically Contribute is about everything around open source that isn't necessarily like super code focused. And so we want to celebrate and give a shout out to an individual project group of people that is really making open source possible, right? In their own way, but wouldn't necessarily be like. called out for it. And so I'd love to give you the floor to give a shout out to someone.
speaker-1: Yeah. So my shout out is to Emma Irwin and her open source software wishlist. So she's been putting together, it's basically a platform where she can match maintainers who need funding with people who are willing to do funding with practitioners who can help them with various aspects of their project where they need help. So this is something that is just getting off the ground. She's in the process of trying to collect enough enough wishes and enough sponsors that she can start to do some of that matching. So it's something that's early in its infancy, but I would say, you know, if you're a maintainer, if you're someone who's interested in funding some things, I would have a look at ⁓ OSS Wishlist.
speaker-0: That sounds awesome. We'll make sure that we, we too, in our marketing of the episode, give a shout out. It sounds like a great idea. But I want to thank you as well, of course, for all the work that you do and for taking some time to share all of the wisdom that you have around OSPO's and beyond.
speaker-1: Yeah, thank you so much for having me on the podcast. This has been a lot of fun.
speaker-0: Take care.
speaker-1: Thanks.
speaker-0: you ⁓
speaker-1: you
