Latest / Oxide and Friends / Open Source Anti-Patterns with Kelsey Hightower

Transcript

Open Source Anti-Patterns with Kelsey Hightower · Oxide and Friends

• 0:00
  Speaker 1: After Elon took over I know you you joined us for one of the prediction episodes, I think, a year and a half ago or so. Yeah. After Elon took over, we looked for a new home, and we evaluated some, kinda hilarious other options, but landed here. And, it's been working out really nicely. People have really liked the, the live chat, in in this as a sidebar, and it's been pretty handy for the show notes.
• 0:27
  Every once in a while, we can just mine out the the chat and turn that into the show notes and call it good enough.
• 0:35
  Speaker 2: Are we talking Twitter spaces versus Discord?
• 0:38
  Speaker 1: Exactly.
• 0:39
  Speaker 2: Yeah. Kelsey, it's good. I I gotta say, it's, I know. Because you I I was in a bunch of your spaces too. You think you get some great Twitter spaces, and I feel like, you you must have also seen room for improvement, I would assume.
• 0:52
  Speaker 3: A lot of room. I mean, number 1, you can use your normal, like, podcasting setup
• 0:59
  Speaker 2: It's awesome.
• 1:00
  Speaker 3: Desktop. That we're already winning.
• 1:02
  Speaker 2: We're already winning. I know. I know. I know. It is, one in particular, going
• 1:08
  Speaker 1: back and listening to some
• 1:08
  Speaker 2: of the back catalog, Adam, I am reminded I mean, we would joke about it, but we would joke about it because it was true that more or less every episode, something went wrong with Twitter Spaces. And then you get the the the fact that that you can't dial in on your laptop and but but you can listen it. You just can't speak, and there's nothing to indicate that. I mean, boy, we had so many people get hung up on that.
• 1:31
  Speaker 1: Yeah. It was rare that it survived the full hour plus or whatever.
• 1:35
  Speaker 2: Totally. Totally rare. No. But but Kelsey Discord's been great. It's been really, it's we've really enjoyed it, and, it's been good because it has made it super easy to get people up on stage, but also super easy for people to contribute in the in the chat, which is really important.
• 1:52
  Because actually, we got this feedback from in Twitter spaces too a lot, where it's like, I got something I wanna say, but I'm, like, happy to just type it into the chat. I don't actually need to, like, stop a conversation to say it. So it's been it's been good. Well, Kelsey, welcome. It's great to great to have you here.
• 2:11
  Speaker 3: Happy to be here. You you picked me for the most contentious topic right now. So Well you were
• 2:17
  Speaker 2: at Lowe. You know, the Kelsey Lowe the last time you were here was for the the the terrific predictions that you made after you went deep into web 3 and with a with an astonishingly open mind And, with it did a huge service for the rest of us, in terms of coming out with, like, I mean, being fair. It's like, hey. You're I hear some things I found that are interesting, and we hear a lot of challenges. So, yeah, we we figured you that you're good for the lighting rods.
• 2:45
  You know? We gotta have you come in and and, this is not the right thing.
• 2:50
  Speaker 3: Pan out. What what was my prediction around web 3? Did I say it was gonna be a raging success?
• 2:55
  Speaker 2: That's what you said. Raging success. Everybody go long.
• 2:58
  Speaker 1: Put all your money on all your money on 32 red or whatever.
• 3:02
  Speaker 2: That's right. Yeah. You promised an air drop for all listeners. I wasn't even sure what that meant. No.
• 3:08
  So you were, I need to go back to the the the the the prediction from that year that stuck with me was Adam's prediction that that we won't use the term web 3. Web 3 will kind of quietly disappear, which felt like it was that felt accurate. It felt like.
• 3:25
  Speaker 1: Felt hopeful at the time, but it it it seems to have panned out. I don't know.
• 3:29
  Speaker 2: It definitely I I don't think we anyone predicted that the, one of the largest cryptocurrency exchanges would be in a Bahamanian jail and then a Brooklyn jail. I don't think we we did not correctly predict the the jail route. But, yeah, it was, that was fun. Anyway, Kelsey, it was great to have you there, and I mean and always appreciate your perspective. And this is I mean, Kelsey, you said this is a contentious topic, which is I mean, there's so many truths to that.
• 3:56
  This is also one that's very near and dear to your heart and our hearts. This has been super important to us. So we and, Adam, did you did you see this this talk that I gave now a decade ago? Over a decade ago on Yeah. For sure.
• 4:10
  About it?
• 4:11
  Speaker 1: Yeah. For sure. Yeah. I remember it at the time and and watched a bit of it this, this weekend.
• 4:15
  Speaker 2: Yeah. And it's funny to go back and watch it. And because, of course, my now 11 year old was a newborn. I mean, this is the way decades work, generally. Turns out.
• 4:24
  Right? It turns out. And, but it was it was interesting to go back and kind of rewatch that. And I don't think anybody is wrong. I mean, I definitely would stand by, but you realize that it definitely is standing in 2012 looking back on the previous decade.
• 4:40
  And just, you know, we had said that predictions tell you more about the present than the future. I think that that was really telling you about what that decade was, and a lot of that decade I mean, it was open source stepping into its own. And a lot of the, the the corporate open source antipatterns that I saw at that time were all around companies that had been born proprietary, and trying to figure out how to participate in open source, and then especially how to open source their own projects. That was kind of the focus of that, I would say. Was source that had been born proprietary and was becoming And, again, I think I stand by all of that.
• 5:20
  But what we saw in the last 10 years is really pretty different. And in part because open source arrived. Open source had, by 2012, everyone was deploying things with, open source, open source, the core the core of all of our infrastructure. And, we now had companies that were being built around open source. So companies that started open.
• 5:45
  And now I would say in the last decade, the anti patterns to be much more, mindful of are now in companies that start open, and then, and then things happen. So that's I would say that's the theme, but I would love to get so Kelsey, I mean, people obviously associate you with with with Kubernetes, but you were also at an open source company, CoreOS, before you were at Google. And that was a company that was more or less born open, wasn't it?
• 6:15
  Speaker 3: I mean, even before that, you know, if you go back maybe another if you go back another maybe 4 or 5 years before CoreOS, there was Puppet Labs, which was also born open, you know, configuration management space. I think during those times, both CoreOS and Puppet, you're gonna build an infrastructure tool. You almost had no choice but to start off open. There was anything else was just too big of a barrier to adoption. A lot of people were not just competing on price, but just getting that entry point to the average enterprise, you you had to just be open.
• 6:50
  Number 1, just from a book coming out of that whole lock in period of we're using proprietary tools that just cost too much to use from dev to production.
• 7:01
  Speaker 2: So
• 7:01
  Speaker 3: I think anyone that was gonna allow a new tool to come into any company, you're gonna have to have, for lack of better words, some type of free tier, but a very low bar of entry for 1 on price. And then number 2, just this idea that I just wouldn't get locked in in terms of your sales team deciding to charge more. So, yes, I definitely was in that part, but I thought it was necessary for those infrastructure companies at that time.
• 7:26
  Speaker 2: Okay. Can you speak to that? Because I think this is actually it's something that that I think people may have historically lost that is very important about that fear of lock in for infrastructural software. Because, obviously, like, we are of a vintage that recalls that era. Could you speak a little bit to
• 7:43
  Speaker 3: That thing?
• 7:43
  Speaker 2: What what customers were afraid of?
• 7:44
  Speaker 3: When I joined Financial Services, they had a automation tool. I forget what it was called, but it was one of those built by HP or IBM. The license was so prohibitive that if you wanted to add it to a new server, there was gonna be a whole discussion about getting another license so you can automate the server. You're in a situation during that time of virtualization where we were making a lot more servers than we had actual physical servers. So the pricing model is way off.
• 8:12
  Oh. So we had to pick and choose what servers to automate. So that number one barrier to entry also, nothing's worse than lock in than lock out. But when new when Linux started to come around, new software packages that we wanted to automate, the thing we were using, literally, they had no integrations, time,
• 8:36
  Speaker 2: I
• 8:40
  Speaker 3: don't know if we would have complained as much. They couldn't. Time, I don't know if we would have complained as much. They couldn't. Oh, then it was like, hey, here's this thing called Puppet.
• 8:50
  Some people are using things like CF engine. Either way, they were open in terms of you can build the integrations that you need it. And 2, there wasn't this weird pricing situation where you just couldn't install it on all of your servers. And so those two things, I think, allowed those tools at that time. We're talking 2,009, 2010, to basically go from QA to production in less than a year, and then they became the way we thought about automating things going forward.
• 9:20
  Speaker 2: Yeah. That is a first of all, I love your point about, the worst thing about lock in is lockout. That is definitely feel you on that. And I think that I think I mean, because we still do use we have to use some proprietary software here at Oxide, in particular, around EDA. And, we have all of those same problems.
• 9:38
  And it is, I just think I mean, I can when you describe that, Kelsey, I can feel myself being kind of with you in, you know, 2,006, 2,007,008, and not being able to spin up new infrastructure because, oh, we actually need to expand our license footprint, and the person that does that is actually gonna be out for 2 weeks. Or it's like we're my business can't move forward at the speed that it wants to move because I have to effectively I mean, forget the monetary cost, but that too. But just that whole idea that I can't just use this thing. I've gotta actually I've got someone sitting there, metering all of my usage of this thing. Really makes it hard to actually use it ubiquitously, and it makes it really hard for me to to depend on.
• 10:25
  Speaker 1: It's also a great point that in that time period, we were moving from physical infrastructure to virtual infrastructure. And as you say, Kelsey, the the pricing models for so many of these things was just off. It assumed, you know, dozens of systems where then we were effectively having 100 of systems. And then there was all this FUD that vendors were throwing up. Like, they won't support you if you're on virtual infrastructure.
• 10:48
  So a a really interesting time period for that shift.
• 10:52
  Speaker 3: And I would say the Coro West situation was a bit different because this is like, Ekvizi. A venture capital allows you to go maybe 2 years. Like, magic term is prerevenue. Don't worry about making any money right now. Focus on adoption.
• 11:10
  And to be fair, addition to the funding part, some of this stuff was just better. There was no competition in the container space, really. There's not a lot in like configuration stores like etcd. You know, you had zookeeper, but that was also open. So that's where the bar was.
• 11:28
  So you had 2 things, I think, in the core west time. So that's a zooming forward a little bit. And in that time frame, open source is better, my opinion, and there was enough funding will allow you to go and focus on the community and focus on actually doing all the things we all enjoy about open source. But I think that's the anti pattern starts because a lot of people didn't realize how much money it cost to run these open source projects. Right?
• 11:57
  We went from, oh, download it and good luck if you can find documentation to there's a community manager with swag and stickers. Right? There's a whole lot more that went into open source, I think, in the last 10 years than the 10 years before it.
• 12:13
  Speaker 2: Totally agree. And I and I totally agree about, like, that is kinda where the end of patterns start. And so, yeah, maybe that's a good alright. So let's go through some of these, guy. I feel you you hit on, like, 4 of them right in there.
• 12:25
  So I wanna take it apart a little bit, and I I kinda think that, like, the lens is, know, someone who is looking for guidance for the coming decade. You know, what are some of the the things that when they see, they should say, like, wait a minute. This is, like, a a step down the a wrong step or a step down the wrong path. One of them that you mentioned is that, you know, you you're building these these downloads, you know, building community. And I think it is important, I and I think an anti pattern when you kinda see this kinda creeping into a company, it's a challenge.
• 12:55
  Downloads are not customers. They are downloads, and they're great, and it's exciting, and it means you've got a community and someone using it. But if you're building a business, you can't assume that you're gonna be able to directly monetize downloads into customers. I feel I mean, I don't know, Kelsey, but but what what's your take on that?
• 13:17
  Speaker 3: I mean, I think I saw for the other day. I didn't even think about it, and it should have been super obvious. People buy GitHub stars.
• 13:24
  Speaker 2: I know. I know.
• 13:26
  Speaker 3: That that part is when you're really doing you and the community a discount. Totally. Because people kind of use these metrics that signify the health of the project. They're the wrong metrics. Me, especially going through like the whole Kubernetes thing, you really wanna look at the sustainability long term.
• 13:47
  So typically, there's a lot of hype, especially from the companies funding these things. Being that initial traction, you're in out the enterprise product, you're on a line between open and paid. Then it comes to the point of what happens when primary funding company is doing most of the core work. I think we tend to step back and say, oh, those 5 people are going to take care of this project. Y'all can just download file issues and wait for them to get fixed.
• 14:20
  That to me is what I think is what some people believe open source is about, even though they won't say those words. A lot of people go through this idea that you big company that has tons of money, you should fund this thing for decades to come. If you don't, we will complain.
• 14:38
  Speaker 2: Right.
• 14:38
  Speaker 3: To me, I think the other part of open source has to be, are you willing? Take the responsibility to keep this thing going? Should said company decide they wanna go in another direction? And to me, I think this sustainability is probably the biggest anti pattern is that I think a lot of people on the other side of the equation get what their responsibilities in this thing. You need a lot more than just a handful of people within the skill step in and fork the process project if necessary, or at least be able to contribute in the low level boring aspects of it all.
• 15:18
  There's that other part that I think is even worse, which is the idea people should be working for free. I don't know how you solve this problem. It isn't sustainable for most maintainers to work on a project people use for production or profit free. That's tough.
• 15:36
  Speaker 2: Totally. And I think and you've got a couple different variants of that. Right? You've got these projects that are not associated with the company, but are really important to humanity. You know?
• 15:45
  And you've got, you know, Bash or OpenSSL or Curl, or you the one of these things that that lots of folks are using, and the and the software is still being developed. But there is no company around it, and it's not really and I think that, you know, the folks behind all of those projects have said, hey. Look. It's really hard to maintain this because there's a lot of work to do, and it's not clear how it's monetized. And I'm yeah.
• 16:09
  I'm I'm that that's a phony one. I'm not sure how I mean, in in in there I mean, you you certainly can have corporations act as kind of sponsors of individuals because they think the project is important, and that's happened in a couple of cases. But to your point about sustainability, Kelsey, that's not really a sustainable path.
• 16:28
  Speaker 3: And let's jump into, like, probably why we're here. Right? HashiCorp did a thing.
• 16:32
  Speaker 2: Yes.
• 16:33
  Speaker 3: Right. I remember my first contributions, to Terraform. Right? It was primarily Mitchell there. Maybe Armand was there as well.
• 16:41
  And remember someone from Google Cloud reached out to me and said, hey. You look like you've made some contributions to Entable. Seemed like you no go. We need some help bootstrapping the Google Cloud provider. And I remember getting in there, hacking on this thing, doing it wrong, and Mitchell stepping in and saying, hey, let me help you.
• 17:04
  Here's how it's supposed to work, etcetera, etcetera. So to me, it was very community oriented. And I think a lot of people contributed to Terraform to either scratch their own itch at a provider that they thought was missing or help rework its plug in system. So it was easier to use with other APIs. But either way, I think a lot of us volunteered our time.
• 17:27
  On the other hand, though, is I got to drop those contributions off.
• 17:30
  Speaker 2: Hey. You're right.
• 17:31
  Speaker 3: So I Right. They'll set a commit. I was done. I wasn't tracking the mailing list. I wasn't looking at bug reports.
• 17:41
  I dropped it off and I was out. The people who were maintaining Terraform, I think they had to pick that up. They have to own it. Once it's committed, it belongs to them, and they are stewards over that project. Now the question is, how long could they be leading a project without being able to decide where it goes next without necessarily buying from the community?
• 18:07
  That's where I think all of this stuff gets very tricky, especially someone that's been at Google for about I was at Google Cloud for 8 years. The whole thing behind the scenes with Kubernetes is that people the individuals, or everyone thinks there's, like, this evil empire behind these open source projects. Trust me, folks. Open source projects are not making executive board meeting discussions. It's not happening.
• 18:31
  Speaker 2: It will. And this was bigger
• 18:32
  Speaker 3: fish department.
• 18:32
  Speaker 2: Yeah. Totally. And Kelsey would just start to interrupt their embellish just for a second. When this has hit home for me when Craig McCluckkey was like, the reason that we need to get Kubernetes in foundation, we Google, is so we can get some marketing budget for Kubernetes. I'm like, don't you work for, like, the most profitable company on earth or whatever?
• 18:50
  It's like, really?
• 18:51
  Speaker 3: You said something super important is because things make $0.
• 18:55
  Speaker 1: Yeah.
• 18:57
  Speaker 3: They make no dollars. They cost money to run. 1,000,000 of dollars. If you think about it, you have 10 engineers. And really, these are not just full fresh out of college.
• 19:07
  These are some of your most senior engineers. Imagine taking just 10 of them. Average comp, 400 k, your 4,000,000 in. Just on people costs, bootstrap these projects just on the engineering side. So these aren't things that people are trying to, like, control the world.
• 19:25
  They're a bit to be honest, they're probably more liabilities Totally. Long term, than people realize them to be. So when a company like that decides that they may wanna pivot, have those people work on something else, what happens to the project?
• 19:44
  Speaker 2: Yeah. And so, I mean, is that a, I mean, certainly an argument for one of the things I I a decade ago, I was very jaundiced about things going into foundations, and a lot less jaundiced about that now, frankly. I mean, I think that there are, there are is there's a time and a place for things to be I definitely think open TF belongs to the foundation, and I think that the Linux Foundation is probably the right foundation for it. Even though it, it pained one of my coworkers greatly to upvote my comment on Hacker News saying same. It's like, I uploaded that.
• 20:16
  That was extremely painful to agree with you on that. But I think that that it does belong in the Linux Foundation. I think a lot of things do belong in a foundation. I mean, is that the I that's not a panacea, Kelsey, but is that part of the answer there?
• 20:29
  Speaker 3: I think it is going to be the only answer for infrastructure open source projects in particular need decades of support. Yeah. Let's Encrypt to me is the golden example in my opinion. It's not just a project, it's also a service. I think the lot of the contention we're having right now is around this service piece.
• 20:50
  Right? This is some of the more popular open source projects, switch their licenses because of the competition around the service. Right? I haven't heard a lot of argument around you're using my software. It's you're using my software to provide a service.
• 21:07
  And so, at some point, we have to realize, we're not just talking about software backed into some repository anymore. We're we're I think we're way past that. I think we're at the point now where there's a brand. Brand establishes trust and credibility. Then there's usually now service behind it.
• 21:25
  So it's not just Red Hat Linux. It's everything that Red Hat does behind that that you want to tap into. I think that's the part that is becoming super, super tricky. How do you do that sustainably? And look, if I had to argue on behalf of G Corp, if I look at Terraform in my portfolio, let's say it's not making a ton of cash.
• 21:45
  I don't know what it's making, but let's say it isn't. How many people do you have work on it full time? Community would say as many as it takes. You're a publicly traded company to some of those revenues and pay people to work on it. Let's say you just wanted to pivot or because the other thing, especially working at a cloud provider who depends on open source as part of their actual product portfolio that they sell to paying customers.
• 22:13
  It's only so far we can allow the community to dictate the roadmap. I think this is this anti pattern where you're not super clear about what the governance model truly is.
• 22:25
  Speaker 2: Yeah. What the leadership is.
• 22:26
  Speaker 3: People believe it's like it's a democracy. We'll all vote on GitHub issues. That's not usually how it works. Typically, there's hard lines that says, hey, you can never let their project go in that direction. They're for legal reasons, commercial reasons.
• 22:41
  And the anti pattern is not just being honest upfront saying, hey, this is a dictatorship. These are the dictators. This is what we're doing. This is what we're not doing. Fork button is up to the right.
• 22:57
  Speaker 2: Yeah. I think we would which is I mean, Kelsey, you would definitely find a lot to nod your head out of my talk a decade ago because that's basically exactly what I said is that the, that companies too often issue leadership when they shouldn't. I think, actually, the Hashi example, and I think some of these modern examples of which HashiCorp is kind of an exemplar, there are there are different though. So with with and I was actually surprised. I think, Adam, were you surprised when this side was?
• 23:22
  I was definitely I feel like I won't believe what it's
• 23:24
  Speaker 1: Oh, I was floored. Like, I I I think, like you, Kelsey, I thought that, you know, based on my experience with with Terraform and my understanding of, like, what what I could pay for in the Terraform ecosystem, I didn't think it would be a huge chunk of the revenue.
• 23:40
  Speaker 2: But according to them, that plus Vault is 85% of the revenue. So Terraform, they call out, in their their 10 k and 10 q as, being actually the lion's share of the revenue, which is shocking. And they don't I think, Adam, you and I also both assumed that and Kelsey, sounds like I this the perspective you're coming from too is that, like, your target in this relicensing must be one of the cloud providers offering a service. And it feels like I I mean, it it it well, not just feels like. I think it's pretty explicitly that, like, that's actually not the target.
• 24:16
  The target is these other folks that are offering their own Terraform variants. And they are building on the open source Terraform, and they actually are doing exactly what you described. If you don't like it, fork it. And the thing that I thought was a big reveal, Adam, that I definitely did not know about. I'd be very curious if you knew about this before you heard it last week, about Hashi basically closing themselves off to outside PRs for Terraform 2 years ago.
• 24:46
  And how that actually created a, there's a lot of kind of angst in the community. So I think the part of the problem to Kelsey, to your point about, like, not being direct about where they wanted to take it. I think in this case, like, where we wanna take it is direct monetization. Like, we wanna actually sell this as software, which I actually think is that is one of my kind of modern corp modern open source anti patterns is if you are an open source software company, you do not wanna run a software company playbook from the nineties or 2000s. And where people are paying to use it, and the more they use it, the more they pay.
• 25:25
  Because if you, one, you're creating a whole bunch of perverse incentives, in terms of all the problems, Kelsey, that you outlined in terms of, like, not actually wanting to use it because it's kinda combined. But then you are also because there is this open you are built on open source. You are now per you're competing with yourself effectively, and you are are are kind of incentivized to denigrate the open source offering. And I talked about this a little bit a decade ago with with, license based ports, where it's like, I'm gonna or rather a license based offering where, hey. This thing's available under a under, you know, a GPL, but if you wanna buy a a a proprietary version from me, I'll sell it to you.
• 26:05
  Same same software, different license. The what I think that we're with peep with folks that are, like, heavily monetizing support as Hashi is, they are saying, no. No. No. You can run the open source variant.
• 26:18
  But, you know, I don't know who's gonna who's gonna come help you in the middle of the night when Terraform doesn't work. Like, what? You're gonna file a GitHub issue on that? I mean, no one's gonna it's like only I can actually service this thing, which is not, like, a totally bad argument, but it it also puts you in direct opposition to what you might claim about the software and has definitely can you imagine being like, sorry. We're not gonna fix this data corruption problem.
• 26:44
  We actually need this to actually be able to sell more licenses.
• 26:47
  Speaker 1: So Yeah. This is a huge revenue trend radar in our services department.
• 26:52
  Speaker 2: Totally. It's like, but this is a huge call generator. I think
• 26:55
  Speaker 3: I think some good examples I think some good examples that has a clear kind of the line drawn in Sam would probably be Linux and Kubernetes. Linux isn't much without hardware to run it on. It isn't much without power. It isn't much without all the other things that go into it. So, you know, having a bunch of cloud providers agreed to use Linux across the board makes a lot of sense because you're not trying to monetize Linux directly.
• 27:22
  You're trying to monetize as a component of something else. Kubernetes made a really great decision, which was to, decouple the integration components, which is like the cloud provider module. The thing that, you know, what a node is, what a cluster is, how it auto scales, how it does networking, all of that is external. So when you get core Kubernetes, you still have to make, I don't know, 50 plus decisions about how it runs. And so when you go to a cloud provider, pretty much none of them are selling Kubernetes, selling a thing that is integrated into their cloud platform and give it a different name.
• 28:00
  And it makes it really clear what you're paying for. And if you don't like that, of course, you can run it yourself, but you're gonna have to make a lot of decisions and do a lot of work. I think the thing about Terraform is it's so good as is. Right? You don't really need a UI to use
• 28:17
  Speaker 2: it effectively.
• 28:17
  Speaker 3: Totally. Don't need, until they have the cloud stuff. You don't really need, like, authorization and LDAP, all that stuff integrated. So I think the service providers can actually do a pretty good job with, like, if Terraform breaks, you can call us. My guess is a lot of the things that are tending to break, the things that are like in the provider.
• 28:35
  Right? And you can go to fix those API calls. I think that's what makes your phone so tricky is that, yeah, they could actually see a market of people, that can actually outclass them in terms of supporting Terraform and taking them where they want to go. To me, I'm thinking this whole move will be good Terraform as a whole because now we get to find out what is actually core content, the cloud provider modules and the code you write. Is that stuff portable between this new thing open TF Terraform.
• 29:10
  And if it is, if that's gonna be portable, I think HashiCorp now has 2 implementations. And I think the community has to remind ourselves. Airform and HashiCorp came out pre c and CF. Yeah. If they were for that time period.
• 29:26
  And post c and CF, those companies I talk to, those cloud providers I talk to, they would not use a piece of infrastructure technology unless it was in a foundation first. Boy, that's And going forward
• 29:39
  Speaker 2: That's interesting to hear that from a a user perspective that c n because, you know, I always, like, thought that the CNCF landscape was a little bit ridiculous. The road map with the which just looks all these, like, postage stamps of technologies. But maybe I I I've been, understating its importance because it sounds like it makes it makes a real difference to people that are deploying infrastructure.
• 30:02
  Speaker 3: Because the CNCF, they don't tell you exactly how to govern your project. They don't tell you exactly where you must host it even though a lot of people choose GitHub. You can see I've gets a few things right upfront. IP needs to be very clear. Trademarks need to be very clear.
• 30:20
  And once you get those 2 things right, plus the software, I think a lot of the companies that have gone through this kind of, you know, like the whole Nginx thing before HashiCorp. I remember Nginx being the big thing around, hey, one more contributions to core. Especially anything that contribute or conflicts with our commercial endeavors. I remember that really put a stop to a lot of the momentum
• 30:44
  Speaker 2: Yeah.
• 30:44
  Speaker 3: It's on the NGINX community. So I think now that people have lived through this, I think going forward, people wanna know where's the IP? Are these trademarks about? Can I use them or not? Then what's the governance model?
• 30:57
  And I think CNCF now has shown that you can house a lot of these projects. Maybe they're not all getting all the attention and service that they need. But one thing is, if you're on the consumer side, you know what the IP is doing. You know what the trademarks about. And you know where the source code's gonna end up.
• 31:15
  So I think that part is we're not going backwards from Yeah.
• 31:18
  Speaker 2: And I think actually there's another thing, you know. And I had talked this in my talk a decade ago, but, boy, has this been sharpened. You know that copyrights are held by their contributors. And so you know that, actually, they can't stay in the CNCF and relicense. And for most of those projects, it's owned by all Sun, when people assigned their copyright to Sun, then saw it was Sun was bought by Oracle, and that could now you've actually signed your copyright to Oracle, which may actually not act in a way that that is in accordance with your wishes, and they certainly didn't.
• 31:57
  I I feel that that copyright assignment is a real problem. And I think that developers actually need to really start bridling, to the degree they're not already, at copyright assignment, and really understand what is in this CLA. Does this CLA is it a DCO effectively? Which is to say, a developer certificate of origin, which basically, like, hey. But this thing is I've got the right to do this, which to me satisfies this kind of boogeyman that we've never actually seen where someone comes back and litigates against an open source project because, you know, you've interrupt you've integrated my proprietary software into Kubernetes, and now I'm gonna go sue Google.
• 32:33
  It's like that didn't really happen.
• 32:35
  Speaker 1: It's also worth just before you breeze past that, that's used as a stalking horse in lots of these Yeah. Bucell conversions that, like, we need to do this, you know, some malicious or accidental copyright violation could sync sync everything otherwise. But worth noting, again, that this has not happened.
• 32:56
  Speaker 2: It has not happened, and it's also soul crushing for me to happen for that that Hashi's effectively making these claims, because Hashi is under the MPLV 2. And one of the things I like about MPLV 2 is there's a warranting of original work in the license. So you actually don't need a DCO with the MPLV 2. That's the beauty of the MPLV 2. So it's even more ludicrous to make that.
• 33:20
  And the MPLV 2 speaks to patents. I mean, there's a bunch of things that it's a great license. I like Apache 2 too, but I love the MPL v 2. And the there you shouldn't be able to make a lot of these claims. And I think Adam, it just kind of reveals the fact that people still do reveals it like, oh, it's not actually about the substance of the claims.
• 33:37
  It's like, oh, we're actually just trying to be proprietary proprietary software. It's you. It's like the new meme. It's like, oh, it's proprietary software.
• 33:45
  Speaker 3: I think an I think another anti pattern is our expectations of what open source needs to be. So so thank you, HashiCorp. There's a lot of economic activity has occurred inside and outside of HashiCorp because they chose to share their software. So if a big company were to figure out some grand problem, all they did would just drop off the software, did nothing else. To me, you could appreciate that.
• 34:20
  Like you could say, hey, thanks for this software. No company owes you great documentation. No company owes you videos. No company owes you bug fixes. That's that's extra.
• 34:34
  Getting that software to me is like that initial sharing of the ideas. Hey, here's a problem. It's how we solved it. This is helpful to you in its current form. You can use it too.
• 34:47
  And if you wanna build from there, that's up to you. But here's what we've chosen to share. I don't know if we applaud that as much as we should because we're so accustomed that just happening. But I do think it's an anti pattern that we look at that as not good enough in terms of what we're owed in terms of everything else.
• 35:07
  Speaker 2: I agree with you. I do think that we we you do be sure that we're being appreciative of the this especially infrastructure software that's open source. I I would say that also though, we, people need to every one of those companies I mean, like HashiCorp, itself was built on open source software. And itself, like, they do not have proprietary compilers or tooling. They would have in an earlier era, but they don't.
• 35:34
  They were able to deploy on open source operating systems with open source tooling. And obviously, an open source language in terms of Go. And so it's it which kind of dovetails into it to another one of my, I I think modern anti patterns. And Kelsey, I love your take on is the use of the term freeloaders. I think anytime someone is talking about freeloaders with respect to open source, you gotta shut it down because it's it's just it's too reductive.
• 36:00
  You know what I mean? Where it's like, look. We're all freeloaders here. We're we're all at some point, like, we are all using I mean, it is humanity's great collaboration, honestly, and we are no. There is no company that is building all of their own software, that you are we are all actually collaborating.
• 36:19
  So let's not let's just ditch the free letter term.
• 36:22
  Speaker 1: And you're free load freeloading on the shoulders of giants. Exactly.
• 36:25
  Speaker 2: You're all free loading. Yes. You really are. Yeah. And and we and I I think that, like, when, you know, that when that gets when that kinda seeps into the rhetoric.
• 36:34
  So, Kelsey, I agree with you that we we need to be appreciative to the to folks that are open sourcing their software, especially when they don't have to. But I also think it's important that that, like, we keep a perspective on the fact that by the way, that software couldn't have been built had it not been for the the the shoulders upon which we reload, Adam. So sorry. But
• 36:56
  Speaker 3: I definitely agree with that. I mean, that freeloader logic is so crazy because, like, the Earth, humans are just reloading while we're breathing all this
• 37:04
  Speaker 2: air. All this air.
• 37:05
  Speaker 3: Walking on all this ground, drinking all this water, and we just free Right. So that that that's kind of nonsense. I mean, open source. I mean, we've we've gotten to a point now where we are collectively building shared infrastructure. And I remember working at when I when I first left CoreOS to go to Google.
• 37:25
  I remember being at Google, and a lot of people really upset around Google adopting many other open source projects and and then commercializing them. And I was like, when you write that project in Golang,
• 37:40
  Speaker 2: what did you
• 37:40
  Speaker 3: pay? You paying anything to to use Golang? That count? Does does Googling?
• 37:47
  Speaker 2: Right. I think it should. I think it should.
• 37:50
  Speaker 3: Steve Groop's count.
• 37:51
  Speaker 2: Does does the
• 37:52
  Speaker 3: So, yeah, I think there's a
• 37:54
  Speaker 2: There's Node. Js count. I mean, because the the Node. Js also exists because of v 8, which I feel like v 8 is one of those things that definitely didn't have to be open sourced and was. And it was really important to get that open sourced.
• 38:06
  And I you know, I that's happening kinda right at the time when, like, the expectation is around, things are open source. But, yeah, it'll be we we are all building on this stuff. Yeah. And I that that is pretty funny. Like, I'm pretty sure you actually
• 38:21
  Speaker 3: I think you bring up the good point around accountability. So there's the appreciation piece. Hey. Thanks for putting this out there. We appreciate this initial drop.
• 38:31
  Now we all gotta be diligent about what this is. Is this a ticking time bomb? If I adopt this, am I gonna be on an island? So legal ramifications for using this. What's the legal ramifications for contributing to this?
• 38:45
  I think we have to think about that long game. And then look, I've been guilty of it as well. Sometimes they just drop off my contributions and don't think much about the license that I'm signing. Or what happens to the project going forward. We could do a better job with that.
• 38:58
  But I think the accountability piece is that, you must be willing to exercise your rights of forking the project, taking on the responsibility, have it go in the direction that you want. And if you're not, and I and I honestly think if you're not, I don't know how serious you are about open source. Right? This idea, I think a lot of people like the idea of downloading stuff for free. Having a community to learn from.
• 39:28
  Place to report issues and see them eventually get fixed. I think we all agree on that part. The other side of that equation, when someone like HashiCorp does what they do, accountability piece. Honestly, I was like, hey, people are piling up on HashiCorp. This isn't right.
• 39:44
  And Brian, you shared this video with Twitter. Oh, boy. The CEO of HashiCorp, and I was like, man, might be exaggerating sometimes. Not this time. You But I watched it, and he used the word malicious to describe their open source strategy as if they tricked people like me.
• 40:06
  We're contributing my free time. I was contributing and writing unit test because I actually cared about the quality of HashiCorp's tools. I was using HashiCorp tools. I just thought it was important to be a part of the community, not just as someone who's downloading, using things for free. But as a contributor, was willing to step up, not just fixing my own issues.
• 40:29
  I spent time in those chats helping other people get on board. Maybe I fixed the bugger too. To hear someone think that they were being malicious and that they tricked someone like me into contributing, then he doubled down on it by saying it again. I would say topic of this is corporate or enterprise anti patterns. Is the worst pattern ever.
• 40:54
  You're not tricking anyone at all. You should not refer to anyone who's taking their spare time to do anything in your project. I don't care if it's to correct the typo in the read me. You cannot think that you're some savvy 4 d chess playing software mastermind. You're not.
• 41:14
  You're just continuing lineage of how we've decided to build software together. So I think that part, I'm surprised the video is still out there to be fast.
• 41:24
  Speaker 2: I am shocked.
• 41:25
  Speaker 3: I definitely think that is that's the one I would say they should sit down and say, hey, you should not think of these people as malicious. And honestly, that's the attitude going forward. I can definitely see the community decide that they rather go use something where there isn't a malicious motive behind it.
• 41:44
  Speaker 2: And you're paying customers. I mean, it's like I like, when you say malicious and then double down on it with, like, it's the only word that fits is malicious. You're like, oh my god. What are you
• 41:55
  Speaker 3: doing?
• 41:57
  Speaker 2: And, I mean, Adam, you were obviously I as I think all 3 of us were shocked by that. I was Yeah. Bored by that.
• 42:03
  Speaker 1: Yeah. Floor floor that he doubled down as well.
• 42:07
  Speaker 3: Truth is you can probably make money for a long time even with that attitude. Let's just be honest. Like, oracles of the world exist. You can probably make a ton of cash in the short term by scaring people into paying for licenses. You can probably get away for a little while.
• 42:22
  I think in the domains in which they operate, it is easier to move to another solution. Absolutely. You can replace console. You can replace Vault, and you can replace Terraform. And so you have to have a different attitude when you're in that realm, because you can be replaced.
• 42:39
  And honestly, you can be replaced with your own software. The 4 button is still there.
• 42:44
  Speaker 1: That's right.
• 42:45
  Speaker 3: Right? And so you gotta be careful with that.
• 42:47
  Speaker 1: You know, in open source software did not invent community. And if you because we we've seen people helping each other with software since as long as there's been software for helping and contributing and participating. But if you are lucky enough to be at the helm of that ship that has grown a community that where you have people so passionate about what you've built and what they use, that they wanna help other people and fix typos and contribute code, man, you just gotta say thank you and and appreciate how fortunate you are. Because there are lots of folks who want to build communities and want to marshal that kind of enthusiasm and passion, and it's hard.
• 43:37
  Speaker 2: And, Adam, I maybe this is the example you have in mind, but you think about, like, all of the community that Apple built in its most proprietary era. Right? In the in kind of the eighties nineties and and early thousands where you had people who were excited to help one another and to evangelize the platform. And can you and you cannot imagine Steve Jobs saying, like, oh, by the way, this is, like this was malicious. This idea of having users help one another Yeah.
• 44:04
  Speaker 1: You're suckers.
• 44:05
  Speaker 2: Mouth. You're suckers. You're chumps. Right. It's what it it it just it it is and I I mean, it it was galling to me because I think as someone who also, like, pays for software as we do, and we, you know, we we consume things, we got a lot of suppliers.
• 44:21
  And boy, if I if if one of our suppliers were to say that, it's like, sorry, a commitment to our shared success is the bedrock of our relationship. It has to be. And I don't care who you are, but if we have if there's any economic transaction where Oxide is paying you, and you believe your strategy involves the word malicious in any way, it's like, no. I and it is I we if it's I don't care if it's UPS. I don't care if it's a contract manufacturer.
• 44:52
  I don't care if it's a design partner. It's like, we have to be committed to shared success. And that to me was just like, yeah, Kelsey, it's I I mean, it and it's, of course, like, thinking from I was thinking kind of from my own, honestly, outsider's perspective. But from your perspective to think, like, goddamn it. Like, I did a bunch of things for you that I did not have to do.
• 45:12
  I was yes. I was a, you know, I I had a you know, I was at Google or whatever. I was at Chorus. I was doing this, but I, like, I didn't have to do any of this stuff. I was doing it on my weekends.
• 45:20
  I was doing it because I wanted to help out people. And to think, like, I'm a chump now? I mean, that must have just been gutting to hear.
• 45:31
  Speaker 3: And I and I also think, you know, whatever margins you end up growing with the proprietary software, if we look at the patterns for over the last 20, 30 years in the world of open source, next project is coming for the margins. Period.
• 45:44
  Speaker 2: Oh. But
• 45:45
  Speaker 3: you already know that the target will be there. And remember in the cloud, very particularly, whenever you have, like, let's say you have a observability platform or container runtime. Moment that thing costs more than like cloud compute. It costs more than the VM that it runs on. Cost more than the thing that is being managed.
• 46:07
  That's when that profit becomes a target. There by the cloud provider that has to go and lower the barrier of entry to that type of software to their customers. Therefore, a them forking it or selling a competing version or you're just as something that requires a lot of service. And at some point, you're gonna see the service industry, it's pretty big, will come and try to fill that service gap. I think most people have to realize is that your open source game, then you have to realize that your position somewhat temporary.
• 46:40
  And the sustainability part is gonna require a lot of effort. And I think that brand comes so important. So the one thing I would say Shikorpe has going well for them, is is they have a wonderful brand and I'm gonna be fair with them. They have a wonderful track record, at least up into this point of doing the right thing by most of their users. So let's see how far that carries them, but it could definitely be unraveled through.
• 47:05
  You wanna see for the user community part is we want the actual competition.
• 47:10
  Speaker 2: You exactly. I mean, I think if you're a user, it's like, sorry. Actually, we'd like someone to be providing pricing pressure on you, please. That's right.
• 47:19
  Speaker 1: Yeah. The the the benefit of open source isn't is sort of the stalking horse of I could do it myself if you go out of business. But even more compelling is if I'm I'm using something open source and consuming and paying for services around it, if you, my vendor, starts being rapacious, well, other people will step in and provide the service more economically because they can't. Just like, you know, the the point of capitalism, as I understand it.
• 47:47
  Speaker 2: Well, and I I think that
• 47:48
  Speaker 3: It's a comment. Go ahead. There's a comment in the chat that talks about and I actually somewhat agree with this one. Group of passionate contributors can also be a burden. Yes.
• 48:00
  And you can you can imagine a situation where don't work at Google Cloud anymore, so I can use them as a hypothetical example. Imagine that you have a service, a compute service. Let's call it Cloud Run. And Cloud Run starts to make a ton of cash, and not only a ton of cash. Let's just say 10 years goes by, It has a particular API.
• 48:24
  It has to be backwards compatible to some degree. And it needs to have some era of or some guarantee of support going forward. And it needs to have very tight integrations for security reasons. Now the community comes along and says, hey. We would like this project to go in a completely different direction.
• 48:41
  At this point, you have to say no. This project will never go in that direction. To be honest with you all, this project is pretty much set in stone, except for this road map right here. So when that happens, I do think the challenge of having people who really, really wanna change things, really, really wanna experiment. How do you tell them no?
• 49:09
  And I think that probably other anti pattern. So one thing you can do to help you be able to say no without necessarily shutting things down completely is to have a great plugin and extension system. One thing that makes Terraform so great, one thing that makes Kubernetes so great, one thing that makes Linux so great, They do have extension interfaces. So if you need a new driver, you need a new integration. You don't need to come to core or get permission from the core maintainers to do that.
• 49:38
  I do think this thing around plug ins and really first class extensions. One of the rules a Kubernetes project was say we need to do something in the cloud. Like, for example, integrate with I'm Amazon has I'm Google has I'm a permission system that you wanna integrate deeply. Thing we did well was put the hooks in core, put the implementation outside. That way, everyone can do what they need to do with authorization, authentication.
• 50:08
  And And you don't necessarily have to have this situation where we start favoring 1 cloud provider over another.
• 50:14
  Speaker 2: That's a good point. And you you've gone to, like, but it does require the the project to kinda be interested in striking this balance of, like, we still want to encourage this kind of experimentation that may be not where we wanna take things, but we, but we we we wanna invest in the ability for you to go do that experimentation on our platform, which I think is not everyone wants to do, but I think it's it's important.
• 50:40
  Speaker 1: Hey, Kelsey. Something you've you've
• 50:42
  Speaker 3: now Brandon Burns.
• 50:43
  Speaker 1: Sorry. Real quick, Kelsey. So something you've now said twice, but I think is, you know, is worth highlighting is having that be really explicit about what everyone wants out of the relationship. Said and I think people are afraid. I think, companies sponsoring open source can be nervous about saying that it's a dictatorship, that we're never going down some particular path.
• 51:03
  And you might want it, but it's just not gonna happen. But to your point, I think that that is setting everyone up for for heartbreak later and being really explicit about what projects are and what projects aren't is really important.
• 51:17
  Speaker 3: I never contributed to OpenStack. Was an observer of how much pressure OpenStack had to evolve. A lot of those evolutions required painful changes to the core itself. Made upgrades hard. It made contributions hard.
• 51:34
  It was was hard. Remember when Kubernetes came out, Brendan Burns, one of the original founders of Kubernetes, was still at Google. He's really adamant about the custom resource definition. Not a 3rd party way of doing things, but a first class way of expressing Kubernetes APIs. That if you did it, you got all the same integrations that the core things had.
• 52:00
  So number 1, broke up the API into its own kind of domains. Then we had this concept of core, but it wasn't done in a way that if you were to build a third party thing, a new resource definition, you wanna manage to sell certificates. The way you did it was almost the same way that the core worked. And that release valve. So I think one of the biggest anti patterns is not thinking about that release valve.
• 52:27
  You know, we're one of going to do networking different. You know, people won't agree on the features and capabilities. And if you don't have that release file, it just becomes this pile of issues on, you know, all only the maintainers can solve. So I think having that outlet and designing your API around it for growth, I think that's probably the thing that we will see permanently change also in the future. You don't want to release an open source project, especially infrastructure.
• 52:55
  1 doesn't have a very clean and clear extension API, and you use that extension API yourself, build first party things. That way, the community and the core benefits from the same improvements over time.
• 53:11
  Speaker 2: Yeah. That's a really good point. And but it's gotta be, like, that important to you. And I I you know, I'm actually now really curious to know where Brendan was that coming from Omega or Borgmon, or was it or was it coming from other I mean, it feels like that's the kind of wisdom that only, scar tissue provides. And I'm curious now where that scar tissue would have come from in terms of it feels like because it does feel very wise, honestly, especially to have these APIs be used, by by the system itself.
• 53:40
  So they they are first class APIs.
• 53:44
  Speaker 3: And my first experience with that scar tissue was maybe with Docker. You know, when Docker came out, the Docker daemon was everything. You know, you built images with it.
• 53:53
  Speaker 2: Yeah.
• 53:53
  Speaker 3: Manage your repositories with it, and you ran, you know, processes with it. This API was very, very limited. I remember Solomon really doubled down on, batteries included but extendable. The problem was API that they would expose for networking was very limited. So you couldn't do very much.
• 54:15
  And you had to wait till Docker evolved and, you know, that creates a lot of the stress. On the Kubernetes world, you know, I worked on CNI when I was at Cro West. And I remember me and another person were designing, this networking layer. And, like, what should the API be? You know, you go through your modeling, like, what object types and, like, I think it should just literally be nothing.
• 54:35
  Like, let people slide into a namespace, configure the network. I don't care if they use Linux shell out commands. It doesn't matter. They return an IP address. And so that way you can support pretty much any networking stack, whether it was on the server or a larger fabric.
• 54:51
  You just made the API super open. And of course, we could always have libraries that made it easy to do common tasks.
• 54:57
  Speaker 2: Oh.
• 54:58
  Speaker 3: I think the scar tissue from, like, how Docker ran away with it all, but made it really, really hard to extend it in a way that was compatible with, bigger projects.
• 55:08
  Speaker 2: Absolutely. And so we and then we took the Docker API and implemented our own de novo daemon. We didn't use the Docker daemon. We basically had the Docker API plugged into our control plane, and Docker Inc was like, woah. Like, how are you how is that possible?
• 55:23
  It's like, well, you have an API. We're just implementing it. But it was not something that is also something they they did not view at all as a they they had no real commitment to the stability of that API, and it was just sloshing all over the place. And as you say, Kelsey, because of the batteries included approach, we were everyone was constantly kind locked on on Docker, either on the API to evolve or on the daemon to evolve. And it was just, that's interesting.
• 55:48
  I should've, of course, realized that that Kubernetes was a direct it wasn't so many other regards that they was learning from some of the mistakes that Docker had made. So, Chelsea, one thing I I I dying to ask you, because you kinda said this at the top, around the importance of DevRel. And I I think it is important, but I feel it's also there's a distinction between DevRel as done in a traditional proprietary software company in the, like, the Microsoft model, say, with which McJannet, the the CEO of HashiCorp sites directly as his inspiration. And in the video we were talking about earlier, they got 60 folks in DevRel. It's like, wow.
• 56:31
  That's a lot of folks in DevRel. How much of that DevRel is actual community building? I mean, is it is that a and I I actually asked this as an earnest question. I'm not trying to put my thumb on the scale because I actually don't. I mean, is is that the is traditional dev rel the right way to build a community?
• 56:47
  Is it effective at building a community?
• 56:51
  Speaker 3: Oh, I mean, look. I've never done DevRel until I got to Google. And probably still have never done DevRel because when I think about what DevRel is, it's very dependent on the person doing those that job role. If you're a person who used to use a piece of software in production, you're gonna be advocating probably for other people that use it in production or at least attempt to. And a lot of the things that you do, you may be focused on things like best practices, fixing bugs in the software, extensions, that kind of thing.
• 57:26
  Some people, very early in their career, don't have a lot of hands on experience. They may be super creative and you need that as well. That creativity could be creating killer tutorials. Amazing video editing. All kind of things that really help lower the barrier of entry to a person that's trying to learn something.
• 57:49
  So there's advocacy in terms of the want to make this material, this content, this software accessible to people. And you have some people that know how to build communities. That's what they specialize in. They've gone through great experiences building communities and bad experiences building communities. When those people enter into DevRel, they're gonna focus on the health of a project.
• 58:13
  Right? How many contributors do we have? The maintainers diverse across different companies. These are all different skill sets. I think what Deborah represents is software industry being very clear and intentional about that type of work needs to be done.
• 58:30
  Before it was called DevRel, I remember going to like, PyCon in the early days. All of those core developers used to give all the talks, used to sit with people that would have problems, help them fix their bugs, sit on IRC, them examples. Some of them created videos and demos, documentation. They just did it all. I mean, I remember when when Golan came out, Rob Pike.
• 58:58
  Jack. Oh, g. Rob Pike gave this beautiful presentation called Hello World. He just broke down every element all the way down to the assembly of how Go works by just showing people hello world. Me, that's a form of developer advocacy.
• 59:13
  So I think you're going to be in the new era of software, where people are attracted to community, meaning people prefer. If I have my choice between 2 open source project that do similar things, I'm probably gonna navigate towards one that has a community, meaning multiple people who use it in production, willing to share their experiences and teach people. Then I would like a group of people who can at least hear me out and say, no, we're not doing that. This is the wrong project. Maybe go try something else.
• 59:47
  I think that is now necessary skill set. Someone who wants to really do a good job and maintain software they expect other people to use And other people to use part is where the community piece comes in. So I think you're right. Some people have no idea what DevRel is. They're like, oh, big company x have DevRel.
• 1:00:08
  Let's hire some DevRel people. It's like, what do you want them to do? We want them to get us more GitHub stars. And you're failing. There's no guarantee.
• 1:00:19
  They're gonna get you more I mean, you can buy them now. I I've I've learned. But I think when we say advocacy, some companies are in just different phases. Some people are in the awareness phase. We have this wonderful software and it's free to download the low bar of accessibility to get into the software, but no one knows about it.
• 1:00:37
  The person you want now, it's someone who can go out into the world and raise awareness. And a lot of the people who maintain these softwares or these software projects have a huge following already because usually it's not their first project or maybe a domain expert has chosen to serialize their expertise into an open source project. But whether they admit it or not, they're doing a bit of evangelism. They're doing a bit of advocacy work themselves. So, okay, we have the awareness component.
• 1:01:10
  Other one is like the adoption problem. Like, hey, no one is using this thing. We put it out there. No one seems to care. We have to go find out why.
• 1:01:20
  Then, of course, you have the revenue side. Got this thing. Everyone's using it. We have no idea how to get people to pay for it. So we need to go find out what's missing to close that gap.
• 1:01:32
  So unless you know where you are on those phases, the print features in the same project can be in one of those phases at the same time. And that's how you want to think about advocacy. If you can afford it, sure. You can have a dedicated DevRel organization. To be honest, everyone at the company should learn how to do a little bit of advocacy for the things that they're building.
• 1:01:55
  Speaker 2: I absolutely agree with that. And I also think, Kelsey, do one of your all your points. It's like, if you're gonna have this kind of DevRel community advocacy function, please make sure it's sustainable. And make sure that you are that like, if you are doing this to get product market fit, that gets scary. That's when you get to, like, yeah.
• 1:02:13
  We don't have product market fit. We don't know how people are gonna pay for it. But we know downloads are up into the right, and we want them to go even more up into the right. So we're gonna add a bunch of DevRel folks. It it it you begin to get some sustainability questions about that about so what happens when you actually like, the DevRel folks are not gonna give you a path to monetization.
• 1:02:33
  They're simply gonna create more folks that are interested in the thing that you already don't know how to monetize. So it's not I think you
• 1:02:40
  Speaker 3: You can create a path to monetization. So one thing I remember the first time I got into DevRel, and my growth, my personal growth. As an engineer working on open source project, it was always find the thing that I thought was most important to the community, whether it had the most upvotes or it's something that the community talks about a lot as like a showstopper barrier, either a feature or a bug. As an engineer, I would fix that thing. It merged and then put it out in the world and hope people would actually use it.
• 1:03:12
  That was kind of the feedback loop. That was the cycle. And then sometimes that could represent like when I was working at Puppet Labs, we would show people what we were building at Puppet Conf, right? Every year or every quarter to a conference to show people what you were working on, and then they would tell you what they were doing so you can figure out how to align everything. That's what I did from a peer engineering mindset.
• 1:03:35
  Then remembered, there's a difference between community and customer. Right? 1 is willing to pay you money, what you do. They need something slightly different. So for me, I learned how to go from, like, hello world to hello revenue.
• 1:03:52
  It's very different. For example, if you're doing advocacy at that level where you want to also influence revenue, you have to also learn how to talk to people that cut checks, that spend money or spend time that they could be using somewhere else. Now, you have to go look at that gap and say, I notice 85% of our customers are using active directory.
• 1:04:16
  Speaker 2: Right?
• 1:04:17
  Speaker 3: I look at our project, we have 0 active directory integration. I got a feeling that if we added active directory integration, they would pay for it. It's the prototype. And Yeah. Then you have to measure it by saying how much revenue is coming in because of that feature.
• 1:04:38
  To me is that same pattern that we use for everything else apply to the revenue end of the spectrum.
• 1:04:44
  Speaker 2: I no. And I love that because that has that's basically taking it that that, you know, hey. Look. If you're in developer relations, you have this touch point with the way people are using the software, and use that touch point to look around you and gather data and ask questions and talk to folks who are maybe in the community now, but want to become customers. And, I I mean, I think that when folks are like, well, how do I build a business on on open source infrastructure?
• 1:05:09
  It's like, well, you you need to actually, like, find a product that you're gonna sell, and you need to do that by, like, talking to people and getting out and understanding why are you using my technology? What's valuable about it to you? What are the missing bits? What are the bits that you pay for? How can I create get more value for you?
• 1:05:27
  So ultimately, you wanna create so much value that you can go capture some of that and still feel like a win for the customer. And I feel like that bit is like a lot of these companies are losing the plot on that. And it's like, you can't just take what you got and monetize it. It's a lot more complicated than that, but it's a lot more fun too, because you get to learn how people are using the stuff, and go build things that they want you to build.
• 1:05:50
  Speaker 3: So Another anti pattern, I think that's probably the biggest. Sorry for shifting gears here.
• 1:05:55
  Speaker 2: No, please.
• 1:05:56
  Speaker 3: It's o is open sourcing the thing in the first place?
• 1:06:02
  Speaker 2: We found the antipathy.
• 1:06:03
  Speaker 3: A number of times.
• 1:06:04
  Speaker 2: Okay. This is good.
• 1:06:05
  Speaker 3: I would meet with a team, and they would say, we wanna open source this thing. I was like, show me the thing. Sit there patiently. I'm like, I'm a be honest with y'all. Nobody cares.
• 1:06:18
  I don't care. I'm surprised you care. This thing solves a problem that you don't even have. Are you using it? No.
• 1:06:28
  Speaker 2: Kelsey, is it routine for people to cry in these meetings? Like, oh my god. They put it down. They smile. Look down at your notebook.
• 1:06:34
  No.
• 1:06:34
  Speaker 3: No. No. No. No. No.
• 1:06:36
  They laughed because it's true.
• 1:06:38
  Speaker 2: Yeah. Right.
• 1:06:39
  Speaker 3: I'm saying, hey. Did you build this because you had nothing else to do? Like, how'd you know? I said, okay. No worries.
• 1:06:46
  No worries. Here's the thing. Let's just do a very basic open source checklist. Are you going to maintain this project for 10 years? Maybe like, no.
• 1:06:58
  I don't I'm gonna drop this thing off. Hopefully, it lands on hacker news, and I'm out. It's like, hey. It's an anti pattern.
• 1:07:07
  Speaker 1: Yeah.
• 1:07:08
  Speaker 3: If you just wanna drop this thing off, then the read me should say, hey. You're dropping this off. We have no intention reading any of your pull request, taking any of your bugs seriously. To be honest, we don't even use this thing. We are just trying to get the promotion and this was our best chance at doing so.
• 1:07:31
  Not use this thing in production. That's the type of honesty that you need to give to a project like that because I think anti pattern leads to brand damage. Have some of these larger companies that say, hey, open source project that isn't any good, I company x. Isn't helping. Just the active open sourcing doesn't help all by itself.
• 1:07:55
  I think sometimes you gotta have a slightly higher barrier. So the reason why I think it's an anti pattern, you open source at all or in the cases, sometimes you're open sourcing a little too early. Give you an example. Let's say you do have a thing that your company actually uses. Or you plan to have a commercial relationship of customers.
• 1:08:16
  Here's the thing. You need to get the roadmap right for the paying customer first. It means all the hard decisions. You don't want to be part of a democratic process. You need to go ahead and make those dictator like decisions for the paying customer.
• 1:08:32
  Get it locked down. Have a good idea what V1 will be. If you have a clear path to V1 and when you open source the thing, you can be very clear to the community. I think the Go project did a decent job, at least one that I was paying attention to. Golang came out and said, listen, this thing is not v one yet, but here's what it's going to take to v one.
• 1:08:55
  It was spelled out pretty clear. These are some things that we don't wanna keep. We're gonna break some stuff because this is our only chance. Because after v 1, we wanna keep it acquis compatible going forward. I think having a clear path to v one because I think for most enterprises and companies, it is your last chance.
• 1:09:15
  Take everything you've learned during the early stages of development of that project and fix them. Because I see a lot of open source projects get out too early, they get popular too early, is really painful for you to change any of the APIs because it's gonna disrupt a bunch of people.
• 1:09:33
  Speaker 2: Yes. I think that people talk about, like, the peril of having no one pay attention to your project, which is okay. That's one that's one failure mode. But another failure mode is, like, actually, a lot of people pay attention to your project, and people get really interested in it. And now you've got this constituency that you feel you need to serve, and it you you but you haven't figured out your your product yet, Kelsey, to your point.
• 1:09:54
  And that you you don't actually know, and now all of a sudden you're getting pulled apart in in 2 different directions. And, there's a there can be just a lot of discord, honestly, in the community. I think that this is I I would dovetail onto that. I would say that it's very important when you are opening something, especially something that for kind of the first time, you're gonna open source it. You wanna be pretty clear about what's important to you, about not just, like, what's on the road map, but these are the kinds of things that are important to us and not important to us.
• 1:10:24
  You know, we gave this this talk on on softwares or software platform as a reflection of values, reflecting on the divorce from Node. Js, and how it was really a values divergence more than anything else. And the fork was ultimately symptomatic of a pretty deep values. We so on this topic, Kelsey, a question that came up in the chat is like, hey, I'm kind of like, I'm not an infrastructure software. I'm, in this case, I am I'm I'm making software for teachers, or customers are teachers.
• 1:10:50
  I I'm I don't know whether I should open source it or not. I mean, I I feel that, like, if I open source it, it's a premise of license. People are gonna take it. I'm gonna get, you know, the the old kinda concern about, like, I'm I'm gonna be everyone's just gonna download it. No one's gonna buy it from me.
• 1:11:05
  Would would what's your your rubric for when to contemplate open sourcing software?
• 1:11:14
  Speaker 3: Yeah. Like, if I was selling I don't know. Let's say I was building an iOS app for my thermostat, And I and I wanna put it on the app store to charge money for it. It probably would not open source it till I figured out if there's gonna be a viable business or not. Because my goal is to sell it through the app store.
• 1:11:36
  That's my primary goal. And so, I'm not going to even flirt with the open source component until I go down that avenue. Number 1, I wanna learn what people actually are paying for. Because I think what some people forget is that initial drop is not the full lifetime of that software. What people really want is when new features come out, when new restrictions or regulations come up, I want someone there to be timely in fixing it.
• 1:12:06
  So, if you're building software for teachers, and more than likely, they're paying for that. They're paying for you to do all the things necessary, take their request, and have a meaningful SLA. And in many ways, it's like workflow insurance. Right? Here's the thing I can do.
• 1:12:24
  A workflow needs to change. The district is now using a new software to keep students grades and things. We are not developers. Right? We are educators.
• 1:12:35
  We would like you to integrate with that so we can use your software and continue doing so for years to come. It's typically what people are paying for, and so that subscription piece becomes a thing. Now here's the thing. Let's say you can't meet demand. You're maybe a 1 person shop.
• 1:12:54
  The customers you can handle, you can handle. And now you have to now you can make this decision. Well, I want to create an ecosystem. That's very different than just having people do exactly what you do. I mean, if you're just a one person show, you may not be able to service Europe.
• 1:13:11
  You may not ever be able to service these other continents because you just don't speak the language. You have no context there. You don't have a Salesforce. So now the question becomes, do you create
• 1:13:20
  Speaker 2: an ecosystem? A network effect?
• 1:13:22
  Speaker 3: If you create there's a network effect, but also it's just one of these things like no one's getting that money. The pie is too small. The pie is too small. It's you don't even have to worry about someone taking the revenue because it's not there. So I think once you figure out what the business model actually is, is it actually support backed by the software?
• 1:13:44
  The software improves as a manifestation of that support. What I would do is figure out what's what. And then let's say think about open source as we've seen, it's hard to take it back. So let's say we take that same example that you're building software for teachers. You say, you know what we're gonna do?
• 1:14:00
  An open source to connectors. The thing that connects to these weird school district, no proprietary back ends. I'm going to open source those pieces because, you know, there's a lot of people probably going through this. I want to do something good for the community. You all can have my connectors that I also use in my software.
• 1:14:19
  You can slowly tease out the parts that you believe could benefit from an ecosystem, meaning there's other people that are helping you maintain these kind of nuance little bits. It's a win for everybody, including you, but not a direct competition to your business. The other reason I would advocate for it is, let's say you're done with this. I wanna be in that business anymore, and creating this ecosystem means you don't want to leave the people who bet on you and that software higher and dry. I think one pattern we've seen is that kill switch kind of situation where I'm done with this.
• 1:14:52
  And it take the whole software package, clean it up, open source the whole thing. And I'm going to support it for another year or 2. But I'm gonna try my best to have the district, like, find a new maintainer, pass this thing off. Maybe someone doesn't have commercial interest, and they just want to keep the project alive. We've seen that happen with certain video games.
• 1:15:12
  I think my advice here would be you can't take it back. It's it's harder to take it back. To give pieces slowly, I would recommend go that direction versus open source, and I hope they will come. And when your feelings hurt when no one cares about your observatory
• 1:15:30
  Speaker 2: And I think I mean, I just love the way you're phrasing that. Like, know why you're doing this. Be able to answer the question of why you're doing this. And, I mean, for us at Oxide, where we we have open sourced effectively everything we've shipped on the rack, For us, it's important to give that transparency to our customers. We want we have been customers of proprietary firmware and software, and it sucks, And we wanna give that transparency for our so so there's this other goal that we've got that is and whether if people use our software, we think it's great.
• 1:15:59
  If you wanna use our software, that's terrific. But, ultimately, like, the reason it's open is for our customers. It is so our customers can see what exactly how exactly this thing is built, so it's not actually opaque to them. And that's that's probably not a not every company is gonna have that goal in in open source. And so for us, there are a bunch of things that don't actually matter as much that we're, you know, we are not actually I mean, we are not gonna spend a bunch of time in, you know we're not gonna hire someone to do Hubris DevRel.
• 1:16:32
  Sorry. If you were waiting to be
• 1:16:34
  Speaker 1: Wait. To be clear, Hubris Hubris is our embedded operating system. I I I hasten to point out just for
• 1:16:41
  Speaker 2: But is there a little bit of a problem? Don't point that out. I just
• 1:16:44
  Speaker 3: Oh, right.
• 1:16:45
  Speaker 1: I promise no context. Sorry.
• 1:16:46
  Speaker 2: They're right. No context. Like, listen, I'm sitting in the litter box and we're not gonna elaborate on that. So I don't know why we would
• 1:16:52
  Speaker 1: Fair enough.
• 1:16:53
  Speaker 2: But so yeah. Sorry. I we should explain that first, Kelsey. Hubris is our is, our Ross to de novo operating system that we run on the service process or in the root of trust. And we would love other people to use it.
• 1:17:05
  We think it's great, but we also are not, whether other people use it or not, is not really part of our business. The reason it's open is so our customers have that transparency. And and then someone else can fork it too. We want people to be able to do that and so on. We wanna inhibit that.
• 1:17:21
  It's under the MPLV 2, so people can do with it what they'd like, but, we are not going to be necessary I mean, we are gonna keep it in a direction that's consistent with the product that we're building. We try to be and you can let us know. We try to be very explicit about that in in our read mes and our contributing documents, because I think it is, you know, something you've hit on a couple of times, Kelsey, is just the importance of being direct with your community. Another question I'm just gonna ask you, just because it is the the kind of the, the the thing we've been circling. I mean, I really do think that copyright assignment is wrong in part because it allows for relicensing.
• 1:17:57
  I really do think this relicensing, I think, ignores the fact that you have a social contract with your contributors, and those contributors contributed under the idea that this is going to be I assigned copyright because I trusted you to basically continue to develop this thing under this license. To me, that social contract is really important. And and Kelsey is as the other one that was on the kind of the other end of that social contract with respect to HashiCorp, what the what's your take on that?
• 1:18:27
  Speaker 3: I mean, it depends. Really depends on my part because I think I'm being very transparent. 80% of the time, I don't care. I'm just being honest. I I just literally don't care.
• 1:18:40
  I remember doing a contribution to open policy agent, integrate with Google's I'm And it's their project. They have their own ecosystem. My only goal was to enable that ecosystem, views native Google Cloud's authorization protocols. It was like the only goal. And well, my unit test updated the documentation, work with the core team, got it committed, got it merged.
• 1:19:09
  Speaker 2: Correct.
• 1:19:11
  Speaker 3: I'm not I'm not tracking anything else. So, honestly, for me, giving them a copyright felt like me giving them the responsibility and the burden. They can do whatever they want with it in that scenario. But I were contributing under a different context. Meaning, let's say I was let's just use Terraform since that's kind of the hot topic right now.
• 1:19:34
  Say I was a service provider and I was providing a managed Terraform service. And one of my customers,
• 1:19:43
  Speaker 1: bug.
• 1:19:45
  Speaker 3: And I chose to fund the development of the fix for that bug. I am going to be looking over clearly. I give you this contribution back to the whole. I need to understand that is my copyright. Actually, not just my copyright, but I can't have you lock me back out of the thing I just fixed.
• 1:20:08
  That's where I would probably care a lot more about this thing. But also, I'll say this, the other anti pattern is, are you building businesses where you don't have this kind of clarity? It's the part where look. Ashford Court made a decision that some people don't agree with. And to me, a part of accountability, a part of this kind of democratic process we've used in some of these open source projects, have every right to voice your opinion.
• 1:20:33
  Also have to take accountability on the other side. How are you building businesses? You don't have a clear or certainty around the IP or the trademark. You built a whole business. You should have LLC, created a logo, opened a checking account.
• 1:20:50
  And the very thing that you built that business on, if someone were to ask you who owns the core IP behind your business and you say, I don't know.
• 1:20:59
  Speaker 1: Well, Kelsey Cook
• 1:21:00
  Speaker 3: I have no idea.
• 1:21:00
  Speaker 1: Question on that though. Wouldn't wouldn't you answer it's open source. It's open source and stewarded by a company that has a great reputation in open source.
• 1:21:13
  Speaker 3: Yeah. But that's there's no but here's the business piece, risk assessment. Now, I'll give you a good example. When Kubernetes came out, it it got wowly popular. I was still a I was contributing in my spare time while working at CoreOS because we had a competing offering called Fleet.
• 1:21:31
  Wasn't clear that Kubernetes would be super I
• 1:21:34
  Speaker 2: remember Fleet. Yeah.
• 1:21:36
  Speaker 3: So and so I was like, you know what? As I was contributing in nights and weekends, I went back to Alex Polvey and Brandon Phillips, like, yo, I think this is the thing. I plan to keep contributing to it. Hopefully, that's not creating any bad blood at the company at work. This thing, winning.
• 1:21:52
  So we decided, without doing all the legal stuff, that we would pivot to this thing. Now this is pre CNCF. But when we did this, I remember shortly after, maybe 6 months later, after we made the big pivot, joining Google, and I'm like, yo. This Kubernetes thing has a clear path. Amazon was like, we're not doing anything until we understand what the IP and the trademark is for doing this.
• 1:22:24
  People don't know, but there's a popular operating system that's Linux based. There are a lot of cloud providers didn't get this figured out until their customers started using said operating system. Then said operating system needed a chunk of that hourly fee. Never again will this happen because people understand. So open source is a thing, but I think now doing the risk assessment as Amazon did to Kubernetes, what we need to see is x, y, and z.
• 1:22:56
  IP needs to be clear. Trademarks need to be clear. We need to understand what happens. So you start asking basic questions. Can you change the license?
• 1:23:06
  And you limit the use of the trademark. We don't wanna go and spend a lot of marketing dollars on this name only to be told that we can never use it again. This is something we should learn now. Like, we have too many examples now where we know open source doesn't cover all of those things. Trademarks and all these other things are not covered.
• 1:23:28
  So now that we know, need to start asking that question. So I would say anyone that's upset by that decision, fully so. You also gotta go look at your own team and say, hey, maybe we don't understand the software business as well as we need to. Because before we start ever again in the future, building value add services or products on top of other things, we need to get clarity on the trademark and the IP. And look, I don't have experience at every large company, but just a few.
• 1:23:59
  One thing Google used to do pretty well is people used to always criticize Google with these bad product names. They did it on purpose. The purpose was to solve the trademark problem as well. Think about I'll use one public example that everyone kinda knows the story behind, but maybe they don't understand how it all links together. We were working on the new version of App Engine, k a now Cloud Run, which is container based.
• 1:24:24
  It's a lot of inspiration from the Kubernetes world. We built all these nice extensions to Kubernetes, creating the foundation for Cloud Run. Now it's time to open source this thing. We kind of knew we were going to open source it. Also did the right thing, we're making sure that it was going to do enough for what our customers are going to be.
• 1:24:42
  And we also thought about version skew. What happens when the enterprise version needs to skew from this open spec API thing? The other thing we thought about was the name. We called it Knative. And I was like, that's such a stupid name.
• 1:24:57
  It doesn't really mean anything. Means a whole bunch. It means not our commercial product is what it means. So you can use Knative in your marketing. You can say powered by Knative.
• 1:25:09
  No problem. Because we are not going to call the commercial thing k Native, and it's just super clear.
• 1:25:17
  Speaker 2: That's it. I mean, it's actually what we did with DTrace too. We did not we deliberately did not trademark DTrace to allow people to use it. And we because we were not gonna have a product named DTrace. So, it it was part of a larger system.
• 1:25:29
  That's really interesting. And and then, Kelsey, how do you square that with things like so, I mean, Go is not enough foundation. Right? Isn't Go just still a Google project?
• 1:25:40
  Speaker 3: Oh, it's interesting. You know, I've never worked on the Go team, so I can't speak authoritatively for the Go team. I think Go was a lot like the majority of the years of Python to me. Python was a bit clear. This is a big what is it?
• 1:25:56
  Speaker 1: BFL.
• 1:25:57
  Speaker 3: Nefelent Dictator. Yeah. Yeah. I'm making final decisions. I understand what the project needs, but at the same time, we can only go so far.
• 1:26:08
  And I think having that pet process is the release valve for people to at least no. I think the thing that the Python product Yeah. Yeah. Yeah. Did some early contribution right now.
• 1:26:17
  Speaker 2: That's alright.
• 1:26:17
  Speaker 3: The pet PEP is
• 1:26:18
  Speaker 2: I agree. Yep.
• 1:26:19
  Speaker 3: Yeah. Alright. No code. Do nothing. Specify what you want.
• 1:26:24
  Give us some examples. Let us iterate on the API. And if you're willing to do all of that, more than likely, you're gonna be able to change the language. Problem.
• 1:26:34
  Speaker 2: Or at least have the assurance that the language is not gonna you're not gonna wake up to the language trying to be rapacious suddenly.
• 1:26:41
  Speaker 3: Exactly. I think that is a good way to kind of phrase it. And, also, it's a great way to say no by saying yes. Hey. I would like this new feature from Haskell.
• 1:26:50
  No problem. Write up the pet for it.
• 1:26:52
  Speaker 2: Yeah. I'm
• 1:26:52
  Speaker 3: not doing all of that.
• 1:26:54
  Speaker 2: That's right.
• 1:26:54
  Speaker 3: Okay. Well, when we get around to it, we'll evaluate it.
• 1:26:57
  Speaker 1: Go fetch those stones and let us know.
• 1:26:59
  Speaker 2: Yeah. Well, that's actually a good point that, like, that the a foundation kinda gives you the assurance that there is at least some modicum of process for deciding what's in and what's out. And if you're gonna build your use this as foundation, knowing that either that such a process does exist is actually really important. And a foundation is one that kinda easy way to assure that. There may be others, but, yeah, this is interesting, Kelsey, in terms of, like, this kind of new era of open stores.
• 1:27:28
  Speaker 3: My personal preference, I like projects that have actual leadership.
• 1:27:33
  Speaker 2: Yeah. Me too. Like
• 1:27:35
  Speaker 3: Yeah. Because these things are typically reflective of the personalities who have created them, their philosophies, their way of doing things, their way of thinking about things. And ideally, the community then starts to take on that. Now, those people should learn. They should evolve.
• 1:27:48
  I do think a lot of people like curated things. When you go to a nightclub, you like the DJ. The DJ is important because they curate the music. When you go to a particular restaurant, the chef is important to curate the menu. Things you actually like, even though you may not say them out loud, you actually like these things.
• 1:28:07
  And when it comes to open source, again, I think one of the anti patterns on the community side is, you think this is a real democracy. You really think you can get enough support on a GitHub issue and I have to do it. Oh. Close button is there. It'll not fix is an option for me.
• 1:28:28
  So since that's how it works, I think the core contributors, the ones who probably are willing to be there long term and stick out these issues and have a bit more weight. And I think it's fair, especially if the some leading the project doing a good job. And I think in the case of Golang, going back to your example. Golang, I think their process and I'm not saying everyone has agreed with it because I think there's been some hiccups. Maybe the Go team could have been a little bit more clear.
• 1:28:54
  Like, hey, this is somewhat of it's not a singular person dictatorship because I think a lot of people own different parts of the go ecosystem. Those people tend to be trusted by the community to do the right thing, Like encryption, there's a person who kind of really focuses on that error area. And so I think they've been doing a good job for over 10 years. The collection of people have come and gone in those different parts. Been a bit of a trust ish, thing that has been granted to them.
• 1:29:25
  I think what the community is like, hey, how do we propose things and we know that it has been evaluated. Now, I'm gonna give a lot of credit to people like Russ Cox here is that, remember when Go was implementing modules. Right? We had no module system and the community stepped up, added 1. And I think it was like go depths.
• 1:29:44
  And honestly, became like the de facto standard. Like, most projects just started using it. Roscos looks at it and says, hey. Hold on. Hold on.
• 1:29:52
  Hold on. I see what you got here. This is pretty good. I have some ideas too. Boy, did those ideas represent, like, a 7 trillion page blog post about the diamond problem, the advances in dependency management, all the things that you have to think about.
• 1:30:10
  When I read it, I was like, wow, this level of analysis is super deep. I think he was able to focus on that level of analysis because there was a little bit of runway afforded to him by having it his eyes probably, temporary solution in place.
• 1:30:25
  Speaker 2: Yeah. Interesting.
• 1:30:26
  Speaker 3: And was a big rub about, I think, no longer being merged into the core, We would do something else instead. Those kind of things will happen in a set up this way. Now, to be honest with you, that's the reason why I think I like Golang. It has a clear personality of what it wants to be, what it doesn't want to be. I would hate, and I'm I've been learning Swift.
• 1:30:50
  Now the thing people use in the Apple ecosystem even though it's a open source language. Swift has every language feature I've ever seen in any programming language. Swift has it all.
• 1:31:01
  Speaker 2: Did you have tweeted about this? This this is my first and last day writing Swift or something like that. You had some to imply that I pushed through.
• 1:31:10
  Speaker 3: Push through. I I gave it 2 weeks. I actually built some things and some mock servers and some UI stuff, and they have some wonderful frameworks. To me, maybe I'm just late to that ecosystem. I don't know the history.
• 1:31:23
  It feels like everything is in there, and it lacks identity and personality for me.
• 1:31:29
  Speaker 2: So and what I think is just as you're describing this, I actually I just think so strongly that projects need to be very clear about their values. So because not all projects are gonna have the same values. And then I can I can get get some predictive power about whether you're gonna be receptive to this or not? I mean, in the Rust community, performance is really important. And if you have something that is gonna be performance and robustness are important.
• 1:31:52
  You're gonna make a big change that is not gonna perform well or not gonna be robust. Like, that change is not gonna go anywhere. And so it's like you you knowing kind of, like, what the the values are, help me engage, help us engage as a community to have and I think with Go, I think it's been some time sometimes I feel it's there and sometimes it feels very fickle, but, I would refer any and all to I love Go Lang. I hate Go Lang. Is that the order of your blog, Adam?
• 1:32:18
  Speaker 1: It is. Yes. Thank you.
• 1:32:20
  Speaker 3: Oh, I'll tell you what it feels like as a maintainer for this to happen. I had a project called Confdy, and I built it for a company I was working with. So we can actually have a lighter weight configuration management, because we just didn't need everything Puppet did. I used it in production. I open sourced it.
• 1:32:36
  People liked it and people used it. SG Corp team members used to use it as well. And I would do things like integrate console. First target with etcd. Console felt like it was also a key value store.
• 1:32:48
  No problem. Multiple back ends it is. Now, as someone who had experience at that time, told and promised myself that etcd would be the only back end I would ever support, the product didn't get bloated. I caved a little bit and just started adding, I don't know, DynamoDB stuff. It just got ridiculous.
• 1:33:06
  Remember someone came from HashiCorp team and said, hey, we wanna integrate Volt. Or yeah. It was Volt particularly. And I was like, you know what? No.
• 1:33:16
  Volt is not a key value store. Now things are just getting too much, and the answer is no. And so team responded with a thing called console template. It did. And it took a lot of inspiration from comp d, and I remember it was on Hacker News.
• 1:33:34
  It made it to the top. And someone said, this is a rip off of Kelsey's comp d project. They literally stole his idea. I commented, you can't steal what was given. It's an open source project for a reason.
• 1:33:51
  It's what happened. It contributed stuff in the past. And in this particular case, I said, no. They did what they were supposed to do. Made a different project with the same ideas.
• 1:34:06
  It gave them a place to do the things that they wanted. How can I be mad if anything? Feel kinda honored that I was able to nudge the industry in this kind of way. So this is what's supposed to happen. I said no, and they found a way to get to yes.
• 1:34:22
  This is what open source to me is also about.
• 1:34:26
  Speaker 2: Yeah. And I love just I'm on the hacker news story. Introducing console template with your top right comment of, hey. Confity author here, trying to to bring some some clarity. That's really, really interesting.
• 1:34:40
  That is really interesting. And that and, I mean, I think, honestly, a, kind of a great spot, here, I think, to, Kelsey, thank you so much. I mean, we you know, you've got you've been such a, I think, an inspiration to so many folks, and I think so many people, you you've you've got such a such wisdom, and really appreciate you sharing so much of it with us today. I mean, this has been, really, really fun. And, and and you're welcome.
• 1:35:14
  But we're, you're you're in the new post Twitter spaces rule here, so, you know, no audio problem.
• 1:35:19
  Speaker 3: I did think definitely think I would check it. I think I think I might use this going forward, but I wanna end with one thing.
• 1:35:24
  Speaker 2: Yeah.
• 1:35:24
  Speaker 3: Absolutely. One anti pattern that I think we need to just remember all of this. And though you think there's big companies behind all of these big projects, and know the title of this is like corporate open source anti patterns. You wouldn't believe is that a lot of times, even if these companies have like 100,000 plus employees, typically, it's only like 5 or 10 people who actually work on a lot of these projects. So they have feelings and emotions.
• 1:35:49
  They pay attention to the good and the bad. Sometimes, take a moment and realize that the maintainers are not necessarily pledging allegiance to the company. Doing this on behalf of you, advocating for you. And a lot of times, they're putting their careers on the line. Work on these open source projects, instead of the things that actually make the company money.
• 1:36:11
  The one anti pattern I wanna make sure that we realize is that software doesn't write itself. So the people behind these projects, the community managers, the documentation folks, the people just helping out in IRC or Slack or whatever you're using these days. Those are just real people. So just take a moment to pause. Just make sure you know that you're talking to real people when we're debating these things.
• 1:36:35
  Speaker 2: Amen. Amen. I think that is a these are all people all working together. And, I mean, I think it's it's honestly I think, you know, we talked with this a couple weeks ago about the things that have been real revolutions in software and sharing are those things that have facilitated collaboration. And open source has facilitated collaboration on a way that we honestly haven't seen it done before, for the way we build things.
• 1:37:00
  The open source allows us to collaborate across all these different boundaries, And it really is remarkable when but at the at the the bottom of it are are the at the roots are people actually working together. So
• 1:37:14
  Speaker 1: Yeah. People deserving of kindness. Absolutely right.
• 1:37:18
  Speaker 2: Kindness and not malice.
• 1:37:20
  Speaker 1: That's right.
• 1:37:22
  Speaker 2: The, yes. Please leave the maliciousness the intent to do harm. You can please leave out of the business strategy. If that's part of your business strategy, please never say it out loud. And definitely don't say it out loud in a recorded venue.
• 1:37:36
  But, hey, Kelsey, this has been great. Thank you so much. Hey. We want to, so we're coming up on a big anniversary right here, Adam. We are.
• 1:37:45
  On September 3rd. Right? I think it's the it was September 3, 2003 that we integrated DTrace. And, it's software that you and I still use basically every day. I mean, this is software that we both have continued to evolve and software that, we are continuing to make improvements to.
• 1:38:10
  So, I think next time, we're gonna be doing dtrace at 20. It's, 20 years old. And reflecting back on what it's like to have to to live with the software you wrote 20 years later, there's a lot to talk about. So
• 1:38:23
  Speaker 1: Yeah. I'm looking forward to it.
• 1:38:24
  Speaker 2: Looking forward to it too. Kelsey, we cannot thank you enough. That was absolutely awesome, and thank you so much, everybody. Speaking of community, we really value all the all of you and, all the the the great engagement in the chat. So thank you very much, truly, Oxide and Friends.
• 1:38:41
  Thanks, everyone. See you next time.