The kubernetes community, being a good corporate citizen in open source, with Dawn Foster

Episode 161 · 49:20 · SRT · archive.org · all Tanzu Talk

Well, you do a lot of, let's say, work in the open source world. That's a very broad way of putting it. You're on, which UK board are you on? I'm on the board of Open UK, which is a nonprofit that's focused on bringing together open technology. So open source, open data, open hardware together in the UK. You know, before we get to our main topic, this reminds me of a question. So you're in the UK, you're, you know, you've been over there a while. What is, and I mean this in a good way, what is the deal with how chatty, like, UK government tech people are about themselves? Like, I often feel like they are the ones who talk the most, like over there in the GDS and other people, like, like, you know, in recent years, like Americans and Australians, I only read English, so I don't know what happens in like Italy, but it seems like the, there's almost like a culture in like UK government tech to talk about yourself a lot. Not, not in a, you know, bad way, but to kind of go over your experiences and document things. Is that a, is that just some weird thing only I see? Or is that, do you think that's an actual conscious effort? No, I think that's, I think there's a lot of truth to that, actually. I think it has, I think it has more to do with the fact that the UK government from, from quite a while ago. So before I moved here, I remember when I worked at, at Puppet, we worked with some people in government digital services, which was the group that at the time was doing a lot of the work in open source. And, and the UK government has embraced like doing all of their stuff in, in the open so that people can actually see it. And so they have this, they have this transparency and they've had that, they've had that for quite a while. And so I think that they really did encourage a lot of people to go out and talk about that because I, I used to see conference presentations all the time about people from the UK government coming out and, and talking about the work that they were doing. Yeah. Yeah. We were both at FOSDOM a couple of weeks ago and I, I just accidentally stumbled into

a presentation from someone from UK.gov talking oddly enough or, or oddly enough from my stumblingness about like Cloud Foundry and Concourse and how they were using it. So yeah, they're, they're, they're just everywhere. It's a, it was exciting. Yeah, absolutely. So, so then also you, uh, uh, you work here at, uh, VMware having been pivotal. So why, why don't you, uh, what do you do around here? Give us a little introduction. Yeah. So I started at pivotal, uh, not quite a year and a half ago. And for the time that, uh, for most of that time, I've been focused on our open source Kubernetes contributor strategy. So I've been looking at, you know, various pivotal product strategies, looking across the whole Kubernetes project and figuring out where it made sense. For, for pivotal to put engineers working on open source Kubernetes. And so a lot of that, a lot of that happened in places like, uh, we, we added some people for cluster API and the cluster life cycle area. We had, uh, people working on API machinery, and then we have people working on more of the infrastructure stuff that benefits everybody. So things like, like release and testing. So we, we actually spent quite a bit of time working in, in release and testing. And so that's what I've been doing at, at pivotal so far. And then we're, we're still in the transition process into, into VMware, but I expect to be doing stuff that's more kind of, uh, more general open source community strategy as we transition into VMware. And then of course, your name is Don Foster. Just, just, just to make sure we, we, you know, had a disembodied voice. Uh, so, so like, like, I definitely want to go back to like, uh, like it's, it's, I've been looking forward to talking with you. Cause we, you know, you can give me kind of a overview of what's the deal with the Kubernetes community. Right. You know, just as far as the landscape of it and, and kind of like how they think and stuff, but, you know, given, given your history, you've worked in, I don't even know, you'll have to tell me what people call this corporate open source, like, like whatever that phrase

is. And, and I wonder like, you know, whether you want to use like Kubernetes as an example or something like when you're, when you're working at a company and helping, you know, manage and input into and making sure they're doing well with open source, like, like, what do you start with as far as like why they care or why they should care? Like what is, what's, how do you connect to what that company wants to do to actually figuring out what, what you should, you know, should be happening in the open source community they're parts of? Okay. That's a really big question. I'll try to break it down a little bit. Um, so, so I have been working in open source for, for more than 20 years. So I actually started using open source when I was a sysadmin back in the nineties. And then when I, when I went to Intel, they were like, Hey, you know, some Unixy stuff, which is kind of like Linux and that's, you know, some open source. So, so here you go. And so since then I have been, that was about 2000, I guess. And since then I've been working almost entirely on open source software within companies. So basically I work at a company and I help them engage with, with open source communities. And that takes a bunch of different forms, right? So my, my approach tends to be a bit more strategic. And so what, what I tend to look at when I, when I join a company and start working on things is what, what is the company trying to achieve? And not just from open source, but what is the company as a whole trying to achieve? What are, what are their goals? And then I try to fit in the bits for, for what we need to do in open source in order to help the company achieve their goals. Because I have, I've learned the hard way that if you don't have really clear justification for the work that you're doing in open source and the work that you're doing within communities, and if you can't tie that back to what the company is trying to achieve, then it's something that's easy to cut, right? They're like, Oh, we don't need to do this open source stuff. I don't know why we're doing this. It's just all, it's all good for the community, but it doesn't benefit us as a company.

So you have to be able to do both. And it's a real, it's a real balance because you can't, you can't just go into these communities, these open source communities, and just selfishly do whatever it is that your company wants you to do, because you're going to be seen as, you're going to be seen as selfish. You're not going to be seen as a good corporate citizen. You also need to do some, you know, you need to do things in a way that the community appreciates. You need to work in, you know, maybe in some other areas to help out. So maybe help out with the contributor experience. Maybe you help out with some docs or some release. And you do this kind of in conjunction with what the, what the company wants. So you have to be able to justify it back to the company, what you're doing, but you also have this balance between what the community needs and doing the, always doing the right thing for the community. So this is one of the things that I stress when I, when I talk to people about our open source participation, when I talk to individual engineers who are contributing in these big, especially these big projects, is that first you have to do what's right for the community. So if the company is asking you to do something that the community doesn't want, doesn't need, doesn't make sense, you can't, you can't just try to push that in, into the community and into the project. You need to, you need to go back and talk to your stakeholders within the company who are asking for this thing and explain to them that we can't do it in this way and talk about alternatives. So this balance between the two is really, really important. Yeah. Both of those aspects are really interesting, especially I haven't really thought so much about the first one, which is, which is you need to make sure the company's involvement in the open source world is sustainable. And one primary way of doing that is proving to the company that they should keep doing it. Right. I always love those. Back when I did strategy work, I went through a few like, I don't know, annoying phases where I finally learned that like part of the job, when you have a job sort of like this is the company hiring you doesn't actually really know specifically what they want you to do.

And they want you to figure that out and then prove it back to them ongoing, which, which like, if you have the wrong, you know, kind of mindset is just like maddening to, to, to be, to be asked to do something and then have the person asking it, not really know what they're asking. And, and, and, and then, and then even more maddening, sort of like tell you that they're wrong if they don't like what you suggest back. Yeah. Welcome to almost every job I have ever had. Exactly. Yeah. But I think, I think that, that aspect is, is, is really interesting. Cause it gets to, you know, one of the, you know, back, back, back when I was way back when at like Red Monk and other places doing consulting as an analyst, like this was in the, uh, the late two thousands, kind of the heyday of like, we should do open source. And, and, uh, you're making me remember that. Yeah. A ton of it was just sort of asking the basic question of like, yeah, but what do you want to do? Right. Like, why, why do you care? And I, and I think, I think there's the easy one. I mean, tell me, it'd be interesting to know, to, to hear if you have some sort of catalog of what people would want to do. I mean, if I feel like the easy one is like, oh yeah, well, we want to make money. Right. So we, we, we'll call it the open core model, which, which can be like, you know, annoying or it could be totally legit. Right. Like we have this, this open source thing and there's stuff that we sell around it, but that's almost like a little too easy. Like, like, like, like the, you know, I, I feel like there must be other more, uh, complicated sort of reasons why people would want to be involved. Yeah. And, and one of the things that's really interesting about doing this is every job, every, every company I've ever worked for and every job I've ever done has been, has been completely different. So, so what an approach that works in one company, isn't necessarily the approach that's going to work in, in another company. And it depends entirely on, on what the company, what the company happens to need.

I mean, when I, when I worked at, at puppet, it was all around, um, you know, kind of the, the open source puppet technology that we were building enterprise products on, on top of. And that was, that was my focus. And I spent a lot of time, honestly, they, they had all kinds of roadblocks for their engineers. They just weren't getting enough done things like, uh, you know, terrible CLA processes and things like that. And I went in and my first, my first few weeks, I just talked to people and everyone I talked to was like, wow, the CLA process is really broken. If you want to fix something, that would be a good one. Um, and so, you know, I spent my first couple of months at puppet working on the, the CLA process, which was just bizarre. Um, when I was at Intel, I did community for, um, for Mego. If anyone remembers that it was an open source mobile operating system that Intel was working on jointly with Nokia as a Linux foundation project. Um, and the stuff that I, I did for that was, it was totally different. It was, you know, it was a little more, um, you know, trying to get people, trying to get people engaged in the community in a different way. And at the time I actually had someone who worked on my team as another community manager, uh, uh, Jeffro, Jeffrey Osier-Mixon, and he was working on Yocto. And even though we worked on the exact same team, he worked, he worked on my team. We did completely different things. Like what we did to grow a community for both of those projects was, was vastly different, even though we worked at the same company and on the same team. Yeah. Uh, and you, you know, another way of slicing it up that, that, that's always interesting is like the, the type of company that's getting involved. So like, I think, I think if you're a software company, that's sort of like, you know, to, to, to maybe make a 90% accurate statement, most open source is software and, and, and is driven by software, but you know, you, there are, you've, you've worked at hardware places, uh, that, that do open source. And I wonder like, what, what's the motivation for like hardware companies to be involved in open source communities? Like what are they, and, and, and it can go both ways, right?

Like, why is a community interested in a hardware company being involved, being involved? Yeah. Yeah. There are a couple, a couple of interesting things there. Um, the first one is that, uh, hardware is, so without software, hardware is a doorstop, right? It just doesn't, it doesn't do anything. Um, so you have to have software that runs, that runs on top of it. The reality is lots of people use open source software. So Linux is absolutely prolific when it comes to lots of different environments, servers, and, you know, all kinds of embedded, all kinds of places. And if your hardware doesn't run screamingly fast and do exactly what it's supposed to do with, uh, when people are running those open source software technologies on top of it, um, then people just aren't going to pick yours. They're going to pick someone else's. They're like, well, this one, this one runs like crap, you know, when I run Linux on it. So I'm going to go, I'm going to go and use this other one that runs really, really well. And the reality is hardware, hardware is difficult because there's a lot of, there's a lot of secret sauce that goes into hardware. And it's really difficult for a lot of people to understand the technologies associated with a particular hardware platform when they're not intimately familiar with it. So the reality is when you work at someplace like, like Intel or AMD or any of these big hardware companies, your engineers understand how your hardware works and how to make it perform better than a lot of other people are going to be able to. So having your engineers embedded in these, um, embedded in these open source communities can really, can really help you basically make the software work well for everybody who's using your hardware. Yeah. I mean, I, I think, I think the, the most obvious thing that, that you put very well is like it, it would, well, the software should run on your hardware and, and, and run well. And, uh, so, so it's, it would be getting to that point. It'd be most beneficial if, if you're by your, I mean, if your hardware programmers actually worked with the community of, uh, whatever software you aren't running on it, whether

it's like Linux or some open source thing or graphic editing or whatever. I mean, it's, uh, I imagine it's going to be a lot better than sort of reverse engineering in either direction or not even reverse engineering. That's, but just sort of like reading the documents and not like, uh, actually talking with people. Yeah. And I think the open source, most open source software communities, certainly the Linux kernel, for example, I think appreciate the work that the hardware vendors put into the software because it's, I mean, it's just, it's just a lot of work and it happens a lot faster. If you have, you know, employees from companies who know what they're doing, working on it, you're just going to get, you're going to get things, you're going to get things into the software faster. It's going to support the new hardware platforms faster. Everything is, uh, hopefully going to be accelerated by having, by having more people who are contributing, who, who understand what the, what the hardware does and what they need from the software. Yeah. It's good to have people who know what they're doing around. Yes, it is. Or who, who know a subject. Do you think there's a distinction between the idiom, know what they're doing and like are knowledgeable of a subject? Cause know what they're doing, at least in the tech world has this sort of judgy implication of awesomeness to it. I guess judgy is always negative. It has this sort of like, you know, they're, they're capable of doing something, not just like knowing something. Yeah, I don't know. I guess the distinction I would make between the two, um, having just come out of finishing my PhD and from, you know, spending a couple of years in academia, as I think of knowledge is something a little more abstract. Like you can know about something and, and maybe understand it and know how to talk about it from an academic sort of standpoint without actually knowing how to use it or what to do with it. That makes sense. Knowing what you're doing feels, feels to me like the people who, uh, you know, beyond just having this abstract knowledge, know how to implement it. So I see like one is like academic, no things. And the other is how do I implement something, um, to use that knowledge.

It's like applied knowing. Well, well, you know, that's a good segue because speaking of things that I think I know about, but can't actually apply that we've got a Kubernetes. So I'm, I'm pretty sure I understand how that works technically, but I would have no idea how to do anything with it. Uh, which, which, uh, is, is thrilling for me. But so how, how long have you been involved in the, the Kubernetes community? I actually started getting involved in the Kubernetes community when I started at Pivotal. So it's, you know, it's been just, just over a year really that I've been kind of involved in, in what's going on with, with Kubernetes. So I'm relatively, relatively new to the community, I guess. Um, but it's, it's an interesting community because it is, it is absolutely massive. So, you know, you, you look at the documentation, you look at the code base, it's just, um, you know, it is a monstrous project. It's like looking at the Linux kernel. There's just a lot of stuff going on. There's a lot of people involved. There are, you know, a whole bunch of special interest groups that are all doing different things. But on the other hand, so like, so yeah, yes, it's massive and overwhelming, but on the other hand, they really spend a lot of time focused on how to onboard new contributors. So we have a whole contributor experience sig that is focused on nothing but improving the contributor experience. So we run the contributor summits at KubeCon the day before KubeCon. Um, and as part of those summits, we have new contributor workshops where we actually get people from, you know, here's, here's my first, first pull request to like getting things, you know, how do I get this pull request merged? How do I write my first bit of Kubernetes code? And then there's also a bunch of other programs. So there's, you know, there are mentoring programs, there are office hours, there are all kinds of things that are really designed to bring new contributors into the fold. Yeah, you know, when I was at FOSDEM in that, in that, I mostly stayed in the, uh, that room you were in, is that, was that the community track?

I forget the name of it. Yeah, the community, community dev room. Yeah, yeah. It was making me realize like how, how, uh, how far the open source world has come as, as far as like what you were just describing. Like all of the, uh, you know, all, all of the, the activities that people used to not talk about that were, are very important for like a thriving community. And there's, there's a tremendous amount more than that than there used to be. Like, I feel like way back when in the, in the two thousands, sort of like, uh, gardening the community meant like at some conference, you would sit at a round table and kind of mumble at each other. But you know, now there's, there's actual, uh, processes put in place and people who are in charge of that. And it's nice. It's like a lot more, uh, it brings a lot more people in and probably has much, much broader results than, uh, just little groups of folks. Yeah. It used to be a lot. It used to be a lot harder. I think the barrier to entry was a lot more difficult, you know, even, even just like 10, 10 years ago, you know, it wasn't, everything wasn't on, on GitHub. It wasn't like, uh, each process had maybe, you know, each project had completely different processes. Most of them, a lot of them didn't even have contributor documentation, like they might have user documentation, but how to contribute, you know, a lot of projects didn't really have that. Um, and, and the process itself was a lot more difficult. You know, if you look at the Linux kernel process, it's, you know, do a patch diff and send it to a mailing list, which is a bit, uh, you know, a bit more, I don't know, daunting, I suppose, than, than a pull request on GitHub. Yeah. Yeah. Yeah. There was another talk earlier in the day that was like, I think it was earlier. That was basically, uh, I'll summarize it. It was, we should stop using IRC for open source things. There were a lot of other points in there, but like it was, uh, it was, you know, it was to that point of like, Hey, these tools used to be cool, but now there's, uh, other people and it's just like, doesn't need to be this difficult, which I think, I think, you know, that, that exact tooling aside, that's always a useful thing in a very complicated system

to always say like, Hey, is there a better way to be doing these things than we've been doing for 20 years? Yeah, this is actually, this is actually something I think about a lot, um, because we, we have an aging problem within a lot of open source projects. So if you look at, you know, I'm approaching 50, uh, if you look at a lot of communities like the Linux kernel community, for example, a lot of the people are my age. We're not that far from retirement and we use tools that create these barriers to entry for, um, you know, younger people. They, they maybe aren't interested in doing patch dips on a mailing list and they might like tools that are a little bit more friendly. So we have a culture of people coming into the workforce who, you know, who don't like email, who just aren't used to kind of the old school tools that we use things like, like IRC. You know, it's just not, it's a, it's a different, different way of working and the, you know, kind of a different, different mindset. And if we aren't willing to kind of evolve and embrace that, this is going to continue to be a problem. And, and what happens when in 10 to 15 years, you know, half the people who work on open source are, are retiring or not working on it anymore. Um, or, or frankly, just like, you know, at that age, people, people die more often, you know, people dying of heart attacks and things. And, and this, this is something I worry about. I worry about the aging problem in, in open source. Yeah. Well, you know, we'll, we'll get maybe back to Kubernetes, but since, since you mentioned you worrying about that, like what, what's your, what's your deal with all of this open source stuff? Why do you, uh, why do you care enough to do it as your job? Yeah, I, uh, I absolutely love it. So it was something, like I said, I sort of got accidentally involved in it at Intel. And at some point I realized that, um, I was, I was meeting all of these really amazing people all over the world. And I've developed really deep friendships with some of these people that I've interacted with mostly, mostly online and at conferences.

And I'm at the point now where I can, I can travel to almost anywhere in the world and find someone to get together and have coffee with, because I, you know, I know all of these, all these really amazing people. Like, you know, I, I grew up on a farm in Ohio, um, where there was no money. And like, if you had told 14 year old me that some company was going to pay me and fly me around the world, um, to do this really amazing job, I, I would have been like, that's not a job. I don't know what you're talking about. Um, that doesn't happen. Uh, and you know, and I really, I, I spend a fair amount of time like reflecting on this, like, you know, that, that I am incredibly fortunate to have met the people that I've met to be working in the space that I'm working in. And I continued. So when I was, you know, I kind of dropped out of, of work for a couple of years while I got my PhD, I still did some minor consulting and things, but I continued to go to all the open source conferences because all my friends are there and I really like it and it's fun. And I, I enjoy it. So, you know, I paid to set myself to a bunch of conferences because I, because I like it because I enjoy it. It's fun. And, and by working at different companies on different projects, I get to do lots of different things. So it doesn't, it doesn't get boring because every, every time I do this is different. So, you know, at pivotal is one thing. And as we're transitioning into VMware, it looks like I'm going to get to do something a little bit different. So it's, it's always this, this constant, constant change and constant evolution. But it's still, it's still a lot of the same people. And I'm always, I'm always amazed by how many people I ran into when I joined a new project. So, you know, I started getting involved in Kubernetes and I was like, oh, there's George Castro. I remember him from like config management stuff back in the day. Oh, and there's Janice Roseland. We worked together on some, some puppet stuff that he was working on when he was at EMC. And so there, there were this whole, you know, set of people, you know, Josh Burgess, I know him from other things. So there are all these people that I knew from sort of past lives in these new communities that, that I joined. So you keep running into the same people and you, you build these, you know, these great

friendships with people. And it's really, it's really an exciting space to work in. I love it. Yeah. Yeah. That's a, that's a, that's an interesting explanation because it's purely like to keep using this word, like it's a nice community to be in. Which, which, you know, people will say that about companies that they work for, which, which can also be nice, but then also like a company is nice. Cause you get a paycheck, right. Versus, versus like sticking to a group of P of, you know, a professional community. I don't know. There's, there's weird phrases for this kind of stuff, but like for, for its own right and being kind of rewarding to be involved in is, is it's nice as well. I guess maybe like, like neighborhood sports teams can be a bit like that too. I, I don't know. Well, so, so, so then back to the Kubernetes stuff. So like one thing, one thing I, I, in thinking about talking, I was interested in hearing is like, so how would you describe like what the Kubernetes community like wants, like what's it's desire, right? As far as like the different people it would work with. And like, I don't know, like, how does it want the world to like interact with it? I, I, I hesitate to use the word mission, right? But like, but like, but like if, if, if I was just like a random, not random, if I was a highly selected, awesome, like developer or like an operations person, or even like, I don't know, vice president of some interesting IT thing, like, and, and I go to like a Kubernetes EBC, like what does Kubernetes want me to do with it? Yeah, that's a, that's a really hard question. I'm not, I'm not sure that I can, I'm not sure that I can answer it fully, but I would say that the thing that, that, well, the thing that I see is that what we really want is for, for Kubernetes just become this sort of ubiquitous layer that we build on top of the sort of infrastructure layer that you can, you know, all these different technologies

can build on top of, of the same, the same layer that is, is Kubernetes. So the idea would be that, you know, you can, you can use just, you know, the, the Google stuff, you know, you can use the Google cloud. You can use the Amazon cloud. You can use the, you know, some of the VMware technologies and all of these, all of these could run on top of this sort of common, common infrastructure platform. And so I, you know, I think it's kind of, I mean, I sort of think of it as sort of analogous to like the, like the Linux kernel. So like all the, all the Linux operating systems, and it's gotten to the point where almost all of the operating systems, you know, full stop, at least on the server side run on top of this Linux kernel. And so I see it as, as trying to become sort of this ubiquitous, ubiquitous layer. With that, there's an awful lot of work that has to go in around it because it's, Kubernetes is, has a lot of really amazing potential. I would say that we're still working on what I would call sort of enterprise maturity. So like, you know, there's still, they're working really hard on cluster life cycle. So cluster API and being able to, you know, really robustly manage your, the whole life cycle of your clusters, the upgrades, you know, everything and be able to do that in a way that, that enterprises see as, as reliable. The APIs are also a big focus right now so that lots and lots of different companies can build on top of Kubernetes using this robust kind of, kind of API layer, you know, kind of what they're working on within the API machinery sake and others as well. I mean, it's, there's, there's still a lot of work going on to make this really robust for, for engineering and, you know, kind of enterprise needs. Yeah. Yeah. I mean, I mean, I think ubiquity seems like a good way of summarizing it. You're also reminding me that like, as, as I've been trying to be more knowledgeable, speaking of knowledgeableness, like, like about Kubernetes, I've been

realizing, I don't know, tell me if there's a name for this, that, that y'all in the Kubernetes community have, but there's like an implied, uh, system architecture and application architecture that like, it would be really cool if you followed, if you want to run on top of Kubernetes. Now, as, as, uh, one of my coworkers, Paul's likes, Paul likes to say, you know, you can put any garbage you want in a container. And, and, and that, that will be supported. I think you can put garbage in any type of container, real or metaphoric containers or anyways, but, uh, but like, for, for example, like there is like, like if, you know, the, the, the way that, uh, uh, Kubernetes will want to like, you know, pull out your configuration and have you put your containers in a pod and kind of group them together and things that are, they're situated with each other and describe, uh, their, what their healthiness is and how many replicas that you want, like all of these sorts of things that Kubernetes can do. It sort of has this implication of like, and this is the type of architecture your application should have. And then also this also implies that like, if you're an operations person, like here are the things you worry about. Right. And it's, it's, I feel like, like as I'm, as I'm listening to myself going over this, like there's almost like this book that I'm always missing. That's sort of like the Kubernetes way of thinking about your data center, right? Like how, how it is one, we want operations people to think about what they, what they're doing and what their jobs are. But then the one that's always really elusive is like, so then what are developers supposed to do? Like, how does this mean that they architect their applications and like, I mean, you mean all this stuff. And, and, you know, just as an example, right? Like in theory, if you were doing like Java enterprise development or Ruby on rails development, or I'm sure nowadays reactive development, like those sort of are open-ended, but they also sort of imply a way of doing your software that you should follow to take advantage of

them. Yeah. And I would say, to be honest, like I, I feel like this isn't something you're missing. I feel like it's something that's still evolving. So I think that the Kubernetes community is still in the process. of figuring out like the Kubernetes way to do things. Yeah, there you go. And I think we're certainly converging on a, on a few things, right? So there's been a big focus on APIs so that people are using this kind of like the same layer to, to build on top of. And, you know, there's a lot of traction around things like the, the CRDs, the custom resource definitions and building operators to, to do a lot of the, the work on top of Kubernetes. And so I feel like they're converging around some of those technologies, but I feel like it's been, you know, it's, it's been an ongoing evolution. And as, as the technologies mature and get better, you know, we continue to improve them and continue to find new and better ways of, of doing things. And so I think this is a symptom of it still being, you know, a little bit, a little bit immature from an enterprise standpoint. It, it just, Kubernetes hasn't been around like, you know, like some of the other things that you mentioned, you know, like Java has been around for ages and it's sort of stabilized. People know exactly how to use it. And there aren't a lot of changes. And Kubernetes is still, you know, it's still evolving. It's still growing. It's still maturing. So do you think that like, and I don't mean this in as silly as it sounds, but do you think that like books are still valuable in, in, in this space? And, and I say that cause like over the years, I've always suggesting like, you know, what we should do is like, we should make a book where we write all of this stuff down. And then people often will be like, oh, we've got these articles published here and we've got this here. And, and I always think they're like, yeah, but if you had a book that has like the beginning and the middle and the end, you could like read it and then know, like, now I know how to write software for Kubernetes. I mean, just to pick that example, but I, I don't know if people use books anymore like that. It's always a mystery to me.

Yeah. I think it's, I think it would be, I think it's really hard because the technology evolves so quickly that anything that you wrote might be in danger of being out of date by the time you actually got through the, the publishing process because the publishing process is slow. Yes. Whereas, you know, blogging, podcasting, you get the information out there right away and it's still fresh. So I think, you know, I think there are people that would like to have a book that does that, but I think that the shelf life of that book would be quite short. Yeah. You'd have to update it all the time. Yeah. It would just be out of date so incredibly quickly. Yeah. So, so then, so then also related to that. So, well, you know, we could start with like the Kubernetes community, but like communities in general nowadays, and we've alluded to this, this a little while, but like, so there's the role of the developer in a community, but there's a lot of other roles and, and, and things, things for people to do. Like, what are, what are, what are those other roles that isn't necessarily just like writing code or even being like a lead on, on writing code? What, what other things that people do? Oh yeah, absolutely. So, so there are lots of important things that aren't, aren't strictly development. There are ones that people tend to think of. So like documentation, you know, good tech writers, that's, that's a real skill. That's a technical skill that has to happen that not, not all engineers are great at writing things in a way that can be easily understood by lots of people. So, you know, having really good tech writers and documentation, I think is, is really important. And that's something that anyone can contribute to. So like, even as you're brand new to a community, you start to step in and you're going through the documentation and getting things installed. You'll look at things from a new perspective and you'll notice mistakes. You'll, you'll see things that could be clearer. And so that's a really good way to contribute. Um, one of the other things that I think is also probably under, uh, underutilized in a lot of communities because developers are really busy, but mentoring, mentoring is really important

and bringing on the next wave of, of developers. But the problem is you have these really busy developers who are barely keeping up, uh, or not keeping up as it is. And then you're asking them to mentor someone, which takes even more time. So it's, it's a little chicken eggy, um, but it's, but it's important. Um, there's lots of promotion and, and marketing stuff that goes in around open source projects and, you know, just communicating all sorts of things like, you know, changes that are made in the latest release, for example, um, the release process itself is not really a developer task, but it's more of a, more of a process program management task. Um, and the release process within Kubernetes is actually really interesting because they, we do frequent releases and they form a new release team for every single release. And they have leads for, I think almost a dozen different things like enhancements and, um, you know, patches and like all, all kinds of stuff. They have different, different leads for different areas. And each of those leads has a shadow. Or actually usually multiple shadows. So these are people who are basically shadowing the person and learning what it's like to lead this area with the idea that they would eventually, if, you know, if it goes well, lead, lead that area in a future release. So we've actually had a couple of those, um, release leads from, from Pivotal, for example, in the past. And it's a great way to get kind of engaged with the entire process. So like the, you know, being able to do these releases, this is another thing that you need people who aren't necessarily developers for. And then there's all sorts of like infrastructure operations stuff. So there's a whole like Kate's infra working group within Kubernetes. And these are the people that sort of keep everything running. So they administer GitHub. They, you know, they work on like, you know, testing infrastructure and all of the stuff that needs to happen for, you know, for a project like Kubernetes to even, even run. And those tend to be more, you know, less on the developer side and more on the operation

side. And then there's also lots of community tasks. So like moderation, you know, on Slack, like kicking out the person who's spamming people and, um, you know, moderating mailing list posts and discussion forums and bug triage and all, all kinds of things that aren't necessarily developers that, that there's just work that needs to happen in these open source communities like Kubernetes. So it's basically a software company. It is. It is basically a software company. Totally. All the similar roles. And that's actually not a bad way to think about it. Like anything that you would need for your company to release a software package or release a software solution under any other license, you need to do all of those things for open source projects. That doesn't just, it doesn't just magically happen. You need to know who actually do those. You can't, you can't just put your stuff up on GitHub and then you're done. No, no matter how awesome the, the, the actual code might be or terrible or middling or whatever. Yep. Yeah. Well, so you, so, so finally, I think, uh, uh, let's see. KubeCon Europe is in the beginning of March. If I remember, is that no, at the end of March, the end of March. That's right. That's right. And, uh, so you have a, you have a talk coming up there about being a, uh, like a good corporate citizen in, in the Kubernetes world. Like what, uh, yeah, give us kind of a summary of that. Like what is, what does that, first of all, what does that mean to be a corporate citizen? Yeah, absolutely. So the way I think of being a corporate citizen in open source projects is, again, it's this difficult balance between doing the right thing for your company and keeping your job and doing the right thing for the community and, and walking this, this fine line between community and, and company. And so this is, this is something that's, it's always a little bit difficult. It can be a little bit tricky, but what, you know, it's, it's basically what I'm going

to talk about are ways that you can, ways that you can walk that line, ways that you can do things that make your company happy, you know, like, you know, working on some features that, you know, I don't know your company needs because they're building something on top of Kubernetes and maybe there's some, you know, APIs that they need to perform better. Maybe you're working on some specific scalability issues or some specific performance issues. And you can justify that back to what the company wants, but at the same time, you also need to be doing things for the, for the community and, and representing your company in a, in a good light. So, you know, being, being kind to people and working with people in ways that make people continue to want to work with you and continue to have respect for the company that you're that you, that you work for. And so doing things in a way that, that makes sense for the community and that makes the community stronger. And sometimes that also involves doing some other things like, you know, helping out with docs occasionally, or maybe helping out with some infrastructure things or doing some presentations to help promote some specific part of the project. There's, there's lots of things that, that you could do to help improve the, improve the community while at the same time, also working on the stuff that your, your company is, you know, realistically kind of paying you to do. Hmm. Yeah. It seems like, at least in the way I would think about it, there's, there's, as a corporate citizen, there's some analysis you could do about like the, the stuff we think would be good and helpful. And, and then, and then the second thing out of three is like the stuff that like the community thinks would be good and helpful. And then there's this third bucket of, of like, I guess there's the stuff that doesn't overlap and, and kind of what you're saying is like sometimes to contribute back, like you just go do these other things that may be not like perfectly aligned to whatever your quarterly MBOs or whatever nonsense you use are, but it may not be directly related to, to the, the corporate-y stuff that you have, but it's something that like you should spend the time to, in the other meaning of this, do some community work, right?

Like help go pick up some litter and, you know, think things like that to, to contribute back. And, and I, and I think, I think, you know, you're making me think that like part of that analysis is that like, if we're going to be part of this community, like we need to just make sure it's good in general. So like, we don't know, we don't only, we don't only have like our, our, you know, mercenary interests that we go in and do things like make sure that some exotic storage device is supported on this infrastructure. But we also just want to make sure that, you know, if this community is doing well, we'll be doing well because we depend on it, it running well. So we should go like moderate some comments or, or, or like spend time to go to present on something. Yeah. Yeah. And the other, the other thing to think about too, is that open source projects tend to be they're, they're built on reputation, right? So, so I come into a community and if I, you know, if I'm not doing things in the right way, people, people won't have this, won't have respect for me. And I won't, I won't be able to build the reputation that I need to build. And, and it's not like, it's not like working at a company where you can be like, that guy's a jerk and I'm going to go talk to his manager or HR and, you know, I'm going to, I'm going to fix this because they're open source communities. You don't, you don't really have that. It involves a lot of negotiation and involves a lot of, a lot of using your reputation for stuff. And, you know, initially when you first start in a community, you almost kind of have to start with like stuff that, that you don't care that much about, not, not that you don't care about, but isn't, isn't necessarily important to your company, but things that you're good at. So, you know, documentation or maybe release process or some things where you can sort of get your foot in the door and learn how things work in a way that's going to make it easier for your company to get stuff and, you know, included later because the, you know, the reality is like now I know lots of people within the, within the Kubernetes community. And if nobody's responding to my pull request, I know people that I can escalate things to. I know people that I can talk to and get reviews from.

And, and you learn how to work within the community by using, by using your reputation and by knowing who to talk to and knowing what the channels are and that takes time to build. So the other mistake I see companies making is that they, you know, they pull people in and off of these projects, these open source projects. And that's not the way, that's not the way this works. People, people tend to work within open source communities for periods measured in, in years, not, you know, I need to get this one feature in this one project. And I'm just going to, I'm just going to do this little thing and then I'm going to bug out and do something else. So it's, it's, yeah, this whole like reputation and longevity involved in these communities is really important. Yeah. You know, it seems like over the years, like corporate people or, you know, corporate interests involved in open source. One, one of the things that's often an attribute of successful ones is the longevity, longevity, they're involved a long time. And, and they, they have this assumption that like, you know, we're going to, we're going to commit to being involved in this and, and have, have these, these people working on it. And, you know, I, I think, I think on the corporate side, especially in, in software related stuff, whatever you may be doing, the, the temptation is always to like borrow those people's time to work on something else. And so it's, it's always, you have to be very mindful of as, as a company, if you have like people working on software across all the roles that like, you know, you can't like really just like borrow them. They need to focus on that thing. And I imagine in a corporate context, it's really easy to, to forget that. Cause you know, you constantly feel like your hair's on fire to go chase like a business opportunities, but with, with that long-term commitment, you'll hopefully be more disciplined to not mess that up. Yeah. And the other things, the other thing that companies can do related to this is that, you know, we were talking about the kind of the, the problem of getting, getting new contributors and getting people involved in the communities and, you know, kind of the aging out problem

that I was talking about before. But the other thing that companies can do is once you get a few people who are embedded in the community, who know what's going on, you can use your internal engineers to help mentor new people, to bring new people into the community from, from your company. So bringing in, you know, kind of the next wave of open source developers is something that, you know, I also think that companies should be, should be doing more of and not relying so much on just the community to mentor, you know, people into the project, but also companies can take some of this and it benefits, it benefits the company because they're, you know, getting more people involved in a way that, you know, makes them look good, but it, you know, it benefits the community as well because they're getting lots of, you know, new contributors. Yeah. Yeah. Well, well, great. That's good. You know, you know, one is probably obvious to yourself and other people, but like, I think, I think, I think one of the major things that, that that's come out of this discussion is like the open source community itself has to do a lot of managing itself, right? Like there's not, you can't, you can't, you can't just rely on some, you know, chatter here and there on a mailing list and kind of figuring out like technically what needs to happen, but there's a lot of, uh, we need to, we need to sit around and decide how we're going to manage the overall community and the processes in it. And like, what are we going to do this year? And the year after that, and how do we just like a software company, right? Like someone, some people have to sit down at a software company and figure out the strategy and what that implies for operations and all sorts of things like that. Yeah, absolutely. And then there's just like the day-to-day stuff. Like there's just massive amounts of pull requests that, you know, somebody needs to review bugs that are filed. It's, um, open source projects are, are frankly, it's, it's a lot of work. And, you know, Kubernetes, one of the things that they've done is they, they have a lot of automation. So, so they have all this stuff like built into GitHub that kind of, uh, automates a lot of the sort of mundane tasks. Um, but even, even with that, the people who are, you know, reviewers, approvers, kind of owners of certain chunks of code are still incredibly overloaded and, and need help.

So it's, it's one of those things like you can, you can automate so much of it, but you know, at the end of the day, somebody still has to review it and give it the thumbs up. Yeah. You need a lot of community reliability engineering, make sure, make sure you automate all that stuff. Well, good. Well, well, thanks for being on is, is, is fun to, uh, go over all this stuff. Is there, uh, if people wanted to like check out more stuff that you have, where, where would you point them? Uh, yeah. So if you want to learn more about me, you can go to my blog, which is called fastwonderblog.com. Or if you, if you Google Don Foster and, and something related to tech, you'll get me instead of the Don Foster that works at the Guardian, which is my, my name nemesis. I used to be first in the Google results. I don't think I am anymore. Yeah. Yeah. I w I w when I was looking around earlier, I was wondering why you were involved in so many Brexit conversations. Yes. That one's not me. It was less confusing before I moved to the UK. Exactly. It got more confusing after, after that. So, you know, that reminds me over the years, I've always wondered. So when it comes to fast wonder, does that mean that it's quick to have wonderment or that it's a fleeting amount of wonderment? Uh, here's the funny thing. Uh, it's an anagram of my name. Oh, even better. I sat down and I was like, how can I rearrange the letters of my name to come up with something because I need a domain name and I'm not, I'm not that creative. Well, you, you don't suffer from that problem that I have where like every, every few weeks I have to decide if I want to renew one of my like, you know, tens or a hundred or so domain names where I just, uh, Oh yes, I do. I just, I, I have them on auto renew. I pay way too much for crap that I'm never going to use. Yeah. Yeah. Yeah. You, you might be like me where like when, when, when I, when there were first domain names, they were so scarce, like they would, they used to be like 70 or a hundred dollars and it just seemed like such a, such a precious commodity. And then, and then once I had the ability to actually like just register them chiefly, like I felt like I was, uh, benefiting from it, but really I just create more expense and

problems for myself. There's no benefit. I have some, some ridiculous random idea and I'm like, I should buy a domain name. Yeah. So I buy all these domain names and then never do anything with them. Yeah. Well, speaking of, we should go check up on those, see, see, see how they're doing. All right. Well, well, uh, well with that, this has been a, uh, I think, I think probably when this comes out, we'll still call it a pivotal conversation. Speaking of naming, I think, I think when, whenever we get around to it, we'll actually call it Tansu talk, which I think will be fine. And always, every time I say that it's going to remind me of UHF where they had town talk, uh, and, and, you know, spatula city. Uh, but if, if you want to, um, get, get the show notes for this and other things, if you go to pivotal.io slash podcast and some future magical address that says Tansu in it, uh, then you can go there. But with that, we'll see everyone next time. Bye-bye.

Tanzu Talk · 🍕 Get more pizza.