The Changelog: Software Development, Open Source - ANTHOLOGY — The way of open source (Interview)

Episode Date: October 27, 2023

This week we’re taking you to the hallway track of All Things Open 2023 in Raleigh, NC. Today’s episode features: Matthew Sanabria (former Engineer at HashiCorp working on Terraform Enterprise), Nithya Ruff (Chief Open Source Officer and Head of the Open Source Program Office at Amazon) & Jordan Harband (Open Source Maintainer-at-large with dependencies in most JavaScript apps out there. There has been many changes this year in open source, and each of these perspectives lends insight into challenging and changing waters happening right now in open source.

this week on the change law we're going back to the hallway track of all things open 2023 in raleigh north carolina today's episode features matthabria, former engineer at HashiCorp who worked on Terraform Enterprise, Nithya Ruff, chief open source officer and head of the open source program office at Amazon. And last up today is Jordan Harband, open source maintainer at large with dependencies in most JavaScript apps out there. There has been many changes this year in open source, and each of these perspectives lends insight into the challenging and changing waters happening right now in open source. And we have to give a tremendous thank you to Todd Lewis, the organizer behind All Things Open. It is one of our favorite conferences, and Todd Lewis and team does a tremendous job leading that conference.

Of course, a big thank you to our friends and our partners at Fastly and Fly. This podcast got to you fast because Fastly, they are super fast globally. Check them out at fastly.com and our good friends at Fly will help you put your app and your database in 30 plus regions on six continents with no ops. Check them out at fly.io. What's up, friends? I'm here with James Cowling, co-founder and CTO at Convex. They're one of our new sponsors, and they're building a full-stack platform for the TypeScript era.

So, James, in your main navigation, you link to a page called Convex vs. Firebase. How similar is Convex to Firebase? And if someone is quickly trying to grok what Convex is, is that a good comparison? I think it's a good starting point for sure. I mean, Firebase has been very impactful. And the people we speak to who use Firebase often love it and often lament the time they have to move off of Firebase because it's kind of failed to meet their needs as a growing company. So Firebase falls short in a few ways. One is in terms of like a fully relational document model.

One is in terms of having strong type system. One is in terms of having this full end-to-end consistency story where you write functions that run on an API server on the data that you can subscribe to. And so one thing I think we see in the Firebase style development model is that you have web applications talking directly to a database in a cloud firestore. With Convex, what is different is you have your code talking to actual fully fledged TypeScript functions

running on your data that you can subscribe to. But I think the Firebase's comparison is fairly apt. And if someone is a Firebase user, I think you will love Convex. And it's certainly designed to fill that niche in the market. It's people who want to build applications without having to mess with infrastructure. In what way has infrastructure failed specifically application developers? I think if one was to compare what it looked like to build an application 10 plus years ago

to today, it's gotten more complex, not less complex. There's a bewildering amount of frameworks. I think Google, for all their amazing work they do, has had a bad influence on how people build systems because oftentimes when someone wants to build a web app these days, they're told to like learn Kubernetes or something ridiculous like that. You know, these infrastructure platforms really resemble the shape of the underlying implementation, not the shape of the problem that the application developer is facing. And so, even when before we started commerce, we're talking to customers, people were like,

well, I just want someone to like manage my Kafka cluster. And I say, well, why do you even have Kafka? And like, well, I don't really know. I think the database falls over if I don't put a queue in front of it or like I need to like buffer some data somewhere. And what became clear is is that the the tools just weren't serving the needs of the application developers and i think application developers and framework front-end framework engineers understand the problem space because

they spend all day doing it they sometimes don't have the power to to fix the problem because they don't build the database themselves and i think oftentimes infra folks don't have enough empathy for the application developer that at the end of the day, all that matters is the application. Okay. If you're looking for a better type of backend, Convex is the full stack TypeScript development platform you've been looking for. Replace your database, server functions, and glue code. Get started at Convex.dev. That's C-O-N-V-E-X.dev.

Again, Convex.dev. Let's talk about the last two weeks of your life. Yeah. What's happened? What's going on? How do you feel? I feel good. I feel good. So last two weeks, I've left my job.

Where did you work? I worked at HashiCorp. I've heard of them. Yeah. I was there for about five years. That's 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 Terraform Enterprise, got promoted there, went that route. But when I left, I was pretty much the Terraform Enterprise subject matter expert, working on Terraform Enterprise. So yeah, software engineering, a bunch of like Docker, Go, Kubernetes things. Yeah, pretty fun. It's funny, when he said Terraform there, I'm not even kidding with you.

I legit thought he said tofu. You're kidding me, aren't 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. I ate some tofu, but I never used it. Yeah, 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 the inside was different in the sense of we were made aware and we had all this notice and da-da-da. It wasn't. We found out 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 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, you know. It didn't make me happy, I will say. What we're not asking you to do, just to be clear, is to talk smack.

I think what these podcasts serve as, in my opinion, is like the facts of what really happened and 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 was at some level.

So I just talked to somebody else in Dev Advocacy today, and she said they knew three days in advance. Yeah. So Dev Advocacy knew a couple days in advance. Maybe they didn't. Yeah. But senior engineers on the Terraform team didn't know. Like, Hashicorp's an interesting company, right?

Because they're like a company of companies if you think about it. They have multiple projects, right? Nomad, Vol, Terraform Console. Tons of projects. All of their projects. They have a bunch of projects. And each of those teams kind of operates

in autonomy by themselves. They contribute to each other's code base, they have shared libraries and stuff, but for the most part, Terraform's Terraform, Vault's Vault, Nomad's Nomad. So from the Terraform side, we were pretty shocked. And mind you, I was on Terraform Enterprise, right? So our licensor and all that has never

changed. Terraform Open Source changed. So I wasn't on the Terraform open source team maybe they knew in advance but for me on the Terraform enterprise team we did not know in advance I guess it kind of makes sense to some degree that enterprise doesn't need to know right because you don't really not so much care but it's your underpinnings your customers are buying right from the open source and the customers that are buying the enterprise product are paying for it, and they're going through that sales process anyway, right? I think though, when you make a major shift like that, the story arc quickly for

HashiCorp, 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. You were part of that company. I was definitely happy for that, of course.

Right, which is a great thing. And I think when you're at that level, you probably should communicate to the people around you in your company to say, is this a wise move? Like, we are so ingrained, given that success, in the dev culture and the dev community, Terraform is such a used software that the community was like, that's not cool.

We're going to fork it and make our own thing. 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 this? Agreed. Can we do it? Is there a better way? I mean, looking at the open source repos, there's definitely people that are happy to use Hashigo 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 readme 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 little short staffed in the next couple months. We're going to slow down on reviewing open PRs.

But that was communicated. And yeah, the community looks at that and says, hey, what's going on with Terraform? But it was communicated to the community, and they were aware. 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 HashiCorp, there was about 350 people.

When I left, there was about 2,000. And obviously, I went through the IPO with them and whatnot. So that was one of the reasons too, yeah. It's like you're no longer working on open source. You're working on source available, if you think about it, right? Yeah. That's interesting, though, because you feel that way even though you're on the enterprise team. Yeah.

So just because you're in a silo that isn't really benefited or involved in the creation of the open source, you still care. Exactly. Because if you think about the enterprise, the whole point of the enterprise product is to be able to use the open source product in a way that you control in your own data center, in your own cloud or whatever. Use it in a way that you get the RBAC, you get the CICD kind of pipeline-ish aspect to it. You want to be able to use that.

But at the end of the day, it relies on the open source product to even be functional, right? So when you take that out, I don't know, do you destroy take that out, I don't know. Do you destroy trust? Maybe. I don't know.

It's hard to say. Yeah. How big is your team? We were about 10 engineers in, like, June. Then Hashcorp did a layoff in June. Then we dropped to eight engineers. And then a few of our engineers went on maternity leave, and then I left. So when I left, we were five.

So seven if you count the staff, but I don't count the staff engineers in that. So were your colleagues equally as shocked? Were they also upset? What was the general vibe on your team? Some of them were pretty frustrated with it. Some of them were like, I don't care. We're enterprise. Doesn't really matter. That was kind of the vibe. Me, I was more so like affected by it because I was looking to like transfer teams a year before that to an open source team to specifically work on the open source product and not the enterprise product. And that team also had their license changed.

So for me, I was like, that sucks. But the team sentiment was pretty good, right? Like, being close to the money is nice, right? TowerFirm Enterprise made a pretty good revenue chunk for HashiCorp, and most people were like, eh, we're okay. We're still making money, we're fine. Don't care about the license. That's fair.

This might be TMI, but can you talk at all about your Slack message? Yeah. Can you give an overview of it? Yeah, I can give an overview of it. That was a good one. So like every company, Hashcorp has channels in their Slack where you can monitor, where they talk about the competition or they have a Twitter feed channel, all that stuff, right? Where you talk about what's going on in the industry around us.

And there is one for competition. And Open Toofu came up a lot in that channel. Obviously, people were like, oh, they don't know what they're doing. Some people were like, oh, you know, they're going to eat our lunch. And the sentiment was spread out. They had people that were like, they're going to take our business. And other people were like, nah, they're nothing. And it was interesting, though. But there was one message there was like, when OpenTofu finally announced that they went to the Linux Foundation and they're trying to go to the CNCF,

but then they announced their name change because they were OpenTF and then they changed to OpenTofu. When they announced that, someone posted that announcement in the Slack channel. And I replied, and verbatim,

what I said was like, I wish them well overall, right? Like, I'm rooting for them overall, but that name sucks. That's what I said, right? Verbatim, that's what I said. I don't like the name Open Tofu. I've never been a fan of it. That's fine, but that's what I said in the chat.

And yeah, like, I got pretty good backlash for that comment. Oh, really? Yeah, I was shocked. Why? got pretty good backlash for that comment. Oh, really? Yeah, I was shocked. Why? This was like two to three days before my last day at Azure Corp. So I had already put my notice in and all that stuff,

but I was just engaging in conversation. I was like, hey, you know, like, I wish them well, but I don't like the name, whatever. And I had backlash from that comment where, I guess, two days passed and someone went to leadership and said hey matthew's comment and slack they're not rooting for hashicorp they're rooting for open open tofu they want us to fail and i was like what that's not even what i said so that made it back to me through my manager. And I was legitimately just shocked. I was like, wait a minute. What? What are you even saying here? Right. Yeah. So that was kind

of like an eye opener to me. I was like, that was a little weird in my respect. But what are you going to do? Right. Like things happen. Yeah. So are you at Cockroach Labs now? I start in like a couple weeks. You're actually representing them. I do. I have them on the badge. Despite not truly what if they rescind their offer? They could. They sure can. It's business. What makes you excited about Cockroach?

Just the distributed systems problems that I'll be able to get into and solve. Comparing and contrasting it to where I was and now, Hashgraph, great company. Cool people. Some of the nicest and smartest ICs to where I was and now. Hashgraph, great company, cool, cool people, right? Some of the nicest and smartest ICs I've ever worked with there and good products. But they build the tools.

They don't necessarily run the tools at the scale that the customers do, right? Yeah. Whereas Cockroach, they create the database, they run the database as a managed service, so I get to interact with those distributed systems problems. That's what draws me there. So yeah.

Also some licensing issues there too, wasn't there some licensing issues at Cockroach? Yeah, so which is... I think it's fair to change, and it's fair to protect. Well that's the thing, right? People, with my comment in the Slack that we were talking about,

people were saying, oh, the license is good, you're just, you want HashCorp to fail. It's like, no, I don't, the license, I'm not mad about the license. What I'm mad about is the lack of transparency, right? Right. And that's kind of what got me. And then the company I'm going to, Cockroach, they have the same license, right? They're under the BSL license as well.

Yeah. Yeah, I thought it was SSPL, but I'm probably wrong. I think it's BSL. I got to check too. You're probably right and I'm probably wrong, but there's a BSL. I got to check, too. You're probably right, and I'm probably wrong, but there's a lot of licensing we cover over the years. There's so much. My licensing wires might get crossed.

And in the time that I left HashCorp and before I started Cockroach, I've been in a break mode. I just gave myself a little time to adjust. I think they've always been clear, too. Cockroach has always been clear about what they're trying to do. But it makes sense. Cockroach DB is been clear about what they're trying to do. But it makes sense. Cockroach DB is a service that you're going to run. Long running service

that's going to provide value to whatever applications you run. If you notice the licensing conversations around HashiCorp have primarily been focused on Terraform. But all of HashiCorp's license changed. Vagrant, Nomad, Vault, Console, all of them. All of's license changed, right? Vagrant, Nomad, Vault, Console, right?

All of them, all of them changed. So it's like, when you think about, when you step back and you say, why are people upset about the Terraform license change versus the other products like Vault or whatever, it kind of breaks down where Vault and them are services and Terraform's a tool, right? So then when you apply that to like, you know,

Cockroach or even Elastic, right? They're services that run. Terraform's a tool, right? So then when you apply that to, like, you know, Cockroach or even Elastic, right? They're services that run. Yeah. Terraform's a tool. I don't know if it made sense to change the license of a tool. It does make sense to change the license of a service. Yeah. Because you don't want, like, other providers providing that service on your behalf and whatnot.

Yeah. And they fundamentally use it in a different way. Right. Right? Like, you're going to plug into a service and have it operated or operate it yourself. Yeah. A tool you're going to build things with on top of. Yeah.

Right? Modify more, et cetera. And so they are approached very differently. And so that's why the reaction is quite a bit different. Agreed. Yeah. It was an interesting thing for sure. I mean, again, we don't know what's going to happen.

I just felt like, I don't know. I don't know if the communication was fully thought through in that sense. You probably saw the FAQ pages. They kept adding FAQ messages there. I don't know. It's a weird one. But what I thought was interesting is, so I downloaded OpenTofu, played with it, used it. Despite the name.

Despite the name, yeah. I just renamed the binary OpenTofu. Yeah, it's fine.. Despite the name. Despite the name, yeah. I just renamed the binary OpenTofu. Yeah, it's fine. It's okay. I aliased it back to Terraform. We had a conversation in our Slack about the name as well. I bet everybody in their Slack had a conversation about the name. Of course.

I thought OpenTF was a totally fine name. I thought so, too. But they wanted a cute mascot, apparently. And so they went with the Tofu. I think they probably wanted to get further away from the word terraform or tf in particular i mean it's obviously i think it's enforceable through some sort of i mean yeah it's probably had to yeah it's an obvious derivative correct of its predecessor right correct so i mean it's not like you could argue that it's just shortened to open tf i also not a huge fan of the name, but go ahead. You were saying you ran it.

Yeah, I ran it, used it. Like some of their, first of all, I think they made a really smart decision. If I were in their position, I'd do the same thing, right? If I was in their position of the companies that got together and started that foundation and all that, I would do the exact same thing they did. Why wouldn't you, right? Like you have an opportunity there. You have people that are willing to throw engineering time.

And then there were a few, like, quick win features that you could have added, like the encrypted state file and whatnot. So it made sense for them to do what they did. So what do you think of their claim? So one of the things that Josh Padnick said on the show was about the amount of effort dedicated to Terraform versus OpenTofu. And he stated, like, based on GitHub public, you know, activity on the repos, who's actually working on it, a handful of people.

And he's saying we had 15, I think they said 15 engineers at the time, I don't know, dedicated or full-time resources. Do you think that's, A, accurate from your perspective, and then, B, do you think that's going to really move the needle? I think that's relatively accurate if you just talk about Terraform open source as itself. Because Terraform is kind of a beast of a tool. You have the open source binary that's responsible for the graphing and whatnot, and you have the providers that actually communicate with the APIs. If you look at the open source part of the product,

then yeah, there's probably just a handful of engineers working there. But then there's various little ecosystem teams, CLI experience teams, provider teams, and then the team, I air quotes, the team of Terraform expands beyond that. But realistically speaking, the major providers, you're already partnering with AWS, Google, Azure, all of that for those providers. So you're kind of already sharing that bandwidth.

But if you're just focusing on the core, I think they're correct. There's only about a handful of engineers that work on the core core. So can OpenTofu pull it off with their 15 or so engineers? I don't see why not. 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?

What happens when conflict arises and one company wants to go one way and one wants to go the other way? What do they do? Yeah. You know? One thing I was trying to drill down with him, which I don't think I ever quite got the question asked in a way that he understood it was, it seems like they have a lot of logos, but not a lot of like guaranteed support. So it was like, how much of this is support and name only? Like, yeah, we're behind you put our name on the website, but are we actually going to like, cause it takes a lot, not just up front, you get the energy and the excitement and everybody to slap their logo on in the beginning.

But over the course of years to support a project, that's an ongoing initiative that requires dedication. And how many of these companies are actually dedicated, obviously time will tell. But he didn't seem too worried about it. Yeah, I listened to that episode. I heard the question. I was waiting for a concrete answer as well. We didn't get a super concrete answer, which is fine. You know, they don't know. Yeah, I listened to that episode. I heard the question. I was waiting for a concrete answer as well. We didn't get a super concrete answer, which is fine. Yeah.

They're still early. But I agree. Time will tell on that. I hope they can maintain it because it's a beast of a tool to maintain. The people that work on Terraform have been there for quite a few number of years, built up the context around it. It's a pretty decent large code base. And it's a complex problem domain, right? Like the whole idea of Terraform is just,

you're graphing your infrastructure and you're making API requests. So if you don't understand that whole idea of graphing and whatnot and dependency resolution, it's gonna be a little bit of a difficult thing for you to contribute to. The question is, will you be a contributor? I think so.

I've already contributed to some of the Terraform providers, so I'll probably keep contributing in that respect. I haven't contributed. I think I have contributed to core, maybe like small little contributions, but nothing major to the core code base. Does Cockroach use Terraform? Yeah, they have a Terraform provider, but they don't use it for their production infrastructure.

Gotcha. Yeah, they're on Pulumi, I believe, from what last I heard. We'll see, I guess, right? Yeah. Yeah, we'll see. At the end of the day, infrastructure is, if you think about it, it's a solved problem. We know what we need to do with it.

We need to spin it up. We need to manage it. The tool that you use, use the best one for your team, right? The one that's going to provide you the best benefit. That's the one you should be using. Curious if you have takes on some of the more recent releases in the infra world, system initiative, the stuff that the Dagger folks are doing.

What's interesting to you? Yeah, the Dagger stuff's interesting. I heard about it in the podcast, looked at the website and whatnot. I haven't used it yet. I have not used it. System initiative, however, I have used, I've contributed to, and I interviewed them. Okay. So you're excited about that. I'm very excited about the System Initiative stuff.

Adam Jacob, great person. I think you had him on the show, right? We call him a friend. There you go. Perfect. Perfect. Yeah, great people there. A couple former HashiCorp people that are there. Talked to a few of them. They have a wonderful Discord that if you are really interested in system initiative,

go join. They're wonderful people. They do everything out in the open as much as possible. And that's how I got involved. So I interviewed with them. Didn't get that role. They went with somebody else because, you know, startups,

they're only like 14 people. Yeah, they're small. Right, they're small. So they got to be very, very picky, which is great. But then I liked the product, did the beta, like went through the beta testing or whatnot, gave them and all that and then i contributed their podman driver

to run system initiative on podman is it the future is it the future is a good question i don't i don't know i i like the ergonomics of it a lot honestly it's very fun because if some like when you're thinking about infrastructure the one thing that really like left a bad taste in my mouth with terraform is when you're trying to infrastructure, the one thing that really left a bad taste in my mouth with Terraform is when you're trying to find out what other resources you can use with this resource, it's very difficult. You need to know the name of the resource

that you want to use, right? Like finding the dependencies and the connections between them is tough. You have to look in their docs, and the docs are, there's a lot. But with System Initiative, you drag an asset onto the pane, and you know the dependencies that you can use with that resource.

You know what can plug into it. You know what it can output to. And that's great. I thought that was cool. So from the visibility of how you can build your graph of infrastructure, I think System Initiative is great in that regard. Outside of that, obviously they're still in very, very early release phase. So they have a few UI things to smoothen out.

But I don't know. Is it the future? Again, the future will tell what the future is, right? Do you think it could be just a UI that others, like could it be a UI on top of Terraform, for example? Could it become the interface that we begin to use to orchestrate services and infrastructure and stuff like that rather than just being its own silo.

It's possible they could open that up because they have the capability, technically. Under the hood, all the assets are just TypeScript under the hood, right? So it's like a function or whatever you run. As long as you write it in that interface way, you're good. I think so. Would they want to do that? I'm not sure. Right?

That seems to be the most innovative thing, really, and what it offers, right? It is the visual interface to connect the nodes and see the dependencies rather than scouring through YAML or whatever else you might have for configuration. Exactly. That's challenging, right?

It is. And the example they run you through in the beta is basically spin up EC2 instance, security group, SH key, right? You just put it all together and you see a graph in your AWS region and whatnot. And it's all graphed really nice for you and you get to apply it. And they, you know, similar to Terraform, they have their graph-based way of applying. So dependencies get created first and blah, blah, blah, which is great. I like their extensibility though.

So for Terraform, if you want to extend Terraform, you need to contribute to the provider if there is one. If there's not a provider, you need to create a provider, build that binary, ship it. In system initiative side, you can just edit the TypeScript. Or you can go in there, drop TypeScript functions in, and now you have a new asset to manage. So from the extensibility side,

I think they have a more extensible platform for the average developer. Right. Right. And you're an ops guy who likes TypeScript? I don't actually use a lot of TypeScript. I use a lot of Go. I use a lot of Go.

And you don't seem to have a problem with that. I don't. TypeScript's very readable. It's not my favorite language, but coming from another strongly typed language, TypeScript works for me. Happy to hear that. I just remember that one of the... I think Kelsey was on saying that. One of the concerns is that it needs to be multilingual.

Specifically, back-end folk, infrastructure folk, aren't going to want to use TypeScript. And so, counterpoint. I think if you're a good engineer, the tools matter less than knowing how to use them correctly. Amen. Right? That's what it is. So if they're using TypeScript and I know how to use TypeScript and to do what I need to do, why do I care so much, right? I'm using the thing.

It's okay. I'm using the thing. Yeah, I'm using the thing. So for me, it works out. Do I maybe wish it was something like Go or Rust? Maybe. But everybody knows TypeScript, right? At this point, it's out. Do I maybe wish it was something like Go or Rust? Maybe, but everybody knows TypeScript, right? At this point, it's a pretty ubiquitous language.

I think it's a good first choice for them if they want to expand later. It's got a wide footprint of users. It does, it really does. And so in that regard, it's smart. Yeah, when you contrast it with something like Pulumi, who supports many languages, I don't know if that's the right choice. I think when you give people too many choices, you fall into that analysis

paralysis situation, right? Where you're like, what language do I use? If this team's using Python and that team's using Go, can they contribute to each other's stuff or am I creating silos? So I don't know. I don't know the right answer, but we'll see. Yeah. Well, it's a different thing. So I don't know. I don't know the right answer, but we'll see. Yeah. Well, it's a different thing. So one thing that Solomon said on the show about Dagger is they were Q-Lang, which is basically YAML on steroids, if you don't know about it. It's a strongly typed configuration language.

And that was a real hangup for people because they wanted more power. And so now they went the other direction, right? Go SDK, Elixir SDK, TypeScript SDK, et cetera. And I wonder if that distinction is significant from a declarative YAML-esque thing to a programming language. But once you get to that point, the language itself is less significant, right? Yeah, I think the win there is getting off of the DSL for them and then giving the opportunity to really just plug in whatever you need.

It's a right code. Right, it's a right code. Proprietary versus whatever's out there. Exactly. Yeah. Exactly. Because there have been a lot of people that I've worked with, so many customers over my time at HashiCorp,

that they asked for loops, like proper loops in programming languages, and they had good use cases for them, and the HashiCorp HCL DSL wouldn't really enable that in that regard. So, yeah, it's interesting to see what's out there, though. I'm excited for all these new tools, and I wish when I was doing more ops work earlier in my career, a lot of these tools existed, because it would have gave more choice. I was kind of stuck with Bash and Ansible in a sense, right? Well, man, appreciate you stopping by and telling the story.

Thanks for having me. It was a fun deep dive. Yeah, yeah. I'm happy to chat about these things. It was more like a shotgun dive. A plunge. It's a plunge. We got a lot of stuff out there.

We splashed it. We splashed it. Sure. Splash. No, I appreciate you all having me. Nice meeting you, Matthew. It's great to see you. Nice meeting you all, too. We did it. You splashed it. Sure. Splash. No, I appreciate you all having me. Nice meeting you, Matthew. It's great to see you. Nice meeting you all, too.

We did it. You're off the hot seat. That was fun. What's up, friends? We're working closely with.tech domains to feature startups that are participating in their startups.tech program right here on the changelog. I've never seen something like this from one of our advertisers, but it does make sense to me to show off not only what.tech domains offer, but also who is building on.tech domains. And I'm here with Bastian, co-founder of Eyewear. You can find them at eyewear.tech, E-Y-E-W-A-R-E.tech, where they build AI-powered webcam eye-tracking software used by AMD, Microsoft, and even Intel. Bastian, give me the backstory. What does Eyewear do?

We're a deep tech spinoff, computer vision and AI spin-off from a Swiss research lab. We turn your webcam or 3D which is an eye-tracking SDK that companies like AMD have used in collaboration with us to build, for example, the AMD Privacy View app that is now part of the Radiant software driver suite. There, you can use eye-tracking for certain features like Privacy View. It blurs out parts of the screen that you're not looking at. We also took that app and built our own solution

called iWare Beam that is targeting gamers, where you can turn your webcam into a gaming eye tracker for more immersive gameplay in, for example, simulator games, over 200 of them through the OpenTrack extension. Or you can use it for streaming or game recording to improve your own gameplay by re-watching your recordings with that overlay and seeing when you missed something during essential sections of your gameplay, or just share it with your audience

and engage better with them. Well, this is definitely the next frontier. Are you only licensing focused, or do you have any offerings that's ready for developers to consume and leverage in their projects so with iward beam we are facing consumers directly with this app you can download it there's a free trial on our website and on steam so you can give it a go and and and and see how you like it um the the idea is still that we provide licensing solutions to big players,

to OEMs, and allow them to integrate eye tracking. I think there's going to be a world where you're going to have headsets. They're for sure going to come. I'm going to be

one of the users and eye tracking is an essential part of it. But then you'll have a lot of just interfaces, surfaces, screens, where you will want

to interact with them without a headset on, and their eye tracking will also matter. So there's, for example, these 3D screens, 3D stereoscopic displays where you would need eye tracking, and similar situations. So it's going to be a hybrid setup, and I think our technology is an essential part of that. Talk to me about the choice of using a Diatek domain.

I think it was a logical decision to make from, I think every startup will first take their name and then add a.com behind it and try that out. And then it's probably going to be too expensive or taken already. And then look for alternatives. We are a deep tech company that has already part of it in the name. So if we put eyewear.tech, it makes it clear for third parties, specifically for these potential clients that we want to license to,

that we are a tech provider. We're a deep tech company. We're a spinoff. And I think that represents it pretty well. Okay, make sure you check out eyewear.tech. That's E-Y-E-W-A-R-E.tech. And of course, go to startups.tech slash changelog if you want to have your startup that's building on a.tech domain featured on a show like this. Don't wait.

Go to startups.tech slash changelog. Again, startups.tech slash changelog. All right. So Nitya Ruff, director of the OSPO at Amazon. Is that right? That's right. Open Source Program Office for all of Amazon. AWS and the stores,

devices, other, the whole nine yards. So the OSPO of OSPOS. OSPO of OSPOS. My gosh. That is, that's got to be a big thing, right? And on top of that, you listen to the show. I listen to the show. That's an even bigger credential. Right? You think so? i don't think your credentials are your real credentials but i'm excited about your credentials you think that's an honor gosh i i'm a huge podcast fan

i listen to podcasts on my walks and typically podcasts are about 24 minutes to 30 minutes and my goal every day is to do at least a 30 minute walk. So it really helps me kind of listen, learn and walk. I try. Let's talk about that for a second, because that is a big deal. Yes. Too many people have health conditions and issues or whatever. Right. And all they got to do is just walk. Yes. For 20 minutes, maybe 30 minutes every day. Just go enjoy the world, right? Just go and see what's out there. Bam, healthy.

There you go. The fresh air. I mean, obviously a little bit of diet changes if you want to, but like literally your heart and your lungs, all these things change if you just are a little active. And they say, you know, small micro habits add up. Oh my gosh. What kind of books do you read?

It's like compound interest. So over the course of a year, 30 multiplied by 365. Yes. All of a sudden you walk miles that day. People are not that excited about 1% change until it compounds. Yes. Right? Yes. If you have, oh, it's 1%. No big deal, right? Compound interest is fantastic. Yes. Today, 1%. Tomorrow, when I hear it, do the math for me, Jared. 2%. Hey, Chad GPT. That's right.

Where is Chad GPT when you need it? Yeah, when you need it. Right, right, exactly. Do this math for me. That's a good thing. Okay, cool. Love it. So what does it take to be the Ospo of Ospos then?

What kind of things do you see? What kind of stories can you tell us? What led me to being here and, or whatever. Sure, that too, but more so like what you're doing as the Ospo of Ospo's. I mean, Amazon is a massive company.

Yeah, yeah. I mean, I probably have something on my front door right now from Amazon. Yeah. You know, I do, I watch. Jeff sends me something every day. Does he really?

Okay, well that's nice. Personally, does he personalize it? Around my house, I do say Jeff a lot. Do you? We all know it's Jeff Bezos, but I just say, yeah, I just referenced Jeff. I'm going to talk to Jeff about eggs. If I want to change to Amazon, I'm like, I've got to call Jeff. It's funny you say that.

I've literally never done that. Do you do that? It's funny you say that because every time I receive a package and I order things constantly on Amazon, I always say, oh, Jeff sent me something today. Okay. My husband said, with Jeff? I said, you know the Jeff?

So we're of the same mind then. Yes. What does it take to run the Ospo of Ospo? We know how big Amazon is. We know how influential it is as a brand and just of change. AWS has changed the way we compute. I mean, they were early on in the cloud essentially creating it and inventing it. But what is it like to be in that role?

What does open source play in that kind of position? 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 workflows 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. That's the role we play. I would say historically, Amazon hasn't had the best reputation with regard to open source, at least from my purview. And I'm curious what your position is and maybe helping change that image or what you're doing to maybe change the way Amazon approaches open source. I mean, you all do a lot in the world of open source. I think that gets perhaps shrouded in other things like the hosting of open source projects and commercializing of that, which is what we talk about more often, I think. What's your perspective on that? We want to do it through action. We want to do it through participating in communities, by giving back,

by supporting maintainers and projects and foundations, rather than just telling. And so I hope you've seen over the years that we are showing up more in open source forums. We donate a lot of AWS credits, for example. That's true, yeah. We do GitHub sponsors. We support foundations like the OpenSSF, Apache Foundation, Linux Foundation, Project CNCF, that sort of thing. And we have lots of developers who are behind the scenes

actually contributing to projects. It's never enough because all of us consume a lot, so we have to keep working on that. And most businesses, not just Amazon, is challenged with business justification. Why should I dedicate five engineers to doing this work, because there's so many competing needs, right? Customer needs and product development needs

and so on and so forth. So we work hard as an OSPO and open source marketing team who's downstairs at our booth to work with businesses to educate them on why they should be involved, why they should contribute back, what's the business case for setting aside people to do it. So those are the ways we help the business do more with open source, but we have to have a good business decision and argument

because business is no business and they need the return on investment or justification for why they should be involved. What are some of the things that your OSPO does to enable these different business units to adopt open source, to maintain open source, to do more? What are the kind of things that helps them get there? One of the easy things OSPOS 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, et cetera, 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 contribute it. 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. A lot of times, teams don't want to do it because they'll say, I don't want to go talk to our IP lawyer and I don't want to have to justify why I need to do this. But if you take away all those excuses, then it becomes easier for people to go do it. How long has the OSPA been in place? Has it been in place for years, half a decade, eight years? I mean, they've become more popular in

the last, I would say, five to eight years, I mean, they've become more popular in the last, I would say, five to eight years, roughly, but that's probably even farther fetching, more like in the last three to five. How long has this OSPO been in place? The Amazon OSPO has been in place almost since 2007, 2008, believe it or not. Really? So even further, okay. Yeah, one of my... But it wasn't called an OSPO. 16 years? Yeah. Okay. What was the version of it? I think it was't called an office. 16 years? Yeah. Okay. What was the origin of it? I think it was just called an open source office, open source strategy office. Right. Or open source approvers. My colleague, Henry Yondle, who is in my team, he started it.

It was because, you know, the GMs and lawyers said, please come, someone who's knowledgeable. Well, they probably cost a lot more money, right? Lawyers cost a lot of money. Attorneys. Yes. Right? Per hour. So I would much rather have policy in place that I can reference than a lawyer that has to spend an hour to charge you $700, right?

Maybe that's even cheap for an Amazon type of attorney. It's funny you mentioned that a lot of companies start their open source program office because they say we can't have everybody go to our lawyers and ask questions. So if you have thousands of developers all pinging them and saying can I use this license? Can I use this license? Can I contribute this? Can I release this? It chews up a lot of valuable attorney time. So often OSPOs kind of act as the front line, and we kind of act as the in between developers and legal,

and we handle a lot of the questions and the issues and the tickets. That's funny it's called open source programs office when it's that, right? Like, it's essentially the gateway to legal. The cheaper, not just that. It's one role. The way you described it just now.

I'm not saying that's only the way it is. That's how a lot of OSPOs get started. Right. Because you have to do compliance when you consume open source. But then, you know, good OSPOs go beyond that and actually make it easy to work with community. They go work with foundations. They publish. They speak.

They share best practices. They help the company be a contributor and a leader in the community. So you need to take it past compliance into really leaving something behind. So yeah, I mean, the generic OSPO has been around for the last 10, 15 years. Google, Facebook, everyone had an open source program office. There was a group called the To-Do Group, which sits in the Linux Foundation, which came along and created kind of a support system for open source program offices to share best practices across teams.

Because we are all trying to do the same thing, trying to make it easy for our developers to work in open source, try to ease the legal burden, try to engage more, try to respect the norms of open source, be a good citizen, you know, all of those kinds of things. What are some of the challenges that you face now? Like today, this week, this month, what are some challenges you're dealing with, positive and negative? Like positive challenges in terms of like, we got to get this done,

this is a great thing. And also ones like, this sucks, we got to just deal with this and make it better. I think scaling what we do across the company is one of the challenges, because especially in a large company when you have thousands of developers who you need to make aware of the policies and processes and that we are here to help you, it's hard to get the word across.

So we've been working on a program called Champions, where we have people in businesses become open source champions and enthusiasts. And so you have a local person that you can talk to instead of coming to an OSPO all the time. Because OSPOS typically tend to be small and they're serving thousands of developers. So today we have 230 champions in the company that help local businesses across Amazon have a local person who's an expert that they can reach out to and they can then reach out to us if necessary. So scaling is a challenge. The second challenge is open source security and all the different places we need to get involved in

from an open source security perspective. Working with OpenSSF, working with upstream producers, working with our security teams inside the company, working with policy makers. There's a lot going on in security. So that's another big area of interest. The third is AI. What's the role of open source in AI?

What are the different artifacts in AI? How are they going to be licensed from an open source perspective? Working with OSI and trying to get our arms around making sure that we have a standard for open source artifacts is important. Yeah. And you know, with all of us using more and more models and more data sets, helping our legal team again, like we did for licenses, helping them review and approve model use and data set use

is something we're trying to do. And finding good people to build your OSPO is always hard. Yeah, it probably is. There's only a small group of people. There's got to be people, people that also like policy. How did you land here? How did I land at Amazon? Well, specifically in the OSPO, director of OSPO,

what brought you there? Yes. I've been working in open source for 25 years now. My first job in open source was at Silicon Graphics, working on open source strategy and support. And I loved open source. I fell in love, and I said, because it's such an intersectional role of strategy,

community, technology, community, technology, law, and it's just fabulous. So I've been working in various companies in open source, and it was about 10 years ago, I was at SanDisk, and my manager said to me, I was the director of marketing there, and he said, you know, every time you work with open source, your eyes light up. And maybe you should go do open source for the whole company. And that kind of gave me the bug of,

yeah, maybe I should run open source strategy for SanDisk. And I started, I pitched the idea to our SVP of engineering, and he said, yes, we need someone doing that. So I became the first director of open source strategy at SanDisk, which then led to becoming the senior director of open source at Comcast for five years. So I started the OSPO there and built it all the way. And then so when Amazon was looking for someone to lead their OSPO,

they came to talk to me. And I love the challenge of the scale of Amazon and the width and breadth of things that they do. And it's an open source geek's dream to kind of look at all of the different use cases and how we work in open source. So here I am. There you go. That's a good story.

Yeah. It's a fun journey. What was that pitch like? Do you remember it? When you pitched the SVP of engineering back in the day? You sold him. Yeah. I basically wrote a one-and-a-half-page document which said, open source is so important, even though we are a hardware company,

software is very important to Flash, and Flash hardware that cannot function if storage stacks and open source I.O. does not know how to use the Flash speed because most software stacks in those days were optimized for hard drives. And I said we need to change the software ecosystem around us if we need to get flash to be fully optimal working with software. And I know the consumer group which works on USBs is trying to do that. I know our enterprise group is trying to do that. Thiss is trying to do that. I know our enterprise group is trying to do that.

This group is trying to do that. We need to be involved in the Linux Foundation. We need to work with the kernel. So he said, yes, and we need to coordinate and leverage each other's work, and we need to do it in a more intentional way rather than everybody going off and doing their own thing. And with that, we became members of the LF. We started working more closely with all the storage subgroups and the kernel and started recruiting more open source friendly people.

We now started doing compliance better. Started showing up at shows. Huh. That's a good sales pitch. I would have bought it as well. That was fun. Yeah, that sounds like a very challenging coordination. Yeah, it was.

Because I still had to work with all these different divisions and understand their engagement with open source and where they were, what their obstacles were, how to, what was the commonality across these teams, et cetera. I didn't own any resources, I didn't have a team. I was working with a CTO and trying to help the company. But now I have a team, so it's so much nicer to be able to scale and have really smart, smart people at Amazon who help me get this work done.

Yeah. Curious what your guidance is coming back to Amazon. I'm an engineer at Amazon. I have a library that I've written that facilitates something inside of our service. It's generic. I could open source it. I come to whomever and say, hey, I'd like to open source this. What is the guidance like? You will do this. You will license it that way. It will be under this organization on GitHub. It will have this kind of a read me. I mean, do you guys step by step help people through this? What does that guidance look like?

Like, what do you say? 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 okay 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 RepoLinter, which looks through your code and makes sure that you haven't got keys and proprietary information, etc. So it sanitizes it. We help them attach an Apache 2.0 license.

We make sure that they have a README file, code of conduct, etc. 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. Yeah, cool. That's a bit of a ceremony, I would say, right? Yeah.

It's still somewhat intimidating to have to go to your manager and be like, hey, this is cool because you kind of have to be vulnerable a little bit, right? I guess you are anyways when you're introducing code into the world. You're being a little vulnerable with your works, but yeah. You have to be like, hey, this thing is valuable enough then you said the business line attorney might have to approve it, right? And they still have to

come to you for more stuff. It's a lot though still yet. I think you have to be thoughtful if it's a full library and a full project, right? You need to be thoughtful about what's the right thing to do. And one of the right things to do is to resource it correctly if you're open sourcing it so that it can be maintained properly. Very often teams will be very enthusiastic about open sourcing, but not commit to maintaining it.

Yeah, for sure. And so we want to make sure that the business is fully behind it, and that there is a good sound reason why it's the right thing to do. It's like a liability in a way even too, right? Because liability and the fact that you have to show up, it's one more thing to commit to. It's one more yes that you can't say no to later on. It's a liability in that sense that from the business perspective as Amazon, you have to say, yeah, this makes sense. Not just open source, but for us to open source it.

Yes. And small little things that you want to release like a sample code or something. We really don't do that much due diligence. But if it's a full-blown project, we've released Bottle Rocket and Firecracker and Finch and projects like that. We really want to make sure we do it right. We owe it to open source to do it right and not just throw it over the wall. Let's say there's a case where this library you've written, Jared, is generic, it's useful to some, but you all say, well, it makes sense to be open source but not from us. Do you allow that person to put it open source on their own if they've written it on company time or for company resources?

Is there ever a time where it's like, it's not right for us, but it's okay for you? I haven't seen a situation where we have said it's okay for you to go off and do it on your own. Because if it's done on company time, we need to make sure it's done right. If it's their pet project they've been working on on the weekend, something to do with dairy farming or something different.

You'll never get into dairy farming. But farming is getting into open source. You never know what Amazon might. Not Amazon, but there is a project in the Linux Foundation around farming. Is there? Yeah. That's awesome. Well, I mean, Amazon is a, I don't know if it's a conglomerate,

but you're definitely, the organization expands into areas where you may have, I mean, Whole Foods is an example. For sure. Where all of a sudden now you're a grocer. And so maybe there are competitive things that you don't know about, but you eventually will. I don't know. And we need to do due diligence to make sure that it's not something that we need to care about. What are some of the darlings of Amazon open source? Like if you were to name,

like here's our biggest open source projects, you listed a few there, or like the ones that the Ospo really loves, like a shining example of Amazon open source. What are some examples? I think if you go on AWS Open, you'll see some of the projects listed there and blogs. Clearly, Bottle Rocket, Firecracker, Finch, RealRTOS, what else?

Those are some of the ones that I can think of off the top of my head. But we contribute to a lot of different projects. Like OpenJDK, we take what we do inside the company to harden it and to make it easy to use. And we provide it as Coreto, which is an open free distribution for everybody to use. So there's lots of really fun things like that that we contribute to. Well, we appreciate you stopping by and chatting with us. Thank you. What's up, friends?

I'm here with Vijay Raji, CEO and founder of Statsig, where they help thousands of companies from startups to Fortune 500s to ship faster and smarter with a unified platform for feature flags, experimentation, and analytics. So Vijay, what's the inception story of Statsig? Why did you build this? Yeah, so Statsig started about two and a half years ago. And before that, I was at Facebook for 10 years where I saw firsthand the set of tools that people or engineers inside Facebook had access to. And this breadth and depth of the tools that actually led to the formation of the canonical engineering culture that Facebook is famous for. And that also got me thinking about how do you distill all of that and bring it out to everyone if every company wants to build that

kind of an engineering culture of building and shipping things really fast, using data to make data-informed decisions, and then also informed to what do you need to go invest in next. And all of that was fascinating, was really, really powerful. So much so that I decided to quit Facebook and start this company. Yeah. So in the last two and a half years, we've been building those tools that are helping engineers today to build and ship new features and then roll them out. And as they're rolling it out, also understand the impact of those features. Does it have bugs? Does it impact your customers in the way that you expected it? Or are there some side effects,

unintended side effects? And knowing those things help you make your product better. It's somewhat common now to hear this train of thought where an engineer developer was at one of the big companies, Facebook, Google, Airbnb, you name it, and they get used to certain tooling on the inside. They get used to certain workflows, certain developer culture, certain ways of doing things, tooling, of course, and then they leave and they miss everything they had while at that company. And they go and they start their own company, like you did. What are your thoughts on that? What are your thoughts on that kind of tech being on the inside of the big companies and those of us out here, not in those companies, without that

tooling? In order to get the same level of sophistication of tools that companies like Facebook, Google, Airbnb, and Uber have, you need to invest quite a bit. You need to take some of your best engineers and then go have them go build tools like this. And not every company has the luxury to go do that, right? Because it's a pretty large investment. And so the fact that the sophistication of those tools inside these companies have advanced so much, and that's like left behind most of the other companies and the tooling that they get access to, that's exactly the opportunity that I was like, okay, well, we need to bring those sophistication outside so everybody can be benefiting from these. Okay. The next step is to go to Statsig.com

slash ChangeLaw. They're offering our fans free white glove onboarding, including migration support. In addition to 5 million free events per month, that's massive. Test drive Statsig today at Statsig.com slash ChangeLaw. That's S-T-A-T-S-I-G.com slash changelog.

The link is in the show notes. All right. Well, we have Jordan Harband. Hey, man. How's it going? Good, good, good. Thanks for having me. You are an open source maintainer at large. I know you're mostly through the JavaScript side of things.

Tell us about yourself. 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's download traffic, which is terrifyingly high. I've been on TC39, which is the JavaScript Standards Committee, since 2014. I was an editor of the spec for three years.

A long time. Yeah. When do you sleep then? Well, in between open source and taking care of my kids, I squeeze in a few hours here and there. Wow. Yeah. 450 repositories.

Surely 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, it's that 80-20 thing, right? 20% of the packages take 80% of my time. You know, the rest are pretty self-sufficient. Okay. From the TC39 lens, when is Temporal coming? When can we use this?

Yeah, so when can we use it is the right question. So Temporal's 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 3, which to me tells me it's not ready. Like API changes? What do you mean?

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. Everyone did their best. Tell Adam what it is. He doesn't know what it is. Yeah, so- School me. Have you ever written code with a date object in JavaScript? Yeah.

So you may realize that the date object sucks. It is awful. Okay. Its API is terrible. It's like- I haven't used it enough to know that. That's fine. It is awful. Okay. Its API is terrible. I haven't used it enough to know that. That's fine. It lacks 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 JodaTime. 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, you know, 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. Okay, 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 proposal. As am I.

Hence, I say, when can I use it? Exactly. OK. So it's been in, it's a third phase. It's been working on it a while. So the stages are zero through four. 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. Okay, so it's settling down. Yes, 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 100 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. Is it 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 feature, 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. Okay. When your polyfill is done, let us know. We'll have a big JS party. Absolutely. And we'll all celebrate.

So have the moment JS folks actually obsoleted themselves, or will you still need something like that? they will have once temporal is usable in production unfortunately for in my opinion they announced that moment is done essentially like two years ago yeah um and i don't think they use the term deprecated but essentially they're saying you probably should stop using moment we're not going to change it anymore. Like, use Temporal. But because Temporal wasn't quite stable yet, like, I wish they had saved that kind of impact for the moment when it's stable.

But nonetheless, all of those things will become aligned at the point where Temporal is stable and ready to use. So you have closed doors and people waiting outside. Exactly. Long line of people waiting outside. Give me the Black Friday temporal day. Exactly right. And it is coming. Medrush, let's use it.

Certainly there's a lot of people that are still using Moment. Absolutely. For sure. Yeah. And I have a library that I maintain as well that uses Moment and I'm going to migrate it straight to temporal. People have been asking me to migrate it to date functions or the other alternatives out there and I just didn't want to do two migrations because the instant temporal is usable. Everything else is obsolete. So I'm

just going to wait until temporal is the thing I can migrate to. So that'll be exciting. That'll be an exciting day. Absolutely. Thinking about your open source and your life and your lack of sleep, are you able to make money off of this? Have you been, I mean, cause you you're kind of crucial at this point to the NPM ecosystem as a human, it seems. Yeah, I mean, 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 20s, I could do it full time. But I am not single and I have kids and I'm not in my 20s. 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 people's open source packages, mine 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. What accounts for the diff between those two things? I just think it's because there's no... 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 tech infrastructure,

their 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... It's invisible sometimes. Yeah, it's invisible. It's really hard to talk about it in a way that's quantifiable. You can point to it and be like, you have risked this amount of money because you didn't invest in this thing. It's really hard to demonstrate an ROI or impact to the bottom line. Right.

But it absolutely, I think, ties, like it 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. So when we go back to your packages and talk about the most supported and then the goes your company. So when we go back to your packages and talk about the most supported and then the most used, those are different, right? Yeah.

Why is the most used not the most supported? I think part of that is because most of my packages end up being people's transitive dependencies. So most of my stuff isn't like Babel or ESLint or Webpack where people are choosing it. Most of my stuff is chosen by the maintainers of those packages

or three or four levels deep. And so even though my code is in almost every application on the planet, the number of people that have chosen me is very small. 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. It might just be the way it is. 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. 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, everyone pays real close attention to the best actor or actress, but they don't pay as much attention to 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. In fact, even at the Oscars, I think they have the engineering-style Oscars

have their own separate banquet the day before or whatever. Because they know that's not what people want to watch. So it's kind of that same problem in a different situation. But the crucial difference here, though, is that that's a business, an industry, on TV. People want to watch. Yeah. Right. So it's kind of that same problem in a different situation. But the crucial difference here, though, is that that's a business, an industry, and 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 Tidelift and Thanks.dev. They are the ones like GitHub sponsors and Open Collective and so on are great. But Tidelift 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 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. How can we get you more well-known to the people that use you via transient dependencies? How can we get that visibility?

I wish I knew the answer to that. Okay. That's the hard 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. 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 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 dived deep and tried to become an influencer in that way. Right. I don't know if this is our doing, Jared,

but we just had the maintainer and creator of Askinema on the podcast. And one thing we kind of like did heavy-handedly, at least I did, and I think you agreed because you didn't. I agreed 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 Eskinema more full time a reality. And he has a get up sponsors page.

We link 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 two. If the number uptick is our doing, we added two from seven to nine. That's great. Is that great?

Well, so it's great in relative terms because 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, but it still is. It's the right direction. Yes, it's the right direction. It didn't go from seven to five. Right, exactly.

We're taking it back because of what you said. And seven to nine, that is great. It's just nowhere near sufficient. Yeah, exactly. And I think that speaks to— If I happen to get a new sponsor from this conversation, that's awesome. It's just like it's not one new sponsor that's going to move the needle. But if enough people do it, it will matter.

I think that the folks that should be paying you probably are profitable corporations that leverage the dependencies for which you are a transit dependency of. Yeah, I agree. It's not truly the listeners, but the listeners for which they have influence at the place they operate at and have you as a dependency in their graph. When people ask me about- And that's what I think our request is, is examine that. Be aware of it. Because if not, what will happen to you if this doesn't change in the next year or whatever timeframe?

How does that change how you operate in open source? Yeah. I mean, before I get to your question, I think when somebody sponsors me or they ask, hey, can I sponsor you? 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 cares enough to vote with their wallet. That matters. However, if you really want to help, go tell your employer. 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 pipeline hooked up. 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. It'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. Yeah. And so that's what I'd like to see. And then so your question is, if this doesn't change fast enough, what will happen? Well, I'm going to have to keep getting jobs that aren't full time open source and keep trying to squeeze it in. And as a result, like some of the things I really want to or need to work on are going to keep falling by the wayside. I mean, there are specific tasks, large tasks that I have wanted to do for years and have not had the time to do it.

I'm the maintainer of Enzyme and we don't support React 17 or 18 yet because I've been the only maintainer on it for seven years. And I haven't had time to like set aside a whole month or two to do it. And, but I've had a hundred employees of companies post on the repo saying, this is blocking us. We're going to have to spend a whole like developer month to like migrate our test suite to RTL or something. It's like, well, have your developers help me fix it. And like not one company has actually put money or time towards this problem. It could have been solved four years ago, but it's still not solved because I can justify taking a few hours or a day to work on something.

I cannot set aside all income for a month. Like that's just not realistic. That's a non-starter. That's uncalled for. Will you quit? Will you quit? Will you ever break? I hope not.

I haven't yet. How long have you been doing it? I mean, I have an unbroken GitHub streak dating back to 2014. What does that mean? Like, I've committed and or reviewed code and or merged code every day since 2014. Since 2014. Yeah. That's an amazing. It's a long time.

Are you sure you don't have a robot doing it for you? Gosh. I mean, no, it's a system that's incredibly easy to game and cheat, right? Yeah. So for me, it's more of like a kind of a meditative thing. Yeah. Where it's like some days I do a lot, but most days I'm just kind of checking in. I do a few updates.

I triage some things. I move on. Right? And it's the way just kind of checking in. I do a few updates. I triage some things. I move on, right? And it's the way I kind of keep myself regular. Very regular. 2014, man. You're coming up on a decade. Yeah, it's a ways. A couple years back, GitHub made these 3D prints of your contribution graph for a specific year.

And they mailed it out to select maintainers. And I went ahead and went on the site. It's like skyline.github.com or something. And you can download them for any year. And so I have a whole city now of my entire streak. That's cool. Just on my desk. It looks really cool.

Send us a picture of that. I want to see it. We'll include that in the show. That's spectacular. That is cool. So thanks.dev is cool because they're actually, tell us what they do. They generate where you send your money to based on your dependency tree? Yeah, so both Tidelift and thanks.dev, right?

You give them your lock file, your manifest, right? And then they figure out your entire dependency graph, and then you just put money in, and then they distribute it out. And thanks.dev gives you some granular control about how deep you can go, which probably appeals to some, but actually hurts me because I'm towards the bottom of that graph. But nonetheless, it's good to have more competition out there, more sites trying to get maintainers paid.

What do you know about their algorithm? Not much. You said earlier that you're in, rephrase it for me, it's not like you're in all software or a large majority of software out there? I am in most, I think, JavaScript applications, even a little bit. Like if you go and type npm fund in almost any JavaScript application, my name will be in there. Not everyone.

And it might be in there for one package, it might be in there for 50, but it's in there somewhere. And it might be an inconsequential piece, right? Like I'm not trying to claim that I am an irreplaceable part of most JavaScript, of even any JavaScript applications, right? It's just that I happen to be in there. Something I've done has made life easier for somebody along the way. Yeah. Have they spoken at all, Tyler, about the way they distribute those funds? I don't know if they've talked about the specific algorithm and how they weighed it, but I'm

sure they, I mean, they've been doing it for a long time. Yeah. And they have their upstream conference, you know, last couple of years. I was part of their keynote this year, actually, talking about how I took over packages when a former NPM author, a prolific author decided to kind of delete his GitHub and quit the ecosystem. And so I was able to take over like a dozen or so of his very highly dependent packages. So like I think that, so the specifics I don't know, and I think they tweak it, right?

I've seen the amounts change over time. I think that the goal, like Tidelift has a more kind of enterprise-focused goal, which is like you depend on these things and you need them to, you know, have a certain amount of security and responsiveness and so on. And so in, in turn for maintainers doing those tasks, they get a portion of the money. Thanks.dev, I don't have to do anything to get it. So that's more of a like, uh, patronage gratitude based model. Um, and so in that regard, you can support more maintainers because they don't have to do anything to do it, but you're not necessarily getting as much out of it as you would through Tideless. So it kind of depends on your preferred approach. And if I'm talking to a company who's

in a generous state of mind, I would encourage them to do both. Have you considered sponsorware? I mean, I've thought about it every time I've seen authors try it. I mean, I remember, like I grew up in the late 80s, early 90s, where shareware was a big thing, where all you get all these games, and you could use them for free, but they'd kind of bug you and be like, hey, if you send us five bucks, we can turn off this annoying warning. And, you know, I, I appreciated the spirit of it, it let me like, try out the software. And, you know, but I didn't have any money as a kid. So I didn't, I just ignored the warning the whole time, right. And very rarely did I end up when I had the money, get to the point where I was like,

sure, I'll pay for this. Yeah. You know, it just kind of didn't, because I kind of think of it as free. So I don't know if there is some solution out there, hopefully to, you know, the nice thing about sponsorware specifically is that I'm thinking specifically your example of Enzyme and all these engineers want this feature, this upgrade, whatever, call it what it is, this bit of code to be written. And they work for companies, like you said, who could definitely afford. Yeah. Right? And so you develop that in a closed source environment, but available to all your sponsors. Right.

And so if they're a sponsor, they're already in on it. And then you set a threshold. If I get to this many sponsors, it goes out to everyone. And so they can get their early access. They can afford it. It's not a kid who wants to play with a toy, right? It's a well-funded company. They can get access now.

Obviously, this does require you to invest because you've got to build it first. I think that's it. It's a chicken and egg thing. There is money at the end. If it's a desirable thing, there's money at the end. And because it's a sponsorship, it raises your baseline, right? Because now they're a monthly sponsor. I think that that would work really well if I had the sort of direct software like Babel, ESLint, Webpack.

I don't think it would work as well for my transitive packages, which are the majority of them. Right. So, but I think also, even if I had like, even if something like enzyme, I think that I, in order to spend the time to make something that would be compelling enough to want people to pay for early access to, I'd need to be able to pay for my time. And so that's the chicken and egg thing where like, if I had some companies show up and be like, we will pay you money for this early adapter. And as you know, but you have to keep it exclusive for us for six months or something. Yeah. Then I would do it because it would get it done faster than no money. But yeah, if but I'm not going to just do it and then like dangle it like a carrot that feels like it violates the ethos of open source to me a bit.

And like I can see that part of the challenge. Right. to me a bit. And like, I can see that. That's part of the challenge, right? Because the philosophy of open source and the reality of capitalism are contradictory, but somehow we have to mesh them,

right? Because of the world we're in. How, these issues, I'm assuming, with Enzyme, people saying,

hey, can't upgrade this and that. Have you reached out to that company? Not just those developers, but like done some proactive outreach to criers, the squeaky wheels. I did actually.

That one can't have because you haven't built it yet. I've had conversations with three or four companies. I even had a conversation with, you know, one or two very large, you know, big alphabet letter companies. And like, it's just never materialized. Um, one, you know, I had a company who I met with the manager and some of their engineers, and we talked about what it would take. And they decided that it would take about the same amount of time to migrate to RTL. And so they just did that instead. And I mean, that's their decision to make.

But if it's the same amount of time, they could have done it, not had to change their test code and benefited everyone. And I'm like sponsorware-esque, I guess I would have been happy to slap companies names on there. Like I'm happy to show appreciation and help market somebody that's helped me do something good. But it just never worked out. Yeah. We may be thinking about sponsorware slightly differently. So this is a model wherein... You're talking about like withholding a change.

Yes. Yeah, yeah. Providing that only, not for them to advertise, but for them to gain, it's like early access. Right. But then when you reach a certain threshold of sponsors overall, you're just going to put it out to everybody no matter what. Yeah, no. So it's kind of like a little bit of a middle ground.

Totally. And it works well, at least for a few people, but they tend to have more product-oriented open source. So definitely not for your transit dependencies. I thought maybe with Enzyme, it would be a situation where if you have 100 engineers like, hey, we want this. It's like, well, that's worth money to somebody. And I think it would be.

So I think Enzyme would be a good fit for that model. It's just that unless I have the work complete. No, I get it's worth money to somebody. And I think it would be. I think Enzyme would be a good fit for that model. It's just that, like, unless I have the work complete. No, I get it. You have to invest. Yeah. Which is not the easiest. You can't always do that. Exactly.

Yeah, totally. Yeah. But I appreciate the creativity. I mean, like, you got to consider all options. It's an interesting idea. Yeah. It's a way of going about it. Not all of your projects are going to be funded necessarily.

Right. You know, you look at an artist or a musician or a film, you know, certain you have one hit and that powers the rest of your things. And so maybe you have one project that's letting you work on the other ones. Can you lay out your open source income streams? Like what they are? Do you have sponsors? Open Collective?

Like, how do you structure it? How do you, how does it come into your pocketbook? Yeah, so I have a GitHub sponsor for my personal account. I have one for... And then I have an Open Collective for two of the GitHub orgs that I also have hooked up through GitHub sponsors through that Open Collective. I'm on thanks.dev.

I'm on Tidelift. I'm on stackaid.us. I think that's it. But I'm pretty much willingdev, I'm on Tidelift, I'm on stackade.us. I think that's it. But I'm pretty much willing to sign up for anything that might bring money. It's just anything that requires a heavy marketing effort from me is something that has to pay out in turn, and very few of the things have. I would say Tidelift and GitHub sponsors and Open Collective and Thanks.dev in that order have been the most lucrative. Tidelift first, huh?

Yes, by a large margin. That's good. Good for you. I like their model of the dependencies of the dependencies because all too often do you have a great, as you mentioned, influencer. Not saying that these people have been, but like Sean, Webpack, et cetera, these things have been great at promoting the project and getting the awareness, but they're also sitting on top of the other shoulders of other folks that it's not filtering to. And there's not enough money even coming into Webpack, let's say,

for Webpack to compensate its own developers and also to significantly compensate its entire debt graph. If there was, I would hope that they would do it. But there just isn't. And I know that that's the case for Babel, that Babel has barely enough. And you can't expect them to either. Exactly. I mean, I could ask them to, but I can't expect it.

You're all sort of fighting for the same customer, basically, in a way. Exactly right. Yeah. What a problem. It's a hard problem to solve. Yeah. Well, I'm happy to hear that 20-year-old single Jordan could at least do this. Yeah.

So that means you're not doing bad. That's actually better than most people are doing. Right. A lot of us are out there getting our eight bucks a month from our sponsors and that's it. Exactly right. But it is worth noting that it takes such an outsized level of reach to get to that point. Right. such an outsized level of reach to get to that point where like I could, you know, have a roommate in a studio apartment and like cover my food and my drinks for the week.

Like, you know, it's, it's better than most, but it's, and I'm grateful for it, but it's still not anywhere close to sufficient. Like we need to be in a world where somebody providing public value, like a public good is able to live their life without disruption. And that's not where we are right now. Yeah. What would you change about Tidelift, about GitHub sponsors? What would you change about how,

because it's all about distribution and awareness, and you're only one person, right? They have a company in both cases, profit in both cases. I assume Tidelift profits. They have marketing. They probably have marketing assume Tyler profits. They have marketing, they probably have marketing dollars they spend, they do upstream, they do a lot of outreach. What would you change about, I 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 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 and that counts. 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 trying to separate out the money. And on top of that, there would be so much money that companies like Tidelift and thanks.dev and so on would already be there to fill the gap and provide that accountability. The government would require a forum or something and can help filter the money to the right folks. I think that would just solve this problem.

Okay. Because like I said, capitalism, right? We have capital and regulation. And I think that unless we can... I can't come up with a big enough capital incentive that's convincing enough, but regulation could do it. Profitable companies.

Yeah. So if your company doesn't make any money, you're good. As soon as you start making money, every dollar you make, a penny has to go towards open source. There's a lot of very well-known, well-used, a lot of value even created by the company that doesn't make money. They lose money. Absolutely. And you could argue that they might even make money off of that.

Great. 1% of that could also go. Sure. Right? I'm not precluding them making money if they've made open source. Regulation's challenging. I see where you're going with that. I think regulation means.

That's what I said, magic wand. Yeah, I know. I know you did. I'm hypothetical-ing this a little bit. You might get into a world where it's like, well, we don't want to be profitable, or we're not profitable. We're already in that world. That's what companies do to try and ditch taxes.

Yeah, exactly. That's why HBO shows and writes them off, right? Oh, I know. Isn't that the worst? Like completely finished movies, literally, just not released. They could just release that on BitTorrent for the world to have. Totally. Makes no sense.

They deep six it. And that's your only change? Regulation? I think, I mean, obviously I would make many changes in the world if I had that kind of power. But I think that as it relates specifically to the funding of open source, I think that one change would be the most impactful. Could GitHub or Tidelift do more? I guess is my sub-question. Always. What could they do more of?

Well, I think Tidelift, all they need to do is get more subscribers. And that's a human problem, a sales challenge, right? Right. GitHub is in a position where they can do a lot more, but Microsoft would have to be willing to pump a lot more money into it post-acquisition than they seem to have been doing lately. Yeah. For example, I don't think GitHub Sponsors is really staffed right now

inside GitHub. And I think that... There's at least one person. I think they might have one person. But there should be more than one. There should be like a team of 20 people on that product, right? And I don't think there is. So a lot of things at GitHub seem to be understaffed at the moment.

How about NPM? How is NPM looking? From my external view, it seems wildly understaffed as well. There's a lot of things they need to fix, and the people working there who are doing great work are very overworked. What a world, man. I know it. Stop talking.

I don't want to hear any more of this stuff. You're starting to scare me. All right, well, let's chill your links now. GitHub sponsors, how do they hit you up? What do we do? GitHub.com slash what? L-J-H-A-R-B? L-J-H-A-R-B. LJ Harb. I'm that on everything.

LJ Harb. If you use JavaScript, you probably use his code. If you are in an organization that profits from that JavaScript, maybe throw him a bone. That's right. Type NPM fund into your Node code base. Join Tidelift. Throw some money at thanks.dev. I mean, just pick one or more ways and try and get your company to contribute.

Certainly do so yourself if you can, but it's much more impactful to take your employer's money than yours. Yeah, for sure. Thanks, man. Yeah, appreciate it. Thanks for having me. Okay, so stick around if you are a plus plus subscriber. If you are not a plus plus subscriber, you can correct that by going to changelog.com slash plus plus. It's better. That's right.

It's better when you are a plus plus subscriber because you get bonuses. You get no ads. You get closer to that cool changelog medal. But most of all, more importantly, you directly support us. And we love that. And we appreciate that. So changelog.com slash plus plus. There's a little bonus on here. Jared and I were in the hallway at our booth and we had some time where there was nobody else around so we were just like let's just uh let's just chat see what's going on and i think you'll enjoy it but again big thank you to todd lewis and team at all things open for working with us so closely every single year to

make us a part of what they're doing and also for letting us host the panel on the impact of AI on developers. You'll find that right here in this podcast feed. So look for it if you want to listen to it. Big thanks to our friends at Fastly, our friends at Fly, our friends at TypeSense, and also to Breakmaster Cylinder. Those beats are banging are banging banging make sure you check out our albums on spotify search for changelog beats stream buy whatever we don't care just enjoy it okay until next time Thank you. Game on!