Using Open Source Events & Ecosystems to Improve Company Culture

Noah: So thanks everyone for coming along. Today we are here in our Fireside Chat with our special guest Stephen Augustus, Head of Open Source at Cisco.

Stephen: Hello hello everyone. 

Noah: I am one of your co-hosts, Noah Abrahams. I am the Open Source Advocate here at StormForge, and with us as always is my other co-host, Cody Crudgington. Today we’ll be talking about using open source events and ecosystems to improve company culture. I’m gonna go ahead and stop sharing so that we can get back to a proper view. This is us. 

Stephen: I love this like quantum superposition of all of us occupying the same space. How amazing. The power of the internet.

Noah: So for today’s conversation, like I said, we’re focusing on open source today and one of the things that has really driven me to open source and has driven a lot of people to open source is the ability to get involved. That you don’t need to work for a particular company, you don’t need to file applications, you don’t need to get into a particular place. You can just get involved. But that also brings along with it that everyone’s story is different. Everyone can get involved in unique and different ways. So let’s start with your story, Stephen. How did you get involved? How did you get started in open source? 

Stephen: For sure, for sure. So I think that we all have been involved in open source, right? Longer than we think really, right? So whether you’re… I guess whether you’re looking something up on Stack Overflow or consuming a piece of software that you’re like, oh this looks pretty cool and it looks like it does the thing that I need it to do, this is awesome, I’m going to use it. 

So I think where that really came to a head was when I was working at the startup in New York and we were starting to explore… it’s kind of a Ruby shop as well as a windowside.net… and we were starting to explore containers and kind of exploring containers for our staging environments. So we had this staging environment called Broadway, because Broadway has stages, and that was run on Docker Swarm and bash scripts duct tape, as you do, right? 

So each of the devops engineers at the time kind of had their own special project. One of the guys was working on going a little deeper into Docker Swarm. Someone else was working on investigating Rancher. And then there was kind of like a gap in the middle.I just started and I was like well I’ve got to fill that gap with another cool container project maybe. Now that we’re kind of like venturing into this territory with Docker Swarm, it’s clear that we need service discovery, right? For all these microservices that we’re kind of building out and trying to connect the pieces between. So I started looking at like etcd and Console as potential options and that brought me to CoreOS and kind of investigating what CoreOS was laying down. I thought they told a really good story, right? Between NCD Fleet Flannel and then kind of like further off into the distance Kubernetes, right? 

So I think Kubernetes might have been 1.2 at the time and I was like this is it. I was like this is it. This is what’s gonna be the hotness. So Kubernetes 1.2. I started digging into the background of it and realizing that like Kubernetes for Google, Google’s running on the… my spiel was like, Google’s running on the order of two billion containers a week with a technology that looks a lot like this, I’m pretty sure it’s gonna suit our needs. We have nowhere near the capacity or requirements, this is probably gonna fit and this CoreOS ecosystem is telling a really nice story. We don’t have to build a lot of these pieces that we’re thinking about like fleet management or OS management, or container management, right? So looking at Core Update and Quay as well. 

So I started having chats with the CoreOS team and the sales team at the time. I think the team that pitched me was Alex Bowie, Redbeard, and Jeff Gray. So they sent the heavy hitters and we had a really good chat. I was even more excited. We ended up going with Core Update and Quay at the time and starting to build out our newer platform on top of that. 

So I went to a larger startup after that and did nothing container related. There was a separate team for containers. I was focusing on some bare metal and bare metal integration with AWS, their heavy chef shop, and then not too long afterwards a recruiter reached out to me and the recruiter was pitching CoreOS. They said hey this is what CoreOS is about. We’re trying to change the world, secure the internet, and I was like listen man, you don’t need to pitch me. Let’s do it. I was like I’ve used CoreOS in the past, I know y’all, I love the products you’re working with, let’s do it. So I ended up becoming a field engineer at CoreOS, or a customer success engineer and the morphing into a field engineer soon afterwards, and that’s kind of like my real start in open source because as part of the engagements I was working on, I essentially had to build a large portion of functionality in tectonic, which is their Kubernetes distribution at the time for Azure. A lot couldn’t be easily answered because not too many people were kind of jumping into that at the time. So that led me to actually participating in open source communities like sending some patches for Terraform and then also starting to work in the Kubernetes like Sig meetings. So Sig Docs and Sig Azure were my starting points. 

Cody: So what was your first commit to an open source project? 

Stephen: Huh… I would say if it’s not Terraform, it’s probably something in Kubernetes Kubernetes, which was a typo fix. There’s a typo fix in a docker file that I think was missing a slash or something, right? A slash to do a symlink for a cube aggregator, right? It was something that we packaged in I think hypercube, right? and we were just not packaging it because it was missing that symlink. So I think that was my first contribution for Kubernetes at least. That kind of goes to the power of like don’t discount your contributions, right? Because like a one-line fix in certain places of Kubernetes and certain places of other other projects, online fix can completely break something or completely fix something, right? So don’t be afraid to get started is the lesson there and sometimes like things that you discount as oh this is too simple or this is not valuable enough? Trust me. Someone has missed it or someone hasn’t had the time to get to it, so please send the PR.

Noah: So when was that? How far back was that for you?

Stephen: 2017, 2018 probably? 

Noah: So it’s still comparatively recent.

Stephen: Yes! Yes, very recent and still in I guess in startup years or in open source years and Kubernetes time, it seems like decades ago.

Cody: That’s fair. So I have a bit of a different background. I came up with infrastructure doing Linux server stuff back in the early 2000s, so my story is a little bit different, but I’m wondering… what is your view on how OSS has changed over maybe the last five years? Because from where I’m sitting it’s like leaps and bounds, right? What do you see are the biggest changes that have happened in the last five years or so?

Stephen: Yeah, so I think one of the larger ones is… I also come from an infrastructure background, right? I think from a… I guess from the scale of like, I’ve done like DevOps and SRE stuff too, you kind of look at it as two different sides of the house sometimes, right? I’ve definitely leaned on the opsi side and I felt like I was learning the devie side, so from the perspective of someone who’s doing development on a day-to-day basis, hobbying around, this was something I was scared of, right? This was not my background. I did not feel comfortable in doing software development and it took some time to dip my toes in. Kubernetes was definitely that place where I proved a little bit more of what I was doing. 

So I think at least from the software development side, you see you’re exposed faster. You’re exposed faster because there are components within kind of everything that you do in the day-to-day, right? If it’s a package.json, if it’s a go.mod, or something like that, you’re pulling in all these dependencies that are essentially open source for the most part, right? So I think I gotta hand it to Kubernetes yet again. Kubernetes is like this opportunity where we’re building software for infrastructure, right? And with Kubernetes being one of the, if not the, largest Golang project on the internet and then one of the largest software projects in general in terms of community, it is an opportunity for folks who are kind of like infrastructure leaning to see like, oh that’s something I can do. I can take my skills and apply this here. I think in a lot of things in life, being able to discover your transferable skills and apply them is what takes you to that next level, right? You do something that’s a little bit more uncomfortable and then you find the next uncomfortable thing to do, right? So I gotta hand it to Kubernetes as one of those pivotal shifts in the industry. And then kind of all of the projects within the cloud native ecosystem that have built on top of, or in and around Kubernetes have kind of just led to a lot of infrastructure leaning types going like, this is something I can do too, or this is something that smells like something that I have written in a bash script or something at some point, right? Or I’ve done this in Ansible, right? Or Chef or Puppet, right? And I can probably replicate it here, right? So it’s cool to see more and more of the infrastructure folks spending time in software development and starting to like, and I mean like this is the Kubernetes is not the first to do it, but kind of blurring, starting to blur these lines between what an engineer is, right? There should be no real line, right? You work on what you’re interested in. Ideally you get a chance to work on what you’re interested in and maybe it looks like infrastructure, maybe it looks like an application, who knows, right? But yeah, that is the answer to the question.

Noah: You see that kind of growth and expansion applying in other directions? So I feel like the Kubernetes and the Cloud Native Ecosystem put a lot of effort into making it accessible and making this an environment where people could contribute, where docs was respected just as much as code, and not treated as a second class citizen, do you see that spilling over into other projects and to spilling back into other projects in the Linux Foundation out to like Node or Apache or whoever else in the other arenas?

Stephen: Absolutely and I think a lot of these ecosystems already have quite a bit of the foundation. What I personally love is having the opportunity to… one of the hats that I wear is I’m a co-chair for the CNCF Technical Advisory Group for contributor strategy, right? And what that group focuses on is like how do we build, how do we help people build their projects up, right? How do we help build your contributor ladder? How do you have those discussions about, oh we are stuck on this aspect of our project and we’re looking to pull in more docs leaning folks or our more pxm types, right? How do we do it and having those conversations, right? Because I don’t think that any single one of us has the answer, but it’s so fun to be in the room with a bunch of people sharing ideas. I chat with Miles on the node.js side to get a better idea of what your release process looks like? What kind of things are you running into? When we have all of what’s been happening lately around software supply chain security, that is a huge conversation across the industry, right? Like there is not a week that goes by that I don’t have some conversation, whether it be internal or external with someone, about how we’re gonna get this done, right? So I think that we’re… being able to kind of like on the Kubernetes release manager side, and so one of my hats is also like co-chair for sig release and Kubernetes, and being able to share ideas with other release managers across multiple projects, whether it’s like oh there’s a vulnerability coming up or there is this new project that is… I think one of the recent ones was like oh there’s this new project that is opening issues about potential vulnerabilities in open source projects, right? Are they necessarily handling, like are they opening those issues by following the disclosure process for the project not necessarily, right? So a bunch of open source maintainers are like hey we need to chat about this or you should watch out for this thing coming in and around your repos. So I think in general it’s just great to like if you take something that was closed source, you take something that you’re working on internally, you’re not necessarily able to have those conversations, right? So even in a situation where you don’t feel your voice is authoritative, right? You may need to own that and drive it to completion even if it’s the wrong answer, right? We like to say merge and iterate a lot, right? It’s not so easy when you don’t have the same reviewership pool that you would in an open source project, right? 

Cody: Now Noah said something, mentioned the Linux Foundation and things like that. What’s your take… this may be a little bit of a controversial question, but I feel it needs discussion… What is your take on foundations and their role in the bureaucracy in politics these days?

Stephen: So I believe in them strongly because they have given me the opportunity. Being a part of a project which is within or rather now multiple projects that are within foundations and seeing the level of support for things that I don’t know how to do. Things that people in the projects don’t know how to do. I think that something that I’ve been saying a lot is that I don’t really build infrastructure anymore. I don’t build systems anymore. I build, or rather, I don’t build infrastructure systems anymore. I build people systems, and I think that being able to bootstrap a community off of like the work that people have already done, right, is huge, right? It’s if you think about the devops mentality in general, right? Where people will have a group of devops engineers of course, right? Like no, don’t do that. That’s wrong. Don’t silo devops, right? It’s meant to be a methodology that kind of spreads across your organization. If you think about it in the same vein, what you’re trying to drive after is creating a set of processes and a set of like components that are repeatable, right? And if you look at the, if you forget the infrastructure for a second and you look at the people system, right? These are these foundations. They’re building an ecosystem. They’re building a framework to get work done that is repeatable. That you can replicate from project to project and knowing that’s work that I don’t necessarily have to do, like there’s a playbook for it is invaluable, right? So one of my one of my goals is to always try to contribute to that playbook in some way shape or form, right? So that is that’s my take. I think foundations are great. I think when they are… I think for a smaller project, I think when you’re just getting started and you see… I think it’s very easy to stray too far down a path without formal governance, right? We’ve got things that are cropping up like the Open SSF, right? For security and core infrastructure and sometimes there’s always kind of like a step in the project where they go all, well we’ve gotta step back and think like are there notices up? Like did we actually choose an appropriate license for people to be able to contribute? Do we list who our maintainers are? Do we understand how we are going to route security vulnerabilities? What’s the process for disclosure and how do we get information to people that is visible on how this project is doing? You often have to step back and take developer time or developer time, right, to get that work done, right? So having a framework to say there are some instances where you can there is, like the CNCF template repo I think is what the repo is called, right? Say you wanted to stand up your CNCF project. You wanted to stand up a Netlify website for your project. You can clone that repo and it has most of what you need. You can search and replace words and like boom you have a website, right? So for someone who doesn’t do front-end development, I’m like our website’s not up because I didn’t know how to do a front end! And now I know that I can click a button and get something stood up and write words into it and it’s like human. That’s the kind of value add that you can’t get without having a community behind you. I think that having a foundation backing these communities means a lot.

Cody: It’s a fantastic answer.

Noah: I want to take that in a slightly different direction. So with the importance of foundations and the community and all the collaboration, the physical manifestation of a foundation and of that community tends to be a conference. There’s not really a happy middle ground between a small conference that is just the engineers and contributors and doc writers and just the people who are getting involved. And then when it suddenly explodes and now you’ve got large corporations getting involved.

The long and short of this question is how do we avoid becoming like Nascar where we’re just branded everywhere with corporate logos all over it? Or does that even matter? How do you feel about that presence within the conference instantiation of the community and the foundations?

Stephen: Yeah, so I feel that there’s always going to be a point at which you need more support, right? Whether it’s human hours, people turning away on docs or code. Whether it is to get a project to the next level, right? How do we make it available? How do we brand it, right? How do we ship it, right? Some of that is physical. Some of that is word of mouth, but I think there’s a… I wouldn’t call it really intangible because like we show it by foundations like Linux Foundation or CNCF, right? That Nascar aspect needs to exist. I think that a lot of people worry about the direction that projects can go in when there are too many larger hands on the scale, right? I think you fix that with governance, right? You make sure that people have voices, and you make sure that the voices within your project, and how your project governance is laid out, they’re equally weighted from the foundation level, right? For these… a great example for Kubernetes at least, right? A few years ago, maybe two or three years at this point, Google donated $9 million in GCP credits to allow the project to begin shifting from Google-owned infrastructure to community-owned infrastructure, right? So that spawned the creation of the working group for Kubernetes infra, right? 

Our infra costs…wow like wow… and we have the conversation every year like how much are we spending? Do we need more? How do we get more? Who do we talk to? So on and so forth. Who else wants to put it into this pot, right? So if you think about infrastructure alone for a project the scale of Kubernetes, it does not run without corporate support in some way shape or form, right? So there is… I can often understand some of the arguments around like well it feels like it’s getting kind of businessy, right? Realistically some of these projects do not run without corporate support, right? That’s the nature of this game, right? 

Cody: Now yeah, I think when looking at things like that the hands-off approach is the better approach, right? We can all agree with that, but I have seen it in the past and I think this is pretty common when some large corporation for example let’s just say is running some kind of open source project internally that they’ve now somehow baked it into their process or in their application how things run, but it’s not doing what they want to do, so they here’s our contribution. Can we get these feature requests done? And I think that’s pretty common in our line of work.

Stephen: Yeah yeah and I mean I think we win by discussing how those things will get done and making sure that we discuss it in the open. There are lots of interesting things that have happened recently. You take cluster API and Kubernetes. That’s a great example, right? For you to think through how the core of cluster API works, we have to consider all these use cases from different cloud providers from people who are running on metal, and they don’t take making those decisions lightly, right? I’ve seen questions on the internet about like well why is cluster API still in v1 beta something, right? I think it’s maybe beta 3 beta 4 at this point, right? And it has to do with our API versioning. It has to do with making sure that we are sure that this is going to be as interoperable for as many people who are using this technology as possible. So I think that the way that we win is having these discussions in the open, right? And making sure that again as part of our governance structure things are well balanced. It’s tough. Yeah, it’s tough. I won’t say that like anyone does a perfect job at this, but I think that a lot of the projects in the CNCF landscape do.

Noah: I want to turn that on its ear one more time. So that’s a good perspective on how companies need to be involved because we just can’t really operate without it and how we’re going to keep things in check, but to turn it on its ear from the company’s point of view…

Stephen: …What’s the value…

Noah: …what are the justifications that we’re seeing? Like OSS on the books is always going to be a net loss. We’re throwing engineering resources on it and we’re not making money from it. That in and of itself self-contained in that box is a net loss. But what are the other justifications that teams are using that companies are using to build up these open source program offices, so that they can be able to contribute and be able to become part of that ecosystem and be able to put forth into the community and be able to put resources out there?

Stephen: So I always cringe at hearing like cost center or it being a loss in general. Coming from, and I think y’all are probably similar backgrounds, coming from like the corporate IT background a little bit, you were a loss. My departments have been a loss for the entirety of my career essentially, right? So I don’t like hearing it. It always makes me cringe a little bit. If I can, if I can flip your flip onto the other ear, right? What is the, to y’all, what’s the value of an OSPO? Maybe that’s the question you just asked me.

Noah: I’ll tell you so internally I always justify things here as we do open source because it’s the right thing to do and everything else is going to be a secondary benefit. 

Stephen: Okay.

Noah: But is that common?

Stephen: And Cody?

Cody: Yeah, so I’ve always, I can’t remember who told me this but they told it to me early on in my career and it’s always stuck with me, I think it’s even my byline on my LinkedIn profile, but what they told me was look, if you’re not challenging the status quo, then you’re not innovating. I think that’s exactly what open source does and I think that’s why it’s important because if everybody’s in their own little silos, in their own little boxes, the technology is not going to move as quickly as it has the last decade, right? I think that’s why it’s important because we’re never going to get to that next step unless everybody’s sharing and collaborating together, right? 

Stephen: So consider a project like Kubernetes. Kubernetes is my example, I’m wearing the hoodie. Do we think that Kubernetes would be the same project that it is today if it was still strictly a corporate project? 

Cody: No, because it only fits that certain use case, right? From Google, right? 

Stephen: So for me, I don’t… I am eventually building the idea of an OSPO and OSPO type functions. Do I think, this is kind of also the devopsy thing where it shouldn’t necessarily be concentrated in one place, right? The ethos of your company should be to contribute to open source on all levels, right? Now when you do that, it’s table stakes. It’s no longer like, is this the thing that we should be doing, or okay let’s have these people do it, they are the open source people. No, we’re all open source people. We all should be open source people, right? When you think of internal programs like inner source, right, which is basically the idea of taking open source concepts and shipping them internally, right, in the most naive way of putting it.

What you’re actually requesting that your org does is you’re fostering collaboration. That is legit what it’s about. Fostering collaboration the same way as would happen in an open source project. So why not, instead of building that function, why not have that as a baseline consideration for building your org, right? I know that in a lot of cases like, oh yeah Stephen, let’s just rewrite all the rules of the org as it’s existed for such a long time! But I think there are lots of things to calculate on the human level, right? As a person who has been in kind of an open source org before and is in one now, there is overhead in doing open source for sure. Like on a personal level, I think any open source maintainer will tell you that like the clock doesn’t stop, right? Even if it’s not a requirement of work per se, I think once you become a maintainer, you’re bit by this bug where like that’s your baby. It’s something that you think about on a pretty consistent basis, right? You’re like oh well if I set this PR up right now, then I know when my release managers get in on the EU side they’ll be able to check it out and we’ll be able to have a conversation like sometime in the next day or so, right? So it’s like it’s something that you’re like oh if I just ship this one thing or if I just send this email to set up this introduction for this conference and yada yada, right? What if everyone was thinking about that? Everyone across the org, right? You start diffusing that maintenance burden across the org, right? And the question about like why even bother with open source, Cody you kind of said it, right? It’s that we’re better together. We build cooler stuff together, right? We don’t necessarily know all of the perspectives that need to be shipped in this project or product, right? And having those outside perspectives, having the student who’s hacking on a raspberry pi and discovers this cool thing or this limitation of the system, having someone from academia come in, having a cern work on your project, like all of these things you get to build up these use cases that you never would have had internally, right? That’s a small part of it, and as small as it is, it’s very large, right? I think that’s enough, right? There’s definitely like a karma building aspect of it. We’re not just big corporations coming in to hover over your open source project. We’re here to help. We’re actually doing things to benefit the community. That always needs to be top of mind, right? How can we help? What are we doing to help? And then ultimately you are, it seems intangible, but you end up building a better product. 

Cody: Yeah, I agree. I agree 100%. Just the idea of collaboration in general, I think takes us leaps and bounds. So let me ask you this for companies that are maybe dipping their toes into open source and how they contribute, what are some of the first steps they can take to start implementing a culture of open source? If you had to choose maybe three or two ways to get started for companies, what would you suggest?

Stephen: Take inventory I think is a really important one, right? And that’s part of what I am doing right now. I think my first month in change at this point has been like either Twitter DM, or LinkedIn, or Webex chat, or email of someone saying like, hey can I grab some time on your calendar to chat about foo, bar, baz, right? And when people have asked me like what am I up to, it’s been like I’m kind of looking around in the cupboards, right? Now looking around in the cupboards to see what we got, see what we can make out of it, and see if we need to go to the store for anything, right? That’s kind of what I’ve been throwing out at people. So I think the first thing that you want to do is definitely take inventory, right? 

You’ve probably got a lot of cool things you’re already working on that are kind of like more private spaces. One great place to look is like your, if you have an internal tools engineering team, you have an SRE team, you have… yeah I think those are two big ones, right? Where they’re essentially building tools for collaboration, right, in some way shape or form. So it’s always cool to get the takes of those folks who are like they need to build for… even, let me not say even, but including like corporate IT, right? They’re building shared services for that live for people? That is part of the essence of what we’re trying to do, right? Foster collaboration. Build tools that allow us to collaborate more effectively with people, right? So the first thing. Take inventory. Have conversations with folks. Do not… as part of taking inventory, what you’re trying to do essentially is not reinvent the wheel, right? I guarantee you someone in the org is working on that thing that you’re thinking about. They have something in a private repo or something, or it’s in your company’s GitHub or GitLab instance, or they were just talking to a friend about this and they can point you to some cool project, right? So have lots of conversations. 

Start to build, like I love the idea of inner source, right? And like it feels like it’s relatively newer to me as someone who’s just starting to get deeper on this from a governance perspective, but I think it speaks to, again, what we’re trying to achieve which is collaboration, right? So building one of those programs out in your org. If your org is not used to this, right? The idea where like this product team owns this and that’s it, right? What if this internal tools team was working with a product team, right? What if the front end folks were working with the internal tools folks? All of these questions and all these collaborations that you weren’t thinking of before can really yield some interesting stuff, right? 

Is it necessary… what if some of your engineers had 20% so to speak time on a different team, right? To kind of investigate and think about optimizations between your teams? What is your, how are you delivering software in the first place, right? Do you have something homegrown? Are you using open source software already, right? I think that’s a really interesting one because so many inefficiencies that we see are like the net results of the quality of our build systems. One of the scary parts right now, especially right now with all the chatter about software supply chain security, is who has access to that stuff? What kind of software are we using to validate that what we ship is actually okay across a product team, across multiple BUs, across an entire org? Can you answer that question right now, right? You’ll find that so much more work can be done by having shared platforms, having a high understanding of how your build systems are functioning, right? If that is slowing down and you’re looking at the bottleneck, the bottleneck may be bottlenecked maybe like five engineers maybe it’s less, right? Being able to share that knowledge like that’s a great optimization. Being able to put more people on that and putting something out that is well understood, right? It doesn’t have to be it and it doesn’t have to be your homegrown thing. Maybe it’s Jenkins. Maybe it’s Flux. Maybe it’s name a thing, right? Maybe it’s Argo, right? Name a thing. I think there are opportunities right there to have more collaboration, especially when you take engineers who know how to ship their thing from their laptop, or from container images, they can provide perspective. Something that I’ve been just noodling with recently is that everything is a cell. I feel like y’all have experience here too, right? In selling stuff. So part of my cloud native journey was being a field engineer and I’ve done field engineering work in the past. Part of my cloud native journey was being a field engineer as well as a Solutions Architect at both at CoreOS and Red Hat and VMware via Heptio, right? 

So everything is a cell. Every conversation that you have brings the potential for collaboration, right? I’m not necessarily saying sell in the monetary sense. It’s not always monetary, right? Sometimes it is building a new connection. So what if you thought about open source the same way, right? As a maintainer, I started to think about open source as it’s a cell. Every comment I respond to, every PR I review, every mailing list thing that I respond to, right? All of that stuff is… I’m hoping to help reinforce the values and the qualities of the community, right? And when we as maintainers don’t manage to do that, people are a lot less likely to contribute. 

So think about it the same way and internally, right? What are you doing to reinforce the values of collaboration within your org? Are you doing it today? Is there more you could be doing all, right? So I guess to shortly answer the question now, right, it comes down to like fostering collaboration across the org, right? Trying to delete the silos, right? How do we have more conversations? How do we think about ways of de-duplicating the work that we’re already doing, right? It’s not necessarily open source, but often the answer is someone has already written this and it’s probably available on the internet. 

Noah: Related to this there’s a great question in the Q&A right now. How do you balance the internal product management and the business interest of the org versus the interest of the community? Where do you find that balance? I’ll take a drink. 

Stephen: So thank you, anonymous attendee, that is a great question. So one of my previous hats as well is Emeritus Chair for Sig PM, right? So Sig PM is kind of like the… formerly the product project program management arm of the sig groups within Kubernetes. We developed something called, you may be familiar with it, the Kubernetes Enhancement Proposals

Cody: Oh my goodness.

Stephen: Right. So KEPs eventually became… we eventually shipped them to sig architecture, right? We folded Sig PM and we shipped the enhancement sub project as part of sig architecture. Now the goal here is really again to foster this collaboration, but also do so in a manner that we can eventually introspect on programmatically, right? So that doesn’t answer the question directly, right? The answer to your question is that it’s hard. It’s very hard, but again it’s a sell. Everything you’re doing is selling, right? So if you realize as a company that you need to sell to the community that you’re trying to build a product on top of, just as much as you have to sell to your main customer base, right? I think you’ll start to have a realization, right? 

So something that we have done in the past, or I’ve done on teams in the past or with the guidance of some really awesome program manager shaped people, is a negotiation, right? Negotiation between your teams or your open source teams and the product management side, right? You bring your priorities, we bring our priorities. We figure out how we meet in the middle, right? If you want to ship this cool new feature, this cool new feature is dependent on something that lives in open source. We’re not going to get it done unless you help and we allocate resources to shipping the thing upstream, right? So I think it’s always gonna be a negotiation. We’re never gonna get away from it. One of the most helpful things that I’ve seen is having your PXM types participate in the open source community, right? I was a chair for this thing, I have never worn in title the P something hat, right, at a company. But it’s organization, right? It’s organization, it’s prioritization. Not in any way meant to minimize, right? But I think there is a different mindset that goes into building a roadmap and shipping products than maybe receiving something that you have to deliver for sprint, right? You’ve got two weeks to do it like, here’s the feature that you’re working on go forth, right? I think that as you go up the scale, as you go up the career ladder on the engineering side, I think in general, right, you start thinking like what is my impact? what is my level of influence across… is it this kind of on the intern to mid level or so? You get a set of work and you do the work and you do it well. And then as you kind of move into senior and staff or principal or however your ladders are laid out, the span kind of increases the impact, the expectation of impact increases, right? Whether it’s at the team level, whether it’s at multiple teams, whether it’s across the org, whether it’s across multiple BUs within the org, right? So as you’re working on all these things and open source you’re running PRs, you’re answering issues and stuff like that, how does that map back to, definitely as a senior and higher engineer, you start thinking about like, how does that map back to what my business wants, right? How does that map to my OKRs per se, right? Am I delivering something in an open source that tells the same story for the product team, right? So again, I think it’s part of that thinking both like how am I benefiting the community, as well as how am I benefiting my org. But also having that negotiation, right? You need to bring them into the story and you need to help them. You need to either help them contribute or help them understand why this contribution, right? We need to ship this thing that’s infrastructure related or this API needs to change before we can do XYZ, right? That doesn’t happen until it happens upstream. If you’re building a product on top of an open source project, a lot of things will not happen until you do it upstream, right? So directing effort into getting the upstream work done and having the company support that is paramount.

Noah: So I’m with you on the sale. I’ve continued to espouse that no matter what you are doing in this environment, you’re still selling it. Even if you’re doing it internally, it’s still a sale. You’re just convincing someone to pay with manpower, instead of money, or to pay with their time instead of with money. 

I think there’s an interesting correlation here, though, that all of that mindset, all that continual change of adoption of OSS philosophy, it goes beyond just the interaction of a particular team talking to product management. It sort of manifests itself also in an employee-employer relationship. People are now talking openly about their salaries or how you relate with other companies. It might seem silly, but calling somebody out on Twitter for bad behavior is still a manifestation of this OSS philosophy and this ability to collaborate openly. Where do you see that continuing to grow and where do you see that continuing to manifest in that human to company relationship?

Stephen: So two good friends and mentors Jaice Singer DuMars and Lachlan Evenson have said to me in different ways, on different occasions, that you were beyond your org chart, your company org chart at least, right? When you participate in open source you have an org chart that extends across multiple companies, right? You have different people that you feel or should feel responsible for, or collaborate on a day-to-day basis. I don’t see that changing any time soon. Definitely like where we are in the cloud native space, like you mentioned pay transparency, right? I think that over the past year or so I think people have spent more time being hyped up by their colleagues in the open source community and kind of re-reevaluating their worth, right? I think that’s huge from a very personal level, but I think now that I’ve been doing it for a while, I don’t feel that I… like I am definitely employed by a company, but I don’t feel that I work in any one place, right? My duty is to you all, right? My duty is to the community. My duty is to foster community and it comes with the, again, everything is a cell. Everything that you say, there’s definitely as you become a maintainer, a public persona that you take on. If you’re a maintainer, a speaker at events, a public persona that you take on that may or may not be wildly different from your private persona. I usually let most of me hang out on the internet. I don’t like necessarily compartmentalizing too much of the work and the play, but I think that ultimately from a personal perspective, from an individual contributor perspective, open source is a career changer, right? I would not be speaking to y’all right now, right? If I didn’t jump into Kubernetes, right? I would not be doing some of the things that I am doing right now. I did not imagine this part of my life at this point, right? I didn’t imagine like I’m I guess a fairly popular person in this community at this point and that was not a goal. That was not something I saw happening. I just came in and I wanted to learn and I wanted to work. I think that is seeing folks like in Google Summer Of Code like seeing students come up and just do these incredible things, right? And then having a community behind them, having an org chart, right, that is not even their company yet? They’re at us like they haven’t even gotten out of school yet, right, and you’ve got like a family backing you, right? Ready to like how can we set you up for your next opportunity, how can we help you be successful. I think it’s not just on the student level, it’s everywhere, right? So I think it has an incredible impact for the individual contributor and I think that that said, as a company, you are highly incentivized to take open source seriously, right? Because the contributors that may be doing open source for your company at any one moment don’t need to stay there. What we’re building, what we’re building is there’s a huge fluidity and what you can do, where you can go as a result of building out in the open, right? If you had a bunch of private repos somewhere that was strictly for your company, they’re the only ones who know your work, right? Having it all out in the open and being able to have those discussions you’re like, oh this person reviewed a PR of mine and they were so friendly and like I just had like a really great interaction. Or they responded to me on Slack so on and so forth. You just have like… you create something that is far beyond the scope of a company, right? So I say to companies, take your open source stuff seriously. Treat your open source contributors well because they are not bound to you by in any way, shape, or form. 

I see that we have more in the Q&A.

Noah: We have a couple in the Q&A, we’re pushing up against time, and we still have the rapid fire to get through. So we’re just gonna do rapid fires real fast. We’re gonna skip the one that would have been long and complicated.

Stephen: Oh no! Now I’m curious.

Cody: Noah, you want to take the rapid fire?

Noah: Okay I’ll do it. You’re from New York. Mets or Yankees? 

Stephen: Ooh, I don’t watch baseball. 

Noah: Okay. Yes or no? Pineapple on pizza.

Stephen: Yeah, why not? Sorry Pop.

Noah: Dressy or sweatpants? 

Stephen: Ooh, dressy sweatpants. 

Noah: Okay. Billiards or darts? 

Stephen: Ah, billiards. I’m a billiards person.

Noah: Your favorite non-CNCF project?

Stephen: Wow… Netlify. 

Noah: Okay, I like it. Sig late night or sig sleep?

Stephen: I feel like there’s an eventual conclusion, so say late night first, but then sig sleep.

Noah: Projects or initiatives that you are most proud of?

Stephen: Right now for sure the inclusive naming initiative. That is near and dear to me. Enhancements will always be one of my babies. Sig Release is like family. Cluster API Azure was one of the first large projects that I’ve done and now it’s the basis for like AKS engine on Azure. That’s huge to me. More release stuff rewriting 5,000 plus lines of bash in Go. Our team took that on and we did it in less than a year, but like we said we were complete with by the year, and that has improved our velocity and allowed us to actually collaborate in a really meaningful way that wasn’t just firefighting, so…

Noah: Okay and in the approximately one and a half minutes that we have left before we close out the session, let’s go back to the Q&A. Two questions from the same person, what are good ways to make the engineering teams genuinely excited about working with external communities instead of just following the organization’s open source policy? And can you comment on the difference between selling a product to a company and creating a customer base versus growing a community around a project? Can we do that in one and a half minutes?

Stephen: We’re gonna try something. So I think part of the first question is are you excited about doing less work, right? Creating a team that lives outside, again kind of this like we’re breaking down the walls of your classic org, creating a team that lives outside of your org means that you can collaborate with more people, right? You’re increasing your headcount just by collaborating, right? And not to just look at it in these very like HR type ways, but like that means you can do more. If you know and trust the people that you’re working with on the open source side, that means you can work on more internally, right? So really you’re increasing your velocity. You’re increasing your capacity across sprints.

Can you comment on the difference between selling products of a company and creating a space, growing a product or growing a community around a project… I think one of the biggest parts that you have to realize when you’re jumping into open source is that you don’t necessarily have the… oftentimes as a maintainer you feel like pangs of managerial-ness when it’s really leadership, right? You’re trying to convince people that it’s good to work on something. It makes sense. It’s valuable to the community to work on something. Often when you’re doing it internally, it’s very easy to not say this directly, but say roughly there’s an understanding that there’s a mandate for this team to work on fubar and bass, right? There’s no mandate for anyone to work on anything in open source. You don’t like the project you’re working with? You don’t like the PR’s you’re working on? You don’t have to do them, right? And you would be having a different conversation if you said that internally, right? So I think that’s one of the big differences that you have to like work through as a maintainer, or a commuter, or reviewer, or brewer, that you are not guaranteed any sort of headcount. Someone could write something incredible and they didn’t sign the CLA and then they got swept up in something internally and were never able to come back to it, you don’t get that code, right? So recognizing that there are… it’s opt-in for everything in open source outside of the code of conduct, right? So watching you all…

Okay, thank you very much, Stephen. Thank you for some tremendous time spent with us talking about this issue that is near and dear to my heart, obviously. 

Stephen: Me too.

Noah: Go back to our quick final slides where we will talk about our next upcoming event in the Fireside Chat series. For anyone who wants to come back and join us in about four weeks, we’ll be having another Fireside Chat with our next guest Charity Majors! Super excited to have her on board. We assume this topic will be about observability. If you would like to learn more about us, we have another webinar coming up… if I can stop switching slides… we have another webinar coming up on June 3rd – Hope Is Not A Strategy. If you would like to learn more about your hosts, your inimitable host, StormForge, you can find us on the web at stormforge.io or on Twitter at @stormforgeio.

Thank you all for coming and it has been a pleasure.

Stephen: Thank you for having me!

Noah: Have a wonderful day.