ANTHOLOGY — The Way of Open Source  ## Metadata - Author: [[Changelog Master Feed]] - Full Title: ANTHOLOGY — The Way of Open Source - Category: #podcasts - URL: https://share.snipd.com/episode/b18b17fe-d6a5-493a-9891-1fac000f6111 ## Document Notes ## Highlights - **Terraform License Change Shock** - Matthew Sanabria shared his experience leaving HashiCorp after nearly five years amid the Terraform license change shock. - He revealed engineers learned about the change the same day as the public, causing internal surprise and dissatisfaction. Transcript: Speaker 2 Life. Yeah. Speaker 3 What's happened? What's going on? How do you feel? Speaker 2 I feel good. I feel good. So, last two weeks I left my job. What did you work? I worked at a HashiCorp. I've heard of them. Yeah. I was there for about five years. It was a long time. It was a while. Four years, ten months or whatever it was. And what did you do there? I started in support engineering, went to software engineering for Terra from Enterprise, got promoted there, went that route. But when I left, I was pretty much the Terra from Enterprise subject matter expert working on Terra from Enterprise. So, yeah, software engineering, bunch of like Docker, Go, Kubernetes things. Yeah. Pretty fun. Speaker 3 Yeah. It's funny what he said, Terraform there. I'm not even kidding with you. I legit thought he said Tofu. Speaker 8 You're kidding me, are you? No. I really am not kidding you. They don't have any Tofu there. I thought he said I was on the Tofu Enterprise team. Speaker 2 I ate some Tofu, but I never used it. Yeah, it was, that was a fun, that announcement. The license change announcement was a very fun time at HashiCorp. I will say. Tell us about it from the inside. I mean, I wish I could come up here and say like the inside was different in the sense of like we were made aware and you know, we had all this notice and it wasn't. We found out at the same time you all found out. So from the inside, the same day that you all found out, the announcement, that's how we found out, which doesn't really inspire a lot of like, you know, it didn't make me happy. Speaker 3 I will say. Well, we're not asking you to do, just to be clear, just to talk smack. Yeah. I think what these podcasts serve as in my opinion is like the facts of what really happened in the sentiment, right? It's less like, oh, they're bad and open source good. It's more like, what really happened? So that one, we just know as developers, because there's an assumption from the outside, oh, people knew in advance and this was orchestrated. Well, maybe it wasn't some level. So I just talked to somebody else in Devavicacy today and she said they knew three days in advance. Yeah. So Devavicacy knew maybe a couple of days in advance. Yeah. But engineers, senior engineers on the tofu, I mean, the terraform team. Speaker 8 I didn't know. Speaker 2 Like Hashikrabs is an interesting company, right? Because they're like a company of companies, if you think about it, right? They have multiple projects, right? Nomad, vol, terraform console, they agree with all of their projects. They have a bunch of projects. And each of those teams kind of operates by, you know, in autonomy by themselves. They contribute to each other's code base. They have shared libraries and stuff. But for the most part, terraform, terraform, volts, vol, nomads, nomad. So from the terraform side, we were pretty shocked. And mind you, I was on terraform enterprise, right? So our license or all that has never changed. Tear from open source change. So I wasn't on the Tear from open source team. Maybe they knew it in advance. But for me, on the Tear from enterprise team, we did not know in advance. Speaker 3 I guess it kind of makes sense to some degree that enterprises doesn't need to know. Right. Because you don't really, not so much care, but it's your underpinnings. You're the customers that are buying the open source. And the customers that are buying the enterprise product are paying for it. Right. Speaker 2 And they're going through that sales process anyway, right? Speaker 3 I think, though, when you make a major shift like that, the story arc quickly for Hashi Corp. Mitchell Hashimoto created it years ago when he created Vagrant. Actually, a couple years after Vagrant, it was successful enough to create a company that created products that lived in open core, but also had paid models around it. It was very successful. So successful that they IPO'd your part of that company. Speaker 2 I was very, very happy for that, of course. Speaker 3 Which is a great thing. And I think when you're at that level, you probably should communicate to the people around you and your company to say, is this a wise move? Yeah. We are so ingrained given that success in the dev culture and the dev community. Terraform is such a used software that they, the community was like, that's not cool. We're going to fork it and make our own thing. It's that it was that impactful. When you make software tools and products that are that impactful, you probably should ask for, is this the right way to handle it? Agreed. Can we do it? Is there a better way? Speaker 2 I mean, looking at the open source repos, there's definitely people that are happy to use HashUgoer products. They love the products. They are very active on the issues, pull requests and all of that. And yeah, there was a time where Terraform was short staffed and there was a public read me update or an issue where they told the community, hey, we're a little short staffed in the next Couple of months. Let's, you know, we're going to slow down and reviewing open PRs. But that was communicated. And yeah, the community looks at that and says, hey, you know, like, hey, what's going on with Terraform? They're just communicated to the community and they're aware, right? They're kept in the loop. That's something that I would have probably expected to happen with the projects, with the license change. But that didn't happen. So I was kind of a shock about that, right? Like, you would expect that to have been communicated to the community more in advance. I guess is what I'm trying to say. Yeah. You know, so it's kind of a shock when it wasn't. Did you leave because of that or? That was one of the motivating factors of why I left, right? It was just the shift in the engineering culture, like move away towards that more product culture. Kind of did it for me, right? I mean, when I joined Hashtagorp, there was about 350 people. When I left, there was about 2000. And obviously I went through the IPL with them and whatnot. So that was one of the reasons too. Yeah. You know, it's like you're no longer working on open source. ([Time 0:05:22](https://share.snipd.com/snip/7c0613ac-2f2f-4c83-aa06-4fdd7f427fdb)) - **OpenTofu’s Small Yet Focused Team** - OpenTofu's core engineering team is small but focused, roughly 15 engineers on the Terraform open source core. - Company support logos abound, but true long-term commitment remains an open question. Transcript: Speaker 2 There's only about a handful of engineers that work on the core core. So can Open Tofu pull it off with their 15 or so engineers? I don't see why not. Yeah, right. I think my worry with them is a lot of companies are coming together to work on Open Tofu, and maybe for now the companies have an alignment on where they're going, but will that always Remain? Hard to say, right? Speaker 5 What happens when conflict arises, and one company wants to go one way and one wants to go the other way? ([Time 0:20:51](https://share.snipd.com/snip/773c509e-59c5-40fb-83ea-430f2299c446)) - **Amazon's OSPO Connects Builders & Community** - Amazon's Open Source Program Office (OSPO) acts as a bridge between open source communities and Amazon's builders. - They streamline open source use, contributions, compliance, and community engagement across the company. Transcript: Speaker 4 Open source is really central to how we build our products, how we build our infrastructure, how we build our services. It's a key component in everything we build. So all of our builders, all of our developers, we call our developers builders because they're building something, right? Software builders. Our job in the open source program office is to make it dead easy for our builders to work with open source so that from the time they consume, to contribute, to release, to distribute, To comply, or to engage with open source, we want to educate them on the easy way to do things, the norms of open source, build it into our workflow so that they don't have to open a ticket To ask us permission to use something or work with something. So our job is to let them innovate with open source freely and openly. And we also play another role which is work with foundations, open source communities, projects, people so that they know how to navigate Amazon. We help them navigate within Amazon as to who to connect with, who's doing what from an open source perspective. And so we kind of are the bridge between open source community and Amazon. ([Time 0:38:39](https://share.snipd.com/snip/a8c3bcbd-60fb-45d2-a76c-a34cc520eee7)) - **Simplify Open Source Policies** - OSPOs should simplify open source policies, allowing many licenses to be automatically approved without permissions. - This reduces friction for developers using and contributing to open source, boosting adoption and compliance. Transcript: Speaker 4 There? One of the easy things Ospo's can do is to create easier policies. So in a very restrictive regime, you can make developers ask for permission, go to lawyers and ask for permission for everything they use, which will deter them from using open source. So we streamline and we make sure that a lot of open source licenses are already green lighted and that they automatically flow through the system without a ticket being cut or permission Being asked. So that's one easy way you make it easy for people to consume it. We have relaxed some of the rules for contribution back. If it's a simple contribution, you don't even have to cut a ticket. You can just go contribute. Even for releasing software, we have something called simple releases. So if it is a sample or a scientific work, etc., you don't even have to cut a ticket. You can just release it. And even the rules for reviewing bigger release of projects and stuff, we really work with the business to help them see what the business reason is for contributing and how to run a successful Project once you're contributed. Because you just don't want to dump it on GitHub and run. You want to be able to maintain it, build a community, a neutral governance, all that stuff. So we kind of make it easy in that fashion for business owners to know that we are here to support you and make it easier for you to do open source. ([Time 0:42:39](https://share.snipd.com/snip/25aee323-c486-4134-9424-e1ac3571d7eb)) - **Amazon’s Open Source Approval Process** - Amazon guides open source project approval through documentation, legal review, and security checks. - They help with licensing, repo setup, and maintaining good project governance to ensure community success. Transcript: Speaker 4 They typically have to write a document. We are big doc writers at Amazon. So they have to write a doc to get approval from their business, their manager and their business owner that this is OK to open source. And typically, their business line lawyer may be involved in approving that. And then once it's approved, they come to the open source program office, we help them go through security review of the code. We help them do something called, it's an open source project called repo linter, which looks through your code and makes sure that you haven't got keys and any proprietary information, Et cetera. So it sanitizes it. We help them attach an Apache 2.0 license. We make sure that they have a read me file, code of conduct, et cetera. And then I have a GitHub team also, who administers our external GitHub. They help them cut a ticket to open a repo, put it in the right org. We have a samples org. We have a lab org where all the lab papers are published. And so they'll put it in the right org. And they'll also monitor the org, making sure it has a proper maintainer, issues are not stale, that we are being good citizens on the project. ([Time 0:55:07](https://share.snipd.com/snip/8f7fd4a7-bfe5-4946-8c92-388d806e2a8f)) - **Temporal API Poised for Adoption** - Temporal is a new JavaScript date/time API improving reliability and localization compared to existing Date objects. - It's been in stage three for two years, and stability signs indicate it may soon be ready for production use. Transcript: Speaker 1 Yeah, let's see. So I maintain 400 450 some NPM packages as well as NVM. They account for like 5 to 10% of NPM download traffic, which is terrifyingly high. I've been on TC 39, which is the JavaScript Standards Committee. Right. Since 2014, I was an editor of the spec for three years. Long time. Yeah. Speaker 5 When do you sleep then? Speaker 1 Well, I in between, you know, open source and taking care of my kids, I squeeze in a few hours here and there. Wow. You know, 450 repositories. Surely those don't those don't all require active maintenance. No, the vast majority of them are effectively done and only need occasional like dependency updates and things like that. So it's, you know, there's it's the 80 20 thing, right? 20% of the packages take 80% of my time. Right. You know, the rest are pretty self self-sufficient. OK. Speaker 5 From the TC 39 lens, when is temporal coming? Speaker 1 So can we use this? Yeah. So that when can we use it as the right question? So temporal has been stage three for two years now. Stage three usually is the time to signal, hey, browsers, you can ship this, users, you can start using it. However, temporal has had what we call normative changes, like observable changes from JavaScript. For almost every two months since it got stage three, which to me tells me it's not ready. Like, it's because changes or it's minor API changes, some semantic changes. It's because it's such a large and complex proposal that it was largely impossible to thoroughly review it before it got to stage three. Speaker 5 Everyone took it back. Tell him what it is. He doesn't know what it is. Speaker 1 Yeah. So, Tell me. Have you ever written code with the data object in JavaScript? Yeah. So you may realize that the data object sucks. It is awful. OK. It's API is terrible. It's like, I haven't used it enough to know that. That's fine, but it's a lot of things. Yeah. It's like mutable so you can change it all the time, which means it's hard to keep track of what things are. It can't be trusted. It has really poor support for localization and all the different time zones in the world. And it's really hard to do date and time math that's reliable and so on. So, Temporal is a proposal that was originally championed by the Moment.js maintainers that it basically provides like, I think it's seven new globals that are all under the Temporal Object that allow you to do like reasonable date time operations. And so it takes a lot of inspiration from actually a Java library called JotaTime. And although I'm not a big fan of Java or taking inspiration from Java, like this actually is a Java library that's done things really right. And we've still, of course, made some tweaks to make it fit JavaScript idioms. You don't like Java? That's a topic for another time. OK. All right. Fair enough. But either way, you'll be able to create a timestamp effectively as one object. You'll be able to create your birthday. That doesn't have a time associated with it. So you'll be able to create just a day, year and month. And that's all it represents. You'll be able to create a duration, like an object that spans two timestamps. And you'll be able to do reasonable things with that. So it's going to make working with dates and times infinitely easier and less painful in JavaScript. So I'm very excited, as are a lot of other people, about being able to use this. As am I, hence I say, when can I use it? Exactly. So OK, so it's been in, it's a third phase. It's been working on a while. First stage is zero through four. OK. Four is when it lands in the spec. Three is usually when things start shipping it and when you can use it. And it's been in stage three for two years. But we just had a TC39 meeting two or three weeks ago. And that was the first TC39 meeting since it got stage three that there were no normative changes to it. Speaker 5 OK, so I'm down. Yes. Speaker 1 So it's settling down exactly. And I'm holding my breath because if at the next TC39 meeting, it doesn't have any normative changes. That's when like, so I'm a polyfill maintainer. I have like a hundred plus different polyfills for language features. So if in the next TC39 meeting, it doesn't have any normative changes. To me, that tells me it's ready for me to start implementing it as a polyfill. Yeah. Which, you know, everybody can have their own signals. You don't have to rely on just what I say. But if I feel like it's worthy for a polyfill, that's when I'm going to start recommending people use it in production. Because at that point, it's stable enough. And there is an available to use, but just not stable. So you shouldn't use it. Basically, that's exactly right. There are polyfills out there, but they don't typically a polyfill tries to be as backwards compatible as possible. So you can use the new feature in the oldest possible environments. The polyfills that are currently available don't have that as a goal. They're just trying to replicate the API in modern features with modern features. So that's good enough if you happen to be supporting like just the latest Chrome or something. But most production web apps need to support farther back than that in every browser. And so in addition to that, there's those API changes I told you about. So that's why I would say you shouldn't have been using it in production yet. But now that the API is settling down, I'm hoping that that will change and we'll all be able to start using it. ([Time 1:04:36](https://share.snipd.com/snip/3b58de60-e27b-43f4-8c18-c8e29deb8aa7)) - **Open Source Maintainer’s Funding Struggle** - Jordan Harband manages hundreds of NPM packages vital to JS ecosystem but struggles financially from open source maintenance. - Despite high usage, corporate sponsorships are too low; he appeals to companies to contribute. Transcript: Speaker 1 I would say that the amount I make off of my projects is I'm very grateful for it. And it's enough that if I were single and in my twenties, I could do it full time. But I am not single and I have kids and I'm not in my twenties. And it just doesn't cover the bills. So I've done the math and if my most lucrative package, like I look at my most lucrative package and then I look at my most used package and if I extrapolated all that out for all my packages, I would be able to do open source full time. But at the moment, that's not the case. So I would definitely be very happy to see a world where all of the profitable corporations that are using, you know, people's open source packages might included are able to contribute Even a tiny fraction of their profit. At that point, I think it will become a much more viable world for open source maintainers. Speaker 5 What accounts for the diff between those two things? Speaker 1 I just think it's because there's no like so this is capitalism, the world we live in, right? Sure. Which means that there's only two levers you can apply capital and regulation. And there's no regulation that's forcing anyone to contribute to their, you know, tech infrastructure. They're open source tech infrastructure. You could perhaps look at fiduciary duty and say that they do in fact have a requirement, but it's not enforced in that way at least. So without the regulation, there needs to be a capital incentive for them to do it. And there is one. It's just a really hard one to... Is that invisible sometimes? Yeah, it's invisible. It's really hard to talk about it in a way that's quantifiable. You can point to and be like, you have risked this amount of money because you didn't invest in this thing. It's like really hard to demonstrate an ROI or impact to the bottom line. Right. But it absolutely, I think, ties like couples to everyone's bottom line and that if you don't maintain your infrastructure, it's going to crumble and fall apart. And then there goes your company. Speaker 5 So when we go back to your packages and talk about the most supported. Yeah. And then the most used. Those are different, right? Yeah. Why is the most used, not the most supported? Speaker 1 I think part of that is because most of my packages are end up being people's transitive dependencies. So like most of my stuff isn't like Babel or ESLint or Webpack where people are choosing it. Right. Most of my stuff is chosen by the maintainers of those packages or three or four levels deep. Right. And so even though my code is in almost every application on the planet, like the number of people that have chosen me is very small. Right. And so I think that's a big part of it. I think also that the specific organizations that have chosen to give back are just going to always use some subset of what's out there. And so what I'm seeing, I think, is that the ones that are most supported just happen to be in that subset. Like, I don't know if there's a good rationale for it. Yeah. It might just be the way it is. Speaker 5 I kind of see it as like a movie and you have your Scarlett Johansson and then you have your audio engineer. Yeah. And it's like they're both crucial. Right. And maybe she knows that this is the best audio engineer in the world. And so he's coming with me or whatever. Yeah. But the studio doesn't. Speaker 1 And I think that's exactly right. Like when everyone watches the Academy Awards or whatever, everyone pays real close attention to the best actor or actress, but they don't pay as much attention to like the best sound Guy or the best costume person or whatever, even though the industry knows that those are the best people and really wants to hire them. Speaker 5 In fact, even at the Oscars, I think they have like the engineering style Oscars have their own separate bank. Exactly. Speaker 1 The day before or whatever. Because they don't bear it on TV. Right. Yeah. Speaker 5 Right. So it's kind of that same problem in a different situation. Speaker 1 But the crucial difference here though is that that's a business and industry and they, the money that comes in from the actors, the well known faces does in fact filter back to all the People who support it. But in open source, no one's paying any money for the software. So there's nothing to filter back to all those transitive authors, which is in fact why I really like sites like Tydlift and Thanks.dev. They are the ones like get up sponsors and open collective and so on are great. But Tydlift and Thanks.dev really focus on kind of surfacing and filtering the money through to all the transitive dependencies. So folks like me who are the backbone of all of these projects actually get see some of that support. Whereas with GitHub sponsors, you know, people don't know who I am to go click on me and support myself. Right. Speaker 3 How can we get you more well known to the people that use you via transient dependencies? Like why that's a great question. That visibility. Speaker 1 I wish I knew the answer to that. That's the question here. Certainly I think part of it is is the kind of the skills that it takes to be a good engineer are very different than the skills it takes to be a good manager. And they're very different from the skills that it takes to be a good influencer or promoter. Right. These are all there's overlap, but they're all distinct skill sets. Yeah. And some people have the skill set to like go on make a Twitch stream every day or write blogs, you know, periodically or like tweet the exact right hot takes, you know, and so on. And I don't have zero of that skill, but I just don't have enough of it, I think, to get the audience that I would need to get that visibility. Right. And I don't know if it's necessarily a good idea for me to assume that that's the only path I can follow. But I certainly haven't. Dive deep and tried to become an influencer in that. Right. Speaker 3 I don't know if this is our doing chair, but we just had the maintainer and creator of a schema on the podcast. And one thing we kind of like did heavy handedly, at least I did. And I think you agreed because I you didn't. I agree that it was heavy handed. You didn't be like, dude, don't do that. I was like, Hey, change the audience. Let's make his dream to work on a schema more full time, a reality. Yeah. And he has a get up sponsors page. We linked to that. That's the only conduit for which he's taking money from the community to say, Hey, you support me in this effort to do this thing. And you see the big picture, but it's going to take time to get there. Yeah. We added to if the number uptick is our doing, yeah, we added to from seven to nine. That's great. Speaker 1 Is that great? Well, so it's it's great. I'm in relative terms because so it's sort of like if you have someone starving and you give them a tiny piece of bread, it's great for them. It's not enough. It's not sufficient. It shouldn't be great. It's the right direction. Yes. It's the right thing. Go from seven to five. Right. Exactly. And we're taking it back because that is great. It's just nowhere near sufficient. Yeah, exactly. And so like every if I happen to get a new sponsor from from this, you know, conversation, that's awesome. It's just like it's not one new sponsor that's going to move the needle. Right. You know, if enough people do it, it will matter. Speaker 3 I think the the folks that should be paying you probably are profitable corporations that leverage the dependencies for which you are a transit dependency of. Yeah, right. Like I agree, it's not truly the listeners, but the listeners for which they have influence at the place they they ([Time 1:11:09](https://share.snipd.com/snip/943b35fd-acb7-40c0-895e-a80633825325)) - **Get Employers to Sponsor Maintainers** - Encourage employers to financially support open source dependencies rather than only individual sponsors contributing personally. - Company sponsorships create sustained funding streams essential for maintainers' viability and ecosystem health. Transcript: Speaker 1 I'm always appreciative. I say, yes, of course, thank you. It really means a lot. It's validation for me, right? Even if it's a dollar, it's still that somebody like cares enough to vote with their wallet. That matters. However, if you really want to help, go tell your employer. Right. Right. Because once you get a company starting to put money into these sorts of things, the incremental difference to putting more money in is so small. But it's like that first getting through all the boilerplate of getting the finances approved and getting the money, like, pipeline hooked up. Like, that's a pain in the butt. But once you've got that hooked up, you can add more money. You can pay different people. Like, it becomes a much more permanent thing. ([Time 1:18:32](https://share.snipd.com/snip/22e1a122-44b3-4a36-b3de-0b3eff3c8e0e)) - **Regulate Corporate Open Source Funding** - To sustainably fund open source, enforce regulation requiring profitable companies to contribute a percentage of profits. - This mandatory contribution could include money, developer time, or sponsorship, easing funding gaps significantly. Transcript: Speaker 1 Guess, any of the things you use to make it better for you and for others? Honestly, I think it's just a pipeline problem. What I would change if I had a little regulatory magic wand is I would make the E the US and the EU require that profitable companies, only profitable ones, donate or contribute, let's Say 1% of their profit to their open source infrastructure period. And you can do that with time or with money. You can sponsor conferences in that counts. Like it'd be very liberally interpreted. If something like that were to happen, companies would just do it all over the world because it's simpler than, you know, trying to separate out the money. And on top of that, there would be so much money that companies like tied lift and thanks.dev and so on would would already be there to fill the gap and like provide that accountability. You know, the government would require a forum or something and like can help filter the money to the right folks. I think that would be that would just solve this problem. ([Time 1:32:13](https://share.snipd.com/snip/4e637489-acf6-4d74-99d8-6ea1c7cddd25))