Kube Cuddle

Repost: Carolyn Van Slyck

Rich: Hi, this is Rich. Shortly after KubeCon Amsterdam we received the news that Carolyn Van Slyke had died. Carolyn was a well-loved member of the Kubernetes and Go communities, a Kubernetes contributor, and one of the maintainers of the Porter project. Back in the early days of Kube Cuddle, I wanted to speak to someone about the realities of working in open source, and I interviewed Carolyn in April of 2021.

We spoke about her love of open source, how Microsoft had changed as a company, and everyone's favorite topic, Git UX. I want to pop this back into people's feeds for newer listeners who might have missed our conversation, and friends of Carolyn who miss hearing her voice. I hope you enjoy it. There's also a great memorial to Carolyn on GitHub and I'll link to that in the show notes.

Okay. Let's go to my interview with Carolyn.

[Original transcript follows]

Rich Burroughs: [00:00:00] Hello! Welcome to Kube Cuddle, a podcast about Kubernetes and the people who build it and use it. I'm your host Rich Burroughs.
I'm excited to be speaking with Carolyn Van Slyck today. Carolyn is a principal software engineer at Microsoft. She works on Porter and the SIG Contributor Strategy group. Welcome Carolyn.

Carolyn Van Slyck: [00:00:34] Hi, thanks for having me. I'm so excited to be here.

Rich Burroughs: [00:00:37] Yeah, you bet. I'm really happy to have you. You've got a very interesting background and you're working on things that I think are super relevant to the listeners. So, yeah. Tell me a little bit about how you got started off in computing.

Carolyn Van Slyck: [00:00:49] Yeah. When I was in high school, I had a TI-83. Right. And I used it aggressively to avoid ever amortizing a mortgage or, calculating a saddle shape or anything like that. So I was programming it really heavily, but I didn't think of it as programming. I just was being lazy and expedient. And my math teacher saw this and she's like, did you know, this is the thing I didn't really know. So she sent me to a computer programming course at the high school.

Rich Burroughs: [00:01:20] Oh wow.

Carolyn Van Slyck: [00:01:21] And I really. I really liked it. It just fit in with my worldview of, I like to make patterns out of chaos.

So it felt good. Yeah. And that's, I just pick that and I'm like, this is what I do previously. I thought I was going to be a veterinarian and uh, yeah. Big switch there. No, human interaction, no animal interactions. Just be in the keyboard.

Rich Burroughs: [00:01:41] I was going to be a newspaper reporter and an actor and a bunch of other stuff. And I'm not even counting the early childhood aspirations.

Carolyn Van Slyck: [00:01:50] Yes.

Rich Burroughs: [00:01:51] So what is it that brought you into doing this stuff professionally? What did your path look like?
Carolyn Van Slyck: [00:01:55] I went to community college because there was no way I could handle living in a dorm. I like refused right off the bat. I'm like, that's not me. So I did community college for two years and then went to the university of Illinois in Champaign-Urbana. And because I really loved what they were doing at the graduate level, which to be honest, it's very different from what an undergrad looks like. So a little bait and switch there, but I still really enjoyed what I was doing.

I probably spent more time out of class programming and doing things with computers than I ever did as part of the school curriculum. Sorry U of I. But I enjoyed it so much and I walked through a career fair one day and saw a table that said Microsoft. And I decided to be goof because like no way they would hire me.

And so I went up there and it just kind of like, was a goof and said silly things I probably shouldn't have said to Microsoft about my love of Linux.

Rich Burroughs: [00:02:49] Oh my God.

Carolyn Van Slyck: [00:02:50] Oh yeah. I know. I was baiting them, uh. No and they gave me an internship instead. So like this right off the bat, it seemed to work out. It was very much pure luck. I don't, if that had happened, I don't know what my path would have been.

Rich Burroughs: [00:03:04] And what about the cloud native Kubernetes stuff? What got you into that?

Carolyn Van Slyck: [00:03:09] So I had done just the standard closed source, you know, implement something to get a line of business out.

Rich Burroughs: [00:03:15] Yeah.

Carolyn Van Slyck: [00:03:16] Out the door, everyone loves those. And I wanted to try something different and I was really interested in doing builds and developer tooling and things like that. I knew that's where I liked spending my time. So I had an opportunity to work with Jesse Noller at Rackspace and they were building a product called Carina
I don't think it exists anymore, to be honest, but it was Kubernetes as a service before that was really a thing. This was late 2015. And I just fell in love with it. I, when I started, I didn't know what a Docker container was. I was kind of like new to everything. I didn't know, Go. And then give me a year and a half of that. And I was like more, this is what I want to do.

Rich Burroughs: [00:03:59] That's amazing. So you mentioned your early stint at Microsoft, and I was looking at your background and noticed that. And I was curious because, I'm one of those people who, in the nineties, I was always railing against how evil Microsoft was and, so you were there in like the early two thousands and now you're back. I'm wondering, like, what's the contrast between that first Microsoft and the one you're at now.

Carolyn Van Slyck: [00:04:25] There are women developers, there are black developers. There are people from all over the world in different cultures. When I went there the first time, um, cause I did two internships and then I worked there for awhile after I graduated. I never met a single woman who was a developer and that's all I wanted to do. That's all I wanted to be. Uh, they honestly wouldn't even hire me as a developer. There were problems with that. So I was a PM, but all I did was write code for them. So, yeah. Yeah, it's, it was totally different though. It was all the things people say it was to be honest.

Rich Burroughs: [00:05:03] Yeah. It's interesting that you mentioned there not being women around because You know, I started off in the mid nineties. I worked at an internet provider and then, you know, at some other companies and I went through like 15 years of my career, at least before I really started working around many women who were in technical roles, it was always, they were HR or they were, you know, product or project managers maybe sales or marketing, but, but they were almost never writing code.

And if they were, they were, maybe a junior engineer doing bug fixes or something like that, you know, and for me, it was when I went to Puppet and worked there that, that was the first time when I was really around a lot of women engineers and had the opportunity to realize that the things they say about diversity really are true.

That it's not, it's not just about, you know, fulfilling some sort of, quota or something like that, but it really, it makes a different kind of workplace, when it's not just a bunch of white dudes sitting around.

Carolyn Van Slyck: [00:06:04] It, it's, it's hard when it's a monoculture it's even more difficult when you can't see a single example of someone like you during the job, you know? That's why I got involved in a couple of different programs, like Women Who Go, which is for the Go programming language or Write Speak Code, um, which is about getting gender minorities into tech, either through, uh, speaking at conferences doing presentations at meetups, running meetups, uh, doing community work, writing, open source code, blogging, things like that. Someone helped me even see that it was an option to do something different. And I wanted to like immediately pay that back because while I don't see myself as a role model, at least I'm out there doing this and like that that's gotta be the bar. That's gotta be good enough. Good enough right now. I'm really excited for people these days who are on Twitter immediately. They find the back channels to be honest, and they get to really meet more people and they get to ask more of their role models and think bigger ideas and thoughts about what they can do.

Rich Burroughs: [00:07:12] I mean, the representation part is so important. And I think that, you know, you don't necessarily, even if you don't think of yourself as a role model, like you said, you're out there and I'm sure that people see your work, and that's, that's the important part. So yeah.

Carolyn Van Slyck: [00:07:27] If people just enjoy working with me. I I'm, I'm pretty happy about that. That's really what I'm looking for, but I don't think it's genius level execution that's for sure.

Rich Burroughs: [00:07:37] Yeah I think so much of that stuff is a myth. I've worked around very few people in my career that I would call geniuses very, very small number and I've worked with a lot of people. Yeah. Yeah. Um, so like you said , you're at Microsoft, your job now is working on open source. How amazing is that to actually have that be your full-time job that people pay you money for?

Carolyn Van Slyck: [00:08:01] I love it. I really do. It's I feel like there's a lot of, of a disconnect between what people think it will be. It seems like a, like a path to 10,000 followers and easy job offers. And I don't know, being friends with like cool people who, uh, you know, say honk on the internet.

Right. Um, and I don't, I don't think it actually is that at all, but I think it is incredibly empowering from the standpoint of saying, I'm more distinct from my employer. The people I work with, if I change employers are still people who matter in my network beyond just the next job recommendation. I'm still working with them.

If I switched from one company to another, if I'm still working on Kubernetes or if I'm still in the CNCF ecosystem, those relationships still matter. Cause I'm, you know, that's probably the only consistency I have sometimes in like when you switch. And I think that's really powerful and you get a chance to work with. leet think some of the people who have. The right idea about how to attack life and technology and what we're trying to do. Uh, because I found that in the Kubernetes ecosystem, especially people are extremely focused on fostering a healthy, inclusive community and not just lead code or, oh, gosh, whatever you want to call it.

So I, I value the relationships I've made in open source so much, almost more than the license. To be honest though, like, I'm always curious, I always want to see the code, right? So I enjoy writing open-source code. But it's almost the people more than anything else, why I'm still doing this.

Rich Burroughs: [00:09:44] It's such a great community. And, I've had this discussion a little bit with, uh, previous guests, about that independence you're talking about. And I think it's really powerful, you know, um, the, the first place that I started seeing that in my career, and it didn't impact me personally, but I saw, other people who were working on OpenStack.

Carolyn Van Slyck: [00:10:05] Yeah.

Rich Burroughs: [00:10:05] And you could move from one OpenStack vendor to another one and keep working on the same exact stuff that you'd been working on at a whole new company. And that just kind of blew my mind, you know? And I, I feel like there's, it's sort of like an extra level of job security, right?

Because if for some reason you're stuck on a team that you don't like or the, the company environment changes for some reason. And that happens, um, Uh, you could move somewhere else and keep doing the exact same work that you're doing.

Carolyn Van Slyck: [00:10:34] Yeah. That's the job security. I feel like it's, it's there at the same time, the number of employers who pay people to really work on upstream and not intermittently submit patches that work in their favor. I feel like those are two very different things. Uh, there's really not that many. Right. Yeah. And then, depending on how you feel about any one of those particular companies, it may be an even smaller field. So it's it definitely makes me feel more empowered though. Like, I'm, I'm a little better footing. I'm a little less like just pleading to, to get a job because I'm able to take and transfer skills a lot more, which is great.

Rich Burroughs: [00:11:18] Yeah. No, agreed. And yeah, I mean, I think thatMaybeyou could count those vendors, those folks who would pay you to do that on a couple hands?

Carolyn Van Slyck: [00:11:28] Maybe two?

Rich Burroughs: [00:11:30] Yeah, not many.

Carolyn Van Slyck: [00:11:32] There's not many, but I mean, I appreciate it. And I think it's really important. Um, you know, there was this great article about how open source is like the roads and bridges, basically what technology is built upon. And I apologize because I don't remember her name, but, uh, maybe we can drop it later and we'll figure it out.

I feel it's really important to not just build on the poor one person who's maintaining curl for 20 years or something like that. Um, it's, it's leeching and I, I much prefer to see companies admit what is really part of their stack and to do the right thing. I mean, the other part of the right thing though, is just that as a programmer, when you rely on an upstream thing and you can't change it and you can't fix it or whatever, like you come up with all sorts of ugly workarounds that your company probably doesn't want to be carrying as debt. So I think it really is in their best interest to, to fund fixing things upstream and improving it. Yeah.

Rich Burroughs: [00:12:29] Yeah. I There's been such a history of those kinds of projects. Like you mentioned, curl and openSSH is another one that comes up, where you know...

Carolyn Van Slyck: [00:12:37] That one's terrifying number of people on it versus who depends on it.

Rich Burroughs: [00:12:43] Exactly. You know, and depends on it for security related things specifically, so, yeah.
So you are one of the maintainers of Porter.

Carolyn Van Slyck: [00:12:54] Yep. That's right.

Rich Burroughs: [00:12:54] And I want to talk about that a little bit. I'm pretty new to it myself. I've, I've looked at some of the documentation, but I haven't ever used it. So if you could give me like the high level pitch for what Porter is and, and why I would want to use it.

Carolyn Van Slyck: [00:13:08] Sure. This was something that Jeremy Rickard and I, uh, created in December of 2018 and it's an implementation of the Cloud Native Application Bundle specification, which is a really wordy thing. Uh, we call it CNAB and what it does is it gives you a way to say, here are all the things I need to deploy an asset or piece of infrastructure or software into, into production, not just the binary, not just, you know, the HTML, CSS, JavaScript, a WAR file, whatever.

Um, It's the logic, it's all those other things that normally you would have put into a README or a Confluence Wiki that says, by the way, poor soul, who's deploying this. This is how you do it. And this is what you do when it goes wrong. And here are all the various credentials you need to collect in order to do it.

It's, it's sometimes deploying something, especially if you're brand new, it feels like a scavenger hunt. And so what bundles do is you can take all of this information and it sounds fancy. It's really a utility Docker container that has everything you need. And then it's basically a common interface on top of it that says, and this is how we work with bundles. They all support install. They all support upgrade. They all allow you to inject credentials securely, or have parameters to change up what it's doing. And that's CNAB that's what bundles are all about. What Porter does it says no one wants to reimplement their deployment on this new technology that we're talking about on CNAB I already wrote something two years ago with Bash, Terraform, and Helm.

Help me out. I'd like to just be able to use this. So what Porter does is allows you to do that. You compose bundles using your existing scripts. You don't rewrite logic. When you move it into a bundle, you just add the extra packaging layer around it, and give you the ability to securely distribute your application and all its logic, uh, with things like, um, it uses TUF The Update Framework or in-toto to be able to have the hot term, right, supply chain security, and being able to say I'm shipping more than just a rando binary. Trust me. Um, yeah. It also does fun things where it's easier to because you brought all of its dependencies together into a single bundle. You can move it across an air gap. So you can deploy to the edge, you can deploy to isolated production environments.
Yeah. So it's, it's sneaky because the value feels like, Carolyn, you re implemented Helm. That's adorable. And sometimes it takes awhile to be like, no, actually we need to build this picture and paint it and go, here are all the other things around it. Right. It's very additive. It's not a replacement.

Rich Burroughs: [00:16:02] Yeah. So it's kind of like a layer up above those other things. Sure. Yeah, this is all really interesting to me because, I, I worked with configuration management for years, you know, I was a puppet user for few years and then worked there for a while. And so a lot of these. A lot of these things you're talking about are things that people have been trying to figure out for a long time, right?

Carolyn Van Slyck: [00:16:25] Oh gosh, this is not a new problem space.

Rich Burroughs: [00:16:27] Exactly. And those, those tools like Puppet and Chef and Ansible, they, they were really good at doing some of these things, but in static infrastructures, right. Which of course, most people don't have anymore. So, uh, I, I love that, that this idea sort of takes the promise of what containers were going to be, right. Which was this thing that had all the dependencies built in and was just basically something that you could throw out there and run anywhere, and, and kind of extend that to make that a reality that actually works for people the way that we work now.

Carolyn Van Slyck: [00:17:03] I mean, I'm excited. I hope people, pick it up more. We're in the CNCF, we're a sandbox project, which is, which is great. It's helped give us a little bit more visibility and to be honest separation. Cause a lot of people, they see that I work at Microsoft and they assume then that this must be a Microsoft thing. And really it's not, it's great when it works with Azure, but it works with everything. So that's good.

Rich Burroughs: [00:17:27] I'm interested the credential part because that's always an issue, right. And again, this is one of those things that people have been sort of reinventing the wheel, coming up with different models about how we safely use credentials and, um, So the idea is that the credential isn't embedded in this bundle...

Carolyn Van Slyck: [00:17:44] Correct.

Rich Burroughs: [00:17:45] It's almost like an environment variable or something, is that...

Carolyn Van Slyck: [00:17:48] It's injected into the bundle when it's executing. And so when I say bundle, when it's executing, what we're talking about is a Docker container, right? Yeah. And what happens is the runtime that understands, this is the bundle here is the image that I need to pull down and run. It also understands it needs these credentials and it knows how to map them. So it says all your credentials are stored in Vault, HashiCorp Vault, or Azure Key Vault, or it doesn't really matter. Any of these things will work. And then you can say the bundle needs a kubeconfig. This is where you find it.

This is what the secret's going to be called in the vault, in the secret store. And then it'll inject it into the, the Docker image as it needs it. I'm actually working on, uh, evolution of how this is so that you can actually say, let's think about what it looks like, the workflow of installing a bundle.

And you may say the first thing I do is I install a database and then you're going to lay down a virtual machine because this was a lift and shift. Okay. And some of these steps should have access to my kubeconfig, but some of them don't right. And the same thing, maybe I have a security credential, a token for GitHub or, or for my cloud provider, things like that.

Some of the things that I'm doing in my bundle should have access to that token and some shouldn't. And the next step I'm doing, like proposing to Porter and this is not implemented, is the ability to say, these are the ones that get the goodies and these don't get to see my credentials. So you can even isolate it further.

Cause sometimes when you think about what do I deploy? It's like a kitchen sink and I don't really want to expose a sensitive credential to a Bash script, even if I wrote the Bash script, I'd rather not if I could isolate it even further.

Rich Burroughs: [00:19:41] I think you're spot on there, and, you mentioned the sort of loaded term about supply chain security earlier.

Carolyn Van Slyck: [00:19:48] It's hot right now.

Rich Burroughs: [00:19:49] Yeah. People are thinking about this a lot after Solar Winds, and this has been one of the issues for a long time, is that people have these production credentials, that their their build systems have access to and, somebody who is able to compromise that system suddenly has a lot of doors open to them. Right?

Carolyn Van Slyck: [00:20:07] Yeah. And what's nice about this is it keeps those credentials off of that build server as much as possible so that we're not storing it in files on the file system. It's, it's never sitting around in an environment variable. Yes, it is in the container. And I'm sure like Ian Coldwater could get at it.

Maybe. I mean, who knows. They've got skills, but it's definitely limiting the exposure of the credential. Obviously you would still need to secure your environment and most of our build servers, um, need a tune up.

Rich Burroughs: [00:20:39] It's true. But we definitely shouldn't judge the security of things by what Ian can get into because...

Carolyn Van Slyck: [00:20:48] Well, I mean, I feel like at some point we need to raise the bar, so I'm glad that they're driving it forward.

Rich Burroughs: [00:20:53] Yeah. True, good point. So, what kind of, um, you mentioned the HashiCorp Vault, like what are some of the secret storage, uh, like back ends that you can use?

Carolyn Van Slyck: [00:21:04] Uh, so one of the tenets of Porter is that anyone should be able to make something work as though it was built into Porter directly. So there are plugins that you can write to integrate with anything, even if you have like your own hand-rolled secret store that's installed on prem, right? You should be able to write a plugin and it should work just like anything else. We have a couple of plugins right now. One is for Azure, obviously, cause, gotta sell.

And the other one is for HashiCorp Vault. Right. If we had someone who felt intrepid, oh my gosh, I would love to help them write plugins for other clouds. You know how it is when you're like one of two people on a project, it's there's things you really want to do. I'd love to have like everything out of the box supported and, already there for people, but at the same time, maybe I'm, I'd like to think that I'm leaving little breadcrumbs for new contributors to really make an impact on the project and own something.

Rich Burroughs: [00:22:02] I mean, in the end you obviously can't do everything right. And you can't do everything at once in any case. So, um, yeah, no, but I think that I think that supporting Vault, besides Azure makes a lot of sense that it's, uh, certainly one of the really popular tools out there for secret storage and I think for good reasons, it's a, it's a really good tool.

Yeah. Yeah. Cool. So, um, I was looking through the Porter docs and there was something that made me laugh, which is, uh, there's an exec capability in Porter. Uh, and

Carolyn Van Slyck: [00:22:39] DId you find the disclaimer?

Rich Burroughs: [00:22:41] I did find the disclaimer, the disclaimer says to use it as a last resort. And this made me laugh because, um, you know, I mentioned that I worked with Puppet earlier a lot, and Puppet also had an exec resource that you could use, which you could use to do anything, you know, run one-off scripts or, run, shell commands, all kinds of stuff.

And, uh, generally our feeling as people who like, knew a lot about Puppet was that if you were using exec, you were doing it wrong, you know, like something had kind of gone wrong, to get you to the point where you felt you needed to use exec and I think part of it was the Maslow's Hammer thing, it was like, it's like, there are people out there who will take a tool like that, you know, like Puppet or any other tool. And they'll, they'll try to use it for things that really aren't within its sweet spot, you know?

Carolyn Van Slyck: [00:23:34] Yeah. I think for, for Porter, it served two functions. One, as I said, we can't deliver every single like provider plugin that you would need. Right. So we have ones for Helm we have ones for Kubernetes, uh, for Kustomize uh, you know, various things out there, but.

There's a couple of scenarios. One is we haven't written one yet for whatever it is that you're doing. For example, there isn't one for Puppet and people have asked, like, how do I use Ansible or Chef or Puppet with this as well? Uh, they're, they're interested in doing that. People want to leverage existing assets here.

Rich Burroughs: [00:24:10] Of course.

Carolyn Van Slyck: [00:24:10] And that's the other piece of it though, is that if, if someone has invested hundreds of hours in writing a wonderful Bash script, just the best, best Bash, right? I don't want to tell them you have to rewrite it and we're too good for your Bash. No, no, we'll run it. We'll just tell you like there, there are trade offs.
One of the things that's really fun about bundles is that so they're stored in OCI registries. So I can put my bundle up there on say Docker Hub and tell anyone, Hey, you can run this and it'll set up the app for you. Which is great, but it feels like really opaque. What is it going to do?

I want to be able to affect this. I want to understand what's in it. And what it does, Porter is authored in a declarative language. It's YAML for better or for worse. Right. And what this lets us do is when you pull down a bundle, you can run, explain on it and it'll tell you, it's using Azure, it's using Helm, it's using Kustomize. And you're like, why are we using Helm and Kustomize? Don't think about it, but we're doing both. Right? And it allows you to get that visibility. If someone chooses though, to use exec, what can I say, who knows what they're going to do? Right. Um, trust it however you will at that point. But it's nice to be able to give people that additional information. Cause you know, some people are happy to curl and pipe it to Bash and some people want to read that script first, right? Yeah.

Rich Burroughs: [00:25:40] Yeah. So that shell script you need to run, that would go in the bundle with the other stuff?

Carolyn Van Slyck: [00:25:46] It would. Yeah. Yeah. So the types of things you would see inside of a bundle would be, that, that helper Bash glue script. That, to be honest is probably always there somewhere if you're starting from existing assets. Right? So that, that file would go in there. It would go right next to the Porter YAML file that says, here's the workflow of the bundle. This is what I want to have happen when I do install. Um, but let's say for example, you're also shipping your products binary, that would go in there as well.

So, uh, it kind of ends up being this grab bag of all the artifacts from your build. So some of it's from your repository, some of it was, was generated. And this gives you a way to easily distribute it.

Rich Burroughs: [00:26:32] Yeah. And it's a, it's a good point. You know, that a lot of times these kinds of migrations it's, you don't do it all at once. Right? You don't have the time to like, do everything. Perfect. You know, you take a first stab at it and then you iterate and you make improvements. And so yeah, there may be that random shell script that you'd rather not have to run at first until you figure out a way to, to, to migrate off of it. Yeah.

Carolyn Van Slyck: [00:26:58] Yeah, because I always feel like it doesn't matter if we're talking about build scripts or production code, which sometimes that's actually the same thing, is rewriting. It is rarely, uh, as a return on your investment, right. You, I rarely get to feature parity and it usually took a very long time and you added new and interesting bugs along the way. So I definitely never want someone to feel like, for anything I'm using that I'm forcing them to like boil the ocean. Uh, I feel like you lose people at that point. Rightly so.

Rich Burroughs: [00:27:29] So speaking of losing people.

Carolyn Van Slyck: [00:27:31] Uh oh.

Rich Burroughs: [00:27:31] So, so as, as we mentioned earlier, you work on the special interest group, um, SIG Contributor Strategy. And I was looking at that a little bit and it looks like you're in a, I don't know what they call them, the sort of subgroups, um, a working group that you're in a working group focused on contributor growth?

Carolyn Van Slyck: [00:27:51] That's right. Yeah. Um, Paris Pittman, uh, tricked me last year, right before COVID hits. Uh, she goes, do you have a couple extra hours a week? And that time in January, I was like, Oh yeah, sure. Of course. Little did I know. Um, because I had written things in the past for, uh, Kubernetes and the community around how to attract new contributors. I had written like a entire article that basically defines for Kubernetes how do you label things as help wanted. Sure. There's applying the label, but why would I call it help wanted, what do I need to put into it? Well, what makes a good first issue? How do we get enough information into these issues that someone could look at it on the weekend, not talk to when, talk to anyone and ask for help and be able to accomplish that issue.

Um, And so what this group is doing is taking ideas similar to this. What goes into a contributing guide? What goes into a ladder that says, how do you move from a contributor to reviewer, to an approver who maintainer to be a project lead or something like that, kind of laying out a path for people to make the projects one more open and transparent and preventing, um, you know, letting your friend become a maintainer, but not the person that's been putting in the work for six months. And then also just, uh, you know, making people feel welcome and ensuring that we have common ground rules too, for people who are in CNCF.

Rich Burroughs: [00:29:25] Well, I have to say that I'm kind of bummed because I was going to ask you to make me a maintainer. Now it seems like you're saying you can't.

Carolyn Van Slyck: [00:29:32] You know I'll make you one directory with nothing in it and I'll put a Codeowners, put your name on it.

Rich Burroughs: [00:29:37] Fantastic. Um, no, but those are great points. And, and I guess you're thinking about these things beyond just Kubernetes, right? It's the CNCF as a whole.

Carolyn Van Slyck: [00:29:49] This is at the CNCF level. A lot of it heaviest is based on one of the most popular projects that the CNCF has. We have, we take inspiration from everything. Being able to say, this is what Helm did. This is what, um, various people on different projects... like Porter's been able to contribute a couple of things too uh, it doesn't really matter who did it. We want to see did it work for them? And what were characteristics about this project that made that the right technique? Because what works for a project that honestly is staffed by 140 Googlers is not going to work for a project that has two maintainers who do it for the love of the game and are not being paid. What you can expect out of them and what they should be putting in a contributing guide or promising as far as onboarding help and things like that is, is very different. And as a maintainer, it can be overwhelming just in general, like you go to Twitter, you hit someone's blog and everyone is telling you. You should be recruiting new people. You should be teaching them to code. They don't need to know the language. They never need to use your tool and you should be open to everyone and you should definitely have Slack, but Discord is really cool, but you know, really we should be inclusive. So we have a mailing list and meetings, you know, on, uh, APAC time and your time. And, um, it's unreasonable because the information we're getting isn't filtered or qualified based on who is going to have to implement this. So one of the other aspects of contributors strategy is. Giving maintainers, uh, the support, they need to draw boundaries and say, that's great.

And when we're bigger, we'll do that. But for now we need to make sure that we don't get burned out and we drop off the project and the project becomes archived. Right. Um, there's just a fine line of what you ask of people, especially right now, because everything sucks. Um, and the fact that anyone is still doing open source is either their own personal therapy or I'm not quite sure, but it doesn't always feel like the right way to spend your time, um, lately.

Yeah. Yeah. That's one of the things that Contributor Strategy does though, is we've created something called a maintainer circle and it's for maintainers of a CNCF project. And we get together twice a month and we talk about different things. We talk about burnout. We talk about how do you define values for your project?

Yeah. Um, and just various things like inclusive naming, uh, has also come up. We're pretty new, but I think these are great things to think about. And I like that doing it at a smaller scale allows us to be nuanced instead of putting out one blog post that says, if you're not doing this shame on you, you should feel bad.

Rich Burroughs: [00:32:37] No, I think that's a great point. And obviously the, the context can vary greatly, you know, Between, you mentioned size of teams, also that idea of, you know, is someone getting paid to do this thing or did they just do it because they think it's really cool. You know, um, those are two really, really different scenarios. You could carve out 10 hours a week, to deal with being a maintainer, as opposed to like doing it on your weekends and evenings.

Carolyn Van Slyck: [00:33:04] And I have to admit, you know, so I have projects from the before times when no one paid me to do open-source and to this day, those still don't get quite the same attention as the ones that I get paid to, you know, reply to comments, during nine to five. And that's the way it should be. No one should feel bad about that.

Rich Burroughs: [00:33:23] It's hard. I mean, being a maintainer is a lot of work.

Carolyn Van Slyck: [00:33:27] It is. You're really, you're putting yourself out there. You're making yourself vulnerable in ways that you don't always realize until you get feedback, comments, spotlight on something that you wrote really quickly to make it work for you.

And then you, I don't know, accidentally excluded a huge chunk of your users and you didn't realize, or it just, all sorts of things can happen that you didn't realize you were signing up for when you put an MIT license on your code and put it on GitHub. So I really liked the idea of giving people better information about what it's like to be maintainer, what it's like to participate in an open-source community from any role.
You know not, not just code that's the other thing that I'm really interested in is I used to work with tech writers. I don't know if you've heard of these magical people.

Rich Burroughs: [00:34:15] Oh, wait a second. Those are those people who write like really good documentation. Indeed.

Carolyn Van Slyck: [00:34:20] Yeah. Yeah. One of the parts of, uh, growing anything or a year project, um, your paycheck is people need to understand how to, how to use what you've wrote and use it in the way that you intended so that they're successful. I'd love to see more, less code contributions and more holistic contributions around how can we make this project that we already have usable and accessible to people instead of going well, step one, learn everything about Kubernetes and CSI and load balancing. And like, this is a particular flavor of annotations that you need for your cloud provider.
And like they're gone. Right. People have left at that point. So like, obviously I want new features, but I'd really like to take what we have now and make it, uh, at, you know, accessible to people, remove that barrier to entry. And that comes through docs. It comes through project management. It comes through all sorts of different angles, community management, videos, content, I don't know everything.
I'd love to see more people contribute in new ways to open source.

Rich Burroughs: [00:35:28] Well, you're, you're going to like me then, because I'm that person, pretty much every one of my GitHub contributions ever has been fixing a typo in somebody's dock or something like that.

Carolyn Van Slyck: [00:35:38] Like it's so it's important work. Let me tell you,
Rich Burroughs: [00:35:45] I'm curious, like, as we mentioned, you know, this, the context of what works is very different, you know, uh, on different kinds of projects, but, but I'm curious. Like, what are some of the things that you've seen projects do that you think helped them be really successful

Carolyn Van Slyck: [00:36:03] As far as being a successful project or like growing contributor base?

Rich Burroughs: [00:36:10] Uh, no, I, I guess I'm thinking more in terms of like adoption and use than the contributor base.

Carolyn Van Slyck: [00:36:15] Yeah. Yeah. Um, so one, I don't think I'm an expert, right?

I've tried many things across my different projects and I've had success with some. Um, so for example, one thing that, that someone suggested to me was for, for new contributors, um, the concept of they should be successful without having to ask you for help, without having to go at IRC or something and figure it out.

And, um, he suggested an onboarding tutorial, like take all the things that someone normally has to play 20 questions with you in order to get started on your project and literally make, uh, a tutorial like it's, uh, it's not even a read me. It's like a real rendered website with pictures and everything, whatever it takes to explain it and go, this is what you need from start to finish, to do essentially, uh, an example feature.

So Porter is a command line tool. So we walk them through, how do you add a new command? And like what's all the plumbing to enable it and implement it. And then how would you log it? How would you write the docs for it? How do you preview the docs for it? Um, how do you run it manually? What would, what would all these things look like so that someone can get all this information with, um, like I said, during that weekend and be successful, um, and get that information out of your head.

And I found that to be incredibly useful. Contributors come in waves. So maybe no, one's gone through the tutorial before, but I had like five people try it previously. And I think that works really well. And I haven't seen that in too many places. Um, but the other thing I think is useful is sometimes we assume that the people who come to our project.

Yeah, no, um, no, how to use it. They want to contribute. I would say most contributors who come to me who say that they want to contribute to a project, different projects. Like they want to contribute to Kubernetes okay, great. Have you used it? No. Um, and I think it would be helpful, like if you want these people, cause some of them were ex really earnest and they actually didn't want to do this.

It's just, yeah. I haven't had the, the star and moon align to give them that work experience. Right. So that they were able to learn that. And so putting in your contributing guide, here's the great video that explains what it is. Oftentimes people will be referred to your project and go, Oh, Porter is a great project. They're really welcoming. And you get people who actually don't even know what Porter is. That's okay. Right. I will take them as long as they're interested in learning what it is on their own. If I give them materials, will they do it? And I think that's the biggest thing is what all these, a piece of advice fall into is scale.

I can't scale me talking to someone one-on-one doesn't scale. Doing a screen share and getting their environment set up or. Yeah. Figuring things out. So anything you can do to enable people to be self-starters right, is going to work in your favor. I never regretted doing something like that. Um, whereas features I can always regret later.

Rich Burroughs: [00:39:23] No, I think, I think you're spot on. And, and this is something that I actually talk a lot about. Um, I have a lot at my, my last few jobs, this, this idea of, um, cause I think that like when somebody discovers a new tool and they're interested in it and they start playing around with it, you know. Any roadblock that they run into is potentially the last thing they do, right?

If they can't understand the docs or if they're trying to copy and paste the commands that are in the doc, and one of them throws an error message, that might just be the end of their journey. Right. They may just peace out there, you know, as opposed to like going to the project, Slack and asking questions or, you know, uh, doing it some other way. Um, you may just lose them completely.

Carolyn Van Slyck: [00:40:11] And you'll never know. You'll never know. They tried it. They didn't feel comfortable or they didn't think, honestly, it was worth their time making you figure it out. Right. Um, and you have no idea. It could happen to five people. It could be 5,000 people who were hopefully going to use your project.

And then there was some, like you said, tripping point where, oops, we can't get past this. And you'll, you'll never know that they even tried. Uh, I, this is why I love talking to people who tell me that my project doesn't work. Initially. I know that sounds horrible because you don't really want to hear, I tried it and it didn't work, but I like to act on every piece of feedback I get about that.

Not just I saw this error, how do I not get, that error. I want to understand why they took the path they did, that ended up not being the thing. I was hoping that they do. Right. How did they get off of that happy path? Why, they have an idea in their mind of what the task was. And I guess maybe I hadn't anticipated that task or I hadn't written doc for it, or there are just so many different things to look at it beyond just changing the code or adding a FAQ for, if you see this error message, this is how you get back on track.
I really like to make sure that I think someone called it falling in the pit of success right. Maybe that's a Microsoft thing. I'm not really not sure, but I want to make sure that the easiest thing to do is to try it and it works. And any time it doesn't, I want to understand why we made it so that it didn't, you know, they didn't end up on the right path. Cause I, I feel it's a failure of us usually not the user.

Rich Burroughs: [00:41:50] That's super interesting. I mean, it, I did a very short stint as a product manager at this all sounds like product management. It's very much about listening to the users and incorporating their feedback and, and figuring out where those pain points are.

Carolyn Van Slyck: [00:42:04] I feel like that's the path to success. I can write a dev tool that does everything I want it to do. And for the most part, not have bugs. But it only worked for me because it was written with my modalities in mind and my worldview and experience and understanding of various concepts. So of course this, everything lined up and it worked for me.

I don't think that's interesting. Right. Cause who else has, there's like one Carolyn in the world. Maybe there's a really cool second Carolyn. Right? Who will also be able to use this dev tool. But I want it to work for everyone and you're never going to get it to work for everyone if you don't talk to a diverse set of people.

Yeah. Which for some programmers is a letdown. Talking to people. I'm an introvert. It's not, it's not my fave and you really don't want to hear it when it didn't work for people, because it feels like, uh, you failed. Right. But I like to look at as a success, they reached out and told me, and I want to take advantage of that interaction.

Rich Burroughs: [00:43:03] Yeah. That's fantastic. I mean, I totally get how, how someone could feel defensive, or feel like they're under scrutiny. And I mean, the reality is that people aren't always kind in those scenarios either, right? Like sometimes the feedback is not delivered in a way that, that even the person who gave it would really appreciate it.

Carolyn Van Slyck: [00:43:22] Yeah. And I'm, I'm on the block first ask questions later, brigade. I am extremely giving of my time and energy and feels to be honest, but if someone isn't coming in, like respecting my boundaries and respecting myself. Then no, no, they don't, they don't get the, uh, 20 questions or the Five Why's of why it didn't go wrong.

I'm just like, I'm sorry, I didn't work for you bye. Um, and you have to do that for yourself. Cause otherwise it it's you're, like I said, being an open source is being vulnerable. Talking to users and getting their feedback is being vulnerable. And I would never encourage someone to do that without strong boundaries and thinking ahead of time and going and telling your other maintainers this as well.

Um, we did this with Dep. I worked on Golang step for awhile. And we would tell other maintainers if people don't treat you right. And this is what it looks like to be treated right. And this is what it looks like to not be treated right. You have all of our permission to shut it down or we'll come and shut it down for you. Right.

Rich Burroughs: [00:44:29] That's really interesting because I don't know, there, there may be some folks listening who are familiar with the context of that, but but Dep was very controversial. It was a lot of feedback about it that I, that I would say was not very positive. And it, it did seem like people, people either loved it or hated it. One of the two.

Carolyn Van Slyck: [00:44:49] Yeah. Yeah. And so it was important to, to, to take care of our people first. Right. We have this community and it's really easy to get on this bandwagon of just saying community first, but you are one of the most important people in any of one of these equations. And then the people who are helping you build this community and are, have already put in the work and are putting in the work and again, making themselves vulnerable, they need to be protected versus well, right. You have to find a balance and being put out there and told you need to do this. And you just hear the rah, rah, you're sending someone out, setting someone someone up to either leave entirely or be really hurt. Right. And that's not, I don't want to do that.

Rich Burroughs: [00:45:36] Yeah, of course. Um, all right. To change gears for a little bit, here at the end. Um, we, had kind of swapped some messages before we got on the recording. And you'd mentioned that you are really into command line interfaces and, uh, this is something that I've, I was super interested in as well.

I've uh, been using CLIs for many, many years and, uh, had lots of different kinds of experiences. You know, some that I liked a lot, some that I didn't like as much. Um, I'm curious, what are some of the things that, that make you really kind of fall in love with a CLI?

Carolyn Van Slyck: [00:46:15] I love that it's... it feels like it's, it's this like wonderful intersection point where I am still implementing functionality. Right. But I'm at the point where I can have some of the largest impact on the developer experience, both for usually the... it depends some CLS, like I've written in the past, we've just wrapped an API or something like that. At that point you have the ability to be that perfect developer advocate and go, these are all the problems with the API and this is what we need to do.

And, and to be honest, I'm the type of person I'd just go fix it. I'm not like a front end person or a back end person. I will go anywhere the problem is. And I feel like I have an answer and I will just submit the pull request. Um, and so at the command line tool, it's kind of fun because your user is nearly always a developer or someone who's in a very similar sphere as you.

So you can bring a lot of your own experiences to bear, which is great. Um, and you're able to go, what would be the experience I wanted? I love being able to think about different CLS I've used and go, this one has worked really well, and this one was basically crud on top of an API. How can we make these things better?

So it allows me to do a lot of the UX I care about. Right. And have. A very large impact. To be honest, it allows me to paper over the cracks in the drywall of whatever it is that the CLI is fronting. Um, Porter is kind of fun cause it fronts nothing. It actually implements a whole bunch. And there isn't like some secret cool backend where people do the real work like everything's in there.

Um, I have to defend my poor little CII work CLI work sometimes because I get, I get defensive about it, but I think that's what it is, is that it's a place to, to really impact usability.

Rich Burroughs: [00:48:14] Yeah, no, I agree. It's um, uh, when I was at Puppet. They actually did quite a bit of UX research, on CLI tools because they were used very heavily by the users, and, there definitely were people who would just go to the web UI and do everything there, but there were quite a few people who depended on the CLIs. And that was really the place where I think I started to... my level of appreciation, went up, you know, what you saw somebody like actually doing surveys about you know, which, which of these two options sounds better to you, to do this particular task. Um, there's quite a lot you can do.

Carolyn Van Slyck: [00:48:53] Yeah. I've always wanted, they had the type of funding where I could do like user research. Um, Conan O'Brien has done this wonderful thing where he went to, I think it was Taco Bell and got to see Taco Bell's user research, where it's a whole bunch of people in this like cafeteria setting with dividers on each side of them and a little window that would open up and they could slide tacos at you.
And then they would tell you how they felt about the taco experience. I would like that for, for my tools, for whatever it is I'm building. I would love to be able to have a tiny little window that I can pull up and send it in front of a user and watch them cross out whatever it is I write. And then ask them a question and then try different things and an AB test, not with a feature flag somewhere, but like, I'm going to give you a flavor and someone else's a flavor and I get to really talk to you and see how it went.

And. I've worked. When I worked earlier at Microsoft, we had that cause I was in Office and there's lots of money to throw around for stuff like that. I'd love to see that type of thing in open source as well. I'd love to see that funded because otherwise you, you always end up, it's like a blessing and a trap.

Um, you feel like you're writing something for yourself, so you don't think to ask anyone else. It's just like, Oh, obviously I know how it should be written because it's for people like me. Um, so it makes it easy. It feels easy to make design decisions.

Rich Burroughs: [00:50:19] Yeah, no, I mean, I think that there's, we're all different. Right. And people find different things easy and hard. I see people complain about the Git UX so often. Yeah. And it's, it's one of those things where like I struggled with Git a lot, you know, and then one day I just kinda got it, you know, and, and I didn't really struggle after that. And so it's, I find sometimes I've sort of forgotten about that pain that's there, you know, for the person just starting out because it's, it's so long since I experienced that.

Carolyn Van Slyck: [00:50:52] Yeah. I, I, it took me two years of saying that Git was the worst thing ever, because I had had so much experience with Subversion and it was kind of a, a big switch. And then at some point I really understood the graph and what was happening. Right. Um, and then it... and I think even more than that, you, you understand these are my three workflows and this is how I accomplish them.
And when I get stuck, this is what I do. And so you remember it was like four or five things with Git and you don't stray from the path, right? This is the way. This is how we use Git. Um, I people keep talking about making, uh, another level of porcelain for Git that really reimagines it and says it works great for how we sort on the file system. Right. But we don't need to be exposed quite this much. And I'd like to think, I think some of them are already out there and they're more task based instead of saying, this is how I accomplish, uh, you know, changing a pointer I've had from here to here and all these other things that you do in Git you just say, I'm trying to make a feature branch. I'm trying to merge it. Yeah. I need to reincorporate, main or something like that. And I think a tool that focuses at that level would be much more successful built on top of Git but

Rich Burroughs: [00:52:05] That's really interesting.

Carolyn Van Slyck: [00:52:06] I don't know if you'd convince anyone to do it cause once you've spent four years learning it yeah. You're kind of proud.

Rich Burroughs: [00:52:11] But I think the thing is there's, there's a lot of shops out there, who've already built that, right? Like they've already built shell scripts that, you know, that somebody uses when they have to, do a specific task because of this, you know, because it's so hard for people to figure things out.

One of the best things I did when I was learning Git is I, um, I made myself a repo just to mess around with, right. Like that had nothing to do with our company's code. It was on my own personal GitHub. Um, I threw a bunch of files in there that I didn't care about at all. Right. And, and I took the pressure off of myself, like, yeah. In my day job. I was worried about destroying our repo that had all this important stuff in it, you know? And, and so I was able to just play around with this other thing that was just literally all junk, you know, and, and it took the pressure off a lot. And, and I think that helped me get to the point where I was comfortable.

Carolyn Van Slyck: [00:53:09] I probably have 16 of those Git test repos where I, where I play around with various FUBAR, farts, um, files, and, uh, just the... figuring out what Git is going to do in various scenarios. Um, Yeah, I would be worried if someone isn't, cause I definitely don't want to like defuse a bomb live on my code if I want to figure it out somewhere else first.

Rich Burroughs: [00:53:36] Well, I think that is all that I had to ask you. I really appreciate you coming on the podcast. It was super cool to chat with you.

Carolyn Van Slyck: [00:53:42] Oh no, thank you. This was so much fun. It was great.

Rich Burroughs: [00:53:45] Do you, um, do you have anything you want to plug like, um, I'll put a link to your Twitter in the show notes.

Carolyn Van Slyck: [00:53:52] Oh, Hmm. I do. I am giving a talk at KubeCon EU.

Rich Burroughs: [00:53:58] Um, fantastic.

Carolyn Van Slyck: [00:54:00] Well, I have to record it like next week, but I imagine it's in it's in a couple of months. I think it's in May and it'll be about growing your contributor base. So if this is something that people are interested in, um, it will be recorded and free later, but if you want to see it, you know, as it happens, you should totally sign up for Kube con.

Rich Burroughs: [00:54:18] That's fantastic. And I, I definitely echo the idea that folks should sign up for KubeCon it's, um. It's a little bit of a bummer to be doing them online because it's not quite the same experience but at the same time, I've been to the last couple of virtual ones and I've still gotten quite a bit out of it.

Um, there's a lot of good content, a lot of talks about really interesting things and yeah, a pretty big variety of topics, right? Like there's talks that drill into security and, all different kinds of things. Um, so yeah, I will, I will be there online. Again for the EU one, even though it means me getting up at like five in the morning or something,

Carolyn Van Slyck: [00:54:56] It is depending on the times when it's about five in the morning, for me in Chicago, when it starts, I am enjoying virtual conferences in a completely different way. You don't have the hallway track, but I will sit down on my couch with my husband who is also in the same house with me. So he gets the ticket to whether he wants it or not. Um, and we put it on the big screen and we watch it. And then you're able to sit there with your laptop and not feel like a terrible person as you try out what they're talking about as they're talking about it.

And then usually you have access to the speaker during the talk. So if you try it and you have a question or whatever, as it's happening when you're confused, because I'll forget it, 30 minutes later, right? That's not going to stick around. You can ask them, which is, it was just fun. I love the level of access you get to speakers with virtual conferences. I feel like it's, it's a lot more immediate than being one of the five people at the crush at the end of a talk who can come up and talk chat with you. Yeah.

Rich Burroughs: [00:55:55] That's a really good way to look at it. I've, I've talked to a number of people who have pointed out that sort of, um, the TV thing, right? Yeah. Austin, who does the Deserted Island DevOps? I think he's the first person I really heard talking about it about the fact that we shouldn't think of these as these, uh, virtual conferences as like a physical conference done online. Right. That that's not the way to think of it. That, um, that they're really a lot more like watching a video or watching TV,

Carolyn Van Slyck: [00:56:24] I treat it like listening to a podcast. Right. It's, it's something that I have on, I I'm mostly engaged with. Occasionally and my mind wanders, but otherwise I'm, I'm incredibly comfortable and I'm usually doing something else, but it's related usually to the conference and, uh, it's different, but I, I think I found a way to make it work, uh, sitting in front of your, you know, your office desk or on a, like a chair at the dining room table staring at a little laptop. I mean, I, you can't do that for more than an hour, right? That's not fun. Get in your jam jams, sit on the couch, get on your bed.

Rich Burroughs: [00:57:02] Yeah. Have some hot chocolate.

Carolyn Van Slyck: [00:57:04] Oh, probably right after this talk. Now that you've said it.

Rich Burroughs: [00:57:09] All right. Well, uh, w uh, I will definitely put some information about KubeCon in the show notes. And, uh, like I said, I'll link to your Twitter, Carolyn. Um, thanks so much for coming on. I really appreciate it.

Kube Cuddle was created and hosted by me, Rich Burroughs. If you enjoyed the podcast, please consider telling a friend. It helps a lot. Big thanks to Emily Griffin who designed the logo. You can find her at daybrighten.com. And thanks to Monplaisir for our music. You can find more of his work at loyaltyfreakmusic.com. Thanks a lot for listening.