Jerod Santo: Well, I was in college in 2004. I recall my teacher saying IPv6 is rolling out, baby. And I was like “What’s this?” Because they were teaching us IPv4. And they’re “This knowledge is going to be useless soon, because everything’s going to be going to IPv6.” And so I was very much expecting it. And I’m still using those IPv4 addresses. And I think a lot of the adoption is – okay, obviously, NAT changed things… Because they didn’t see NAT coming, where everybody would be behind a shared IP, in a local network. And that really delayed it. But I think the other thing that honestly has delayed it so long is like “Dude, those addresses are just too long. Like, we don’t like them.” Right?

Jerod Santo: Linus Torvalds built Git in 10 days

As if it weren’t already impressive… TIL the initial version of Git was hammered out in a mere 10 days back in April, 2005. It’s also interesting to note that Linux’s success wasn’t enough to rid Linus of his imposter syndrome:

that while he’s proud of having created Linux, what makes him “happy about Git is not that it’s taken over the world. It’s that we all have self-doubt, right? We all think, ‘Are we actually any good?’ And one of the self-doubts I had with Linux was it was just a reimplementation of Unix, right? Can I give you something that isn’t just a better version of something else? Git proved to me that I can. Having two projects that made a big splash means that I’m not a one-trick pony.”

This post by Steven Vaughan-Nichols is a great little peak into the history of Git to celebrate its 20-year anniversary. My only gripe is that the “Why has Git been so successful?” section doesn’t even mention the impact that GitHub had on Git’s adoption. Before GitHub, it wasn’t clear if Mercurial or Git would be the community’s DVCS of choice. After GitHub… well, we’re living in it.

Richard Moot: I mean, it’s interesting – I think you make a good point, because the one thing I was thinking about… I used to be very allergic to this; still kind of am. When you – I mean, I’m not opposed to monetizing APIs, but I feel like when you monetize APIs, you have to kind of go about it in the right way, because otherwise developers will never use it. But now with MCP servers, I kind of go “Well, it costs almost nothing for the developer to now go use your APIs”, because they can just have an agent go do it for them and call them for them, and the barrier to adopt adoption is much, much lower. And so it does sort of beg the question of “Okay, if we’re going to have, say, 10X more traffic, do we need to actually put monetization in here in some way?” Or go to the ChatGPT approach, I guess - we pitch our remote MCP server, and it’s five bucks a month, and you get near unlimited calls or something to connect to any of your other AI tools.

Joran Dirk Greef: My first feeling was – yeah, yeah, yeah, but really… Like, July 2020, as the project was started, I remember clearly there were three moments. The first moment was like “Wow, this prototype is fast. It’s like, the design works… Wow, this maybe could change things for the open source switch.” That was it. And maybe it could change things beyond, but I didn’t know. The second moment I remember was the DST, switching it on Kings of Leon, Crawl. The third moment was this wondering of – what actually happened was we designed it to be so much safer that yes, it gained adoption within this Gates Foundation project. We won trust, and they are integrating it today. It’ll power countries at the national level, who knows in how many years, but as it gets deployed. So we did solve the trust problem of being so much safer, because we designed it like that as well.

But then the third moment was people then within that project saying “This is all well, but open source is too cheap. Where’s the company to support it? Where are the people that are gonna be available to service and really work?” You need open source… So this system is Apache 2 open source, and all the software it uses – it cannot use software that isn’t open source, because otherwise it just would be a non-starter. So TigerBeetle was also created – like, contracting then, it had to be Apache 2.0. That was obvious to me open source, because otherwise you don’t fulfill the mission… Which is what inspired the performance and the safety, is actually to make this really safe, because it is people’s money.

So then the question was people were saying, “Where’s the company to support this open source? It’s too cheap.” But I still – I didn’t have a clear vision of like business model at that stage. And then it became clear, as startups said to me “Open source is too expensive.” [laughs]

Anurag Goel: So this is something that came out of Amazon, where back in the day Bezos or someone at Amazon was like “Look, team sizes should not exceed the number of people who can consume two pizzas.” And so if you have a team of 50 people, they’ll require way more than two pizzas. That’s not great. We want your team to be small enough, and we want their scope to be small enough. And the whole thing around service-oriented architecture - so everything is a service, and then all these teams build these well-defined interfaces that talk to each other, or that people have to go assemble themselves… I mean, in some ways, that’s also the Unix philosophy; you have tools that do one thing well, and then you find ways to configure them or use all of them together. So that is essentially how AWS - and not just AWS; I’m sure other parts of Amazon - that’s how they thought about organizational design.

[00:19:45.10] And it’s true that you ship your org chart, right? You’ve heard that one before, I’m sure. And when you think about it that way, that’s why AWS isn’t able to do an end-to-end application stack well. That’s why they falter. And it’s not something that they’re going to be able to change. But when you think about Render, we’re always thinking about stuff at the very top, at the very layer where we’re focused on what application developers want. We don’t actually build for DevOps engineers. We think they’re great, they’re valiant soldiers in this battle that they rage against complexity every day, but we live in a world, Render lives in a world where application engineers are responsible, and want to control their compute. So that’s a very different mindset and philosophy, and it requires thinking about products in a way that is fully integrated. Because as an app engineer, I don’t really want to both integrate Lambda, and API gateway, and something else, and then EC2, and then Kubernetes, and install all of this. No. I just want my app to be out there, to be resilient, to just work, and I want reliable, scalable compute.

So that’s how we think about it, and that leads fundamentally to very different products. And I think it’s pretty evident in how AWS has tried to build these products at the top level. We’ve all heard of Elastic Beanstalk, we’ve all heard of other attempts that AWS has made at building these higher-level products… And they fail. They fail – well, failure is in quotes, because at AWS’s scale, any product you launch will get some adoption, but it doesn’t become the gold standard for how to do it. And that’s because they always have these trapdoors. When you start out with something like EC2, then your incentives for making a high-level product aren’t as strong, because you can say “Well, if this product doesn’t work for you, you can always use EC2, and you still make money that way.” For Render, that’s not true. We’re not selling VMs. We’ll never sell VMs. Our platform is what we are selling. So if this doesn’t work for you, then we lose a sale. So we make it work for you. So that’s, again, a philosophical difference.

Matthew Sanabria: I’m not trying to be mean, or anything. Yeah, I’m not trying to be mean, or anything with that. I’m really not. It’s just, when I was working with open telemetry, I found myself always having to go to the source code, because there was either no docs, or the docs were far out of date and not kept up, and they were kind of meaningless at that point. And it’s like, if you’re telling your users to do that, then you’re going to suffer… Nobody’s going to know what your program does, adoption is going to suffer, people are going to be upset using your thing… And it just breeds an animosity using your tooling. Is that what you really want?

And you hit it right on the head, Jerod - a small paragraph describing how things are laid out or kind of like the concepts and ideas can go a long way to unlocking your mental model to understanding what it is you’re doing, and looking at it.

Jerod Santo: Yeah. Alright, next up, Rusty Nail.

[01:11:43.11]

Hello there, listeners. My favorite moments of the year are, number one - big thanks for remastering “10,000 hours of deliberate programming.” That was my overall favorite episode for the two plus years that I’ve listened to the podcast.

And I’ve been meaning to come back to that episode. However, I don’t have to do that, now that I relistened to it again in the main feed. Number two, in Go Time 332, the discussion of the founder mode led me to a conclusion that I’ve always had it in myself, but I didn’t know how it was called… And during this summer, on one of the interviews I was asked what made me an outlier among my peers and co-workers. And now I know what should have been the answer, which at the moment I did not. Now I am prepared for the next one.

In the episode 611 of Changelog I was really excited to hear the voices of the core Python developer team. I’ve programmed in Python all my career, and I have never interacted with these people in any way. Hearing the voices, I was genuinely excited about it.

In Practical AI 257 it was mentioned how the role of corporate culture and non-tech people impacts the AI adoption in big corporations and organizations. And that was an eye-opening moment for me. So I was really excited to hear that.

Number five - my absolute favorite episode of the year is when the secret service or police was knocking on the door… I think it was episode 609, for not even hacking, but vulnerability reporting. And with a few of the jokes that went along with the story.

Next, we share a fun fact in our morning stand-ups, and the day I learned about the bus factor from the Changelog & Friends number 70, I had to share the fun fact. I shared with the team what the bus factor was, but it was actually called morbid by our CEO.

And finally, I think we’re missing an insane hiring market episode this year… And this was the year that I shifted my job. First time over the last five years. And if you are going to do it, I do have a question to ask… It’s more like a paradox. If everyone complains about not having enough talent and people to hire, when you apply for a job at some company, you never hear anything back if you don’t have any connections there. How does this paradox happen?

Jeff Smith: [31:35] Well, I think it’s incredibly important to keep the human at the center of it, and just look at the integrity of the data, and look at the integrity of the communications, how we’re really working with them, treating with them… What are they seeing – even in the E-score, we couldn’t say that “Hey, you’re a 85 and I’m a 75”, because that might make me feel like “I’m not optimized”, you know? And so what are all the little things? And we even have some of the team that developed the Oura ring and the visuals there to to look at it… I would just say – I mean, we are a purpose-built company. We are all capitalists, but our true North goes a lot deeper in our purpose, our faith, and how we’re driven.

And so from our standpoint, seeing this as a tool for human flourishing I think is just super-important and sacred, matching with how sacred and epic music is. It’s just historic; it speaks to our soul, it goes so deep. And so we want to make sure we steward that well.

Now, in this process you’ve got all the baggage, all the red flags, the landmines you have to look for. Inside of companies, it is privacy, it is data integrity and security, and you look at the user experience and the rate of adoption, and then the whole way – and if we stick to that true North, you’re going to get there. You’re going to get the numbers, you’re going to get people participating… The moment that you violate that, you’ve lost them. And that’s just not something we’re willing to do as a company, as a team, and where we’re headed.

So it’s just been fascinating to see that for us that’s normal. Even how we’ve built the company, we want to do life with people we love. And at the investor level, and the clients, and everything. And what we’re finding inside of companies is trust is so important. We’ve turned away some C-suite that have come to us saying “Hey, we want you to bring this in and fix our culture, because our culture sucks.” And then you realize it’s because they do. It’s just, they just want to get more out of the apple. And so we want to work with companies that care about their people… Yes, retention is important, and productivity is important, and if you have flourishing companies, you have flourishing cultures… But who’s at the helm?

So I think we’ve just used that language and vernacular, and never knowing these environments, if that’s foreign or regular. But I know even from your own leadership and your direction, and our relationships that feel comfortable sharing, that purpose is at the core.

Break: [34:00]

Mitchell Hashimoto: But I don’t just dismiss it. I do think “Can I as a terminal emulator mitigate this bug?” But ultimately, this is not my bug. And so yeah, it’s a lot – it’s frustrating. It’s also frustrating because all the cool new post 1.0 features we want to build, that we kind of touched on - it’s going to be blocked on downstream adoption, right? It’s like any – you know, a web browser comes out with a feature, it doesn’t matter until a website implements it. And so that’s going to happen here, too. But if we have – I’ve joked around building a Ghostty shell that only works in the Ghostty terminal emulator. So it’s kind of crap, because you would never use it remotely… But it’s more of a tech demo of like “This is what shells could be if they implement all the capabilities of Ghostty.” It’s kind of like a Chrome web experience, web experiment. We need the Ghostty terminal experiment, where people visit it, and – with the Chrome one, I would visit it and be like “Holy crap, a browser could do this?” And then it changed my whole perception of a browser, sometimes years before any website behaved similarly. And I have talked with folks about doing the same thing for terminals.

Jerod Santo: It’s now August: Turns out most programmer are unhappy. Llama 3.1 gives ChatGPT a run for its money. Scientists confirm flow state is a thing.

Coolest code: ChartDB. What’s cool about this open source, self-hostable web app is its instant schema import:

Run a single query to instantly retrieve your database schema as JSON. This makes it incredibly fast to visualize your database schema, whether for documentation, team discussions, or simply understanding your data better.

Best prose goes to Do quests, not goals. I love David Cain’s re-framing of short-term goals (which are uninspiring) into quests! “I’m on a side quest to fix my Vim config” is a lot more fun (slash impressive) than “I’ve been tweaking my Vim config the last 4 hours”

And my fav episode: Why we need Ladybird

Getting to interview defunkt (Chris Wanstrath) alongside Andreas Kling was the cherry on top of this delicious episode. We discuss what it’s going to take to get to alpha, the why behind Ladybird, avoiding incentives other than those of the users, their plans for incremental adoption of Swift as the successor language over C++, and of course what they hope Ladybird can achieve as a truly independent open source browser that’s for the people.

Kent Quirk: [00:20:08.15] I mean, that drove an awful lot of Node adoption, because people are like “I’ve been coding in frontend in JavaScript, so why can’t I code the backend in JavaScript?” And that was in large part why the team that I had worked on was using it. And once you realize that there is a bright line separation between those two, there’s no particular reason that doesn’t justify, in my view, wanting one language. The languages are pretty fungible. You can you can switch between different languages and get the thing done. It’s the systems around those languages and what they give you, and that’s one of the big benefits of Go. I think, from my point of view, the most enormous benefit of Go is the fact that if I went back to the code I wrote in 2014, I could even compile it with the current Go compiler. I can read it, I can maintain it. And Go, beyond – like, the JavaScript code we had at that time wouldn’t even run today. And it would be considered five generations old. And one of the major, major, I think, advantages of Go is its long-term maintainability.

The Go 1.0 compatibility promise has been really, really important. And the fact that that code - I can still read and write the same code, in the same styles, for a decade… It turns out software lives a long freaking time; a lot longer than you wanted it to. I’ve got stories about that too, but man, you’ve got to be able to keep working on it. And the pain of – you know, we just watched the team switch from React 16 to 18… That was a painful multi-month effort, by multiple people.

Shruti Kapoor: Absolutely. And that’s why we have PR reviews. However, I think because it’s a starting point, it’s not the final product, or it’s not the final state of your code, I don’t think the adoption will be delayed, because the people who are building these components, when it comes to optimizations, they would reach out to like React Compiler, or like use hooks, and things like that to optimize, instead of just waiting on what the AI has given them. At least as of now. So even if React 19 is introduced tomorrow, I do not feel that it will actually delay us.

Johannes Schickling: So for what it’s worth, a lot of the technologies there in the works right now, off the shelf, local-first-ish technologies… You’ve mentioned some of them, such as Electric; another one that’s coming out soon is called Zero Sync, by the folks at Rocicorp… Their previous product was called RepliCache… And so what both of those technologies have in common is that they lean into your existing Postgres database, that you can partially sync the data that’s in that Postgres database, onto your client, and then you have an experience where you can still locally work with the data, in either an optimistic way, or like save some of the writes offline, and process them when you get online again… That’s sort of like a sliding spectrum of what is not yet possible, eventually possible… But they’re heavily leaning into that incremental adoption story, which I think makes it much easier for people to say like “Hey, we have our existing app, we have our existing API, we have our existing, for example Postgres database… We want to build a new feature, we want to overhaul this existing feature, and for that we want to lean into sync, we want to build a real-time collaboration experience…” So it is getting there, but I think if someone does have the freedom and luxury to build a greenfield app, and who wants to really – in the same ways people are trusting Apple Notes… It’s like, you pull it up, you click that New Note button, and off you go; there’s nothing in your way. If you want to have that sort of like no asterisk experience, I think the best way to get there, and also have a great developer experience, is to fully lean into it.

Jerod Santo: And so if you want to follow Changelog on Blue Sky, by all means, please do. But I’m not personally on there. And I know that they’re getting massive adoption all of a sudden, at least in terms of brand new social networks go. They’re getting a huge uptick, and people are raving.

Jerod Santo: Yeah. I think as it gets more powerful, you’ll have more people wanting power tools to use with it. And you’ll probably always have the people that want to just use it in a browser tab. But I think eventually, with adoption, it makes sense to go deeper into those integrations. Did you train it then on – you’d mentioned some docs, and stuff, but did you start… How’d y’all build the thing? It was like a foundation model that you fine-tuned, or start from fresh, fire up some AWS EC2 instances with big GPUs?

Jerod Santo: Tactile controls are back in vogue

Here’s Gwendolyn Rak, writing for IEEE Spectrum:

Apple added two new buttons to the iPhone 16, home appliances like stoves and washing machines are returning to knobs, and several car manufacturers are reintroducing buttons and dials to dashboards and steering wheels.

She goes on to interview Rachel Plotnick, a leading expert on buttons and how people interact with them, all about the pendulum swinging away from touchscreens and back to physical controls. This is yet another instance of the tech industry’s propensity toward extreme adoption before settling in to a reasonable balance. It’s like:

1. Here’s a New Thing!
2. New Thing GOOD, Old Thing BAD!
3. Let’s use New Thing everywhere!
4. Hmm, New Thing doesn’t work great everywhere!
5. Let’s go back to Old Thing, where appropriate!

You’d think we could skip a few of these steps, but I guess we just can’t figure out “where appropriate” without first realizing “where inappropriate”. C’est la vie…

David Heinemeier Hansson: And this is one of the things I’m just excited about with Rails 8. So if you wanted to use SQLite for a web application today, you have to know a fair amount of a little bit arcane knowledge about how to set things up in the right wall modes, and set the right pragmas, and do all the little tweaks… Because SQLite folks are really dedicated to backwards compatibility. So if you start a SQLite database from like 2005, it’s going to load, it’s going to do all the things. They really cherish that. Which means that to run SQLite in the way we would want to run it today on a multi-tenancy or multi-user app, you have to set a bunch of tweaks in it. And that was a little bit, I think, of a barrier for some folks that would start using SQLite that hit all these exceptions. Oh, I can’t write right now. It just throws an exception. “Well, yeah, you’ve got to build up a thing, where you do a retry, etc.”

[01:09:57.19] Rails 8 has all of that built in. It is fully configured to use SQLite to the best of its current ability, with all the correct pragmas and all the correct protocols of how to use that database well. And I think that’s what’s going to really help adoption - when you don’t have to know all the little arcane bits and pieces and you can just rely on the fact “Hey, this is a database in a file, and it works.” Awesome. Let’s go.

Jerod Santo: Arc is a dead browser walking

I verbalized my concern with the (otherwise exciting) Arc Browser being venture-backed on a couple occasions. Concerns realized!

Arc has gained a loyal user base but ultimately hasn’t achieved mainstream adoption, which the Browser Company wants. CEO Josh Miller spoke on a YouTube Video about the company’s realization that Arc, due to its complexity and unique features, caters more to power users and might not reach the wider audience the company wants…

They’re now working a new browser that they hope will go mainstream. That’s a hard pass from me. Fool me once, shame on you. Fool me twice…

Shay Banon: So I think that sometimes we make the mistake of judging open source based on – it’s like, we always liked the songs when we were teenagers, and they’re stuck with us, and it will never be better… So some of us remember open source licenses and usage like it was in 2004, and 2005, or 2003, and 2007… And it’s like, how many hours did I spend around the differences between GPL and Apache? That was within open source, by the way. And it’s like “Oh, you can’t choose one versus another.” I think developers today, they pick an open source license and they’re fine. You know what I mean? It’s like, they care much less about the fidelity of difference between Apache and, for example, AGPL.

I actually also think that big companies care much less about – like enterprises. We used to say Apache is much easier for enterprises to adopt… But look at MongoDB. It’s all over the place in large enterprises, and it’s AGPL, you know? So obviously, that’s not hurting adoption; or it was AGPL. So it’s not hurting adoption.

[00:34:16.06] And I think a similar thing might happen in AI, and that might be the missed opportunity. We see open models, we see open this, we’re saying open source AI, open source models when they don’t strictly match the definition of open source. It doesn’t matter about OSI or not, I just don’t want the term open source to get diluted. And I think that’s the responsibility of OSI, and us, by the way, to help, to try to figure out – because we obviously play a big role in gen AI as well, and building models, and things like that… To figure out how do we build a system that allows for it. Because you just don’t want it to be diluted to become a term that means everything.

Zac Smith: Well, I took away from it something and I saw this with a lot of larger companies, and it really gave me this newfound respect, both for market leaders and for startups. And I used to see them as very in conflict. And actually, I can see why great market leading companies have muscles around acquisitions. Because in market leading companies - there was a really good book, I think it’s Zone to Win. Have you ever read the book Zone to Win? It basically talks about there’s four zones in a company’s lifecycle or where its products are. And the upper right zone in the quadrant - just think of a two by two - is the kind of market leading. You know how to sell it, you’re leading the market, everybody knows that you do it… That’s where it’s all working.

Then kind of like below it you have the stuff that’s like starting to work. And I think they call them like Horizon One and Horizon Two, something “It’s right here, or it’s like a future opportunity.” And then over on the bottom left - and I’m totally bastardizing this, so please, somebody google it, and it will make a lot of sense. But on the bottom left you have like innovation, which is this kind of like incubation zone, which is not even a thing yet. We don’t even know. It’s super-weird, it’s super-scary, it might fail, probably will fail, we’re not sure… And then you’ve kind of got this adoption zone, where it’s like “Oh, it’s starting to work.”

What I realized is that the zone up on the right hand side where it’s winning, it’s that way because it actually figures out what works; for example, with Equinix, interconnected co-location works. They dominate the market, they’ve been doing that for a while, everybody knows that that’s what they do… And they then build processes that keep that market leading around it. And so internally at the company - and I’m sure that this is at other market-leading companies like say Google, right now with their ad business - there’s a very protectionist approach. Like, don’t distract from winning at the thing that is working. Like, don’t get us off track, because we’re nailing it every quarter, customers love it, we’re dominating the market… Keep doing that. But what that can do is that can obviously take something that looks not working yet, e.g. incubation, or some sort of innovation, and kill it. Because it’s a distraction to the market-leading component of the business.

[00:23:55.02] And so that was definitely one of the challenges we had at Equinix, was they were trying to figure out how this 20 years of market leadership they had around a single thing - well, what happens to the next thing? What do they say about – there’s this funny phrase, it’s like “I went broke slowly, and then all at once.” It’s like, it’s it was working, and I was the number one until – I mean, look at Intel right now. Until I wasn’t.

I think that there was a good self-awareness at Equinix, like “Hey, how are we going to upgrade our products and our experiences for the next thing?” And so acquisition is part of that. And I think startups play a great role, because there is no past. All they have is future. So there is no zone that is swapping away innovation. Everybody’s like “All ideas are good, because we need to figure out how to survive, or make the next wave.”

And so I think that’s super-interesting that companies who have figured out how to do that over and over and over again… And whether they figure out how to incubate, like what maybe certain companies do with labs divisions, or open source, or side projects, or through M&A. I had a very much renewed appreciation for that cycle.

Adam Jacob: Someone’s using BladeLogic. But you can sort of force those – if the technology has enough compelling value, people will replace it over time. But yeah, our goal is that we definitely – I lived that experience with Chef, where… I didn’t love how long the adoption cycles were, and how all or nothing it felt. And so yeah, we’re hoping that part of that adoption cycle is actually just – it’s going to start with just importing the things you already have, that you want to deal with, and then over time you could track just the resource side of that and be like “Well, I can show it to you in a diagram, and we can see what its resource value is.” But then it sort of starts to make sense that like “Well, why wouldn’t I also manage it through here? Because it’s here, and it’s easy, and it’s straightforward.” I think that’s probably how that goes.

There’s all sorts of interesting possible futures, where you do like automatic discovery of things… But there’s a lot of interesting problems with how do you lay it out, you know? And – anyway, there’s a lot of interesting stuff hiding inside there, but like…

Jerod Santo: Yeah, this is a very cool one. It’s basically like - I like a tool that just upgrades your life and doesn’t require anything else. Like, there’s no learning curve, there’s no adoption really… This is a shell history upgrade, basically, built by a gal named Ellie Huxtable. We’ve had her on the show a couple of times. She’s web smart, and a great, great user experience person. And basically, the up arrow or the control R, searching your shell history… If you’ve done that, which we all have a hundred times - like, this just basically improves that in every possible way.

And so you install it, it runs in the background, and it takes over certain keystrokes in your terminal, in order to have fuzzy search on your shell history, a lot like FZF would be, if you configure that yourself, but it’s very pretty as well… And then it also offers advanced things. I don’t care about like syncing your history across machines and all this kind of cool stuff… I’m a one-machine person, so I don’t really have that problem… But if you had a desktop and a laptop and you went and shared shell history across everything, she has a service that encrypts that, and synchronizes it around, and… It’s an awesome cool. It also provides stats, which is fun. You can look at your most used commands and stuff like that.

Kevin Ball: [00:20:35.03] I mean, I buy that Vite is the fastest-growing tool chain, and I buy that… Adoption is not his problem. He’s built amazing tools, that people are adopting. My reservations are not around whether or not he’s going to be able to be successful building something cool. It’s more around as he gets down 12 months from now, 18 months from now, when the funding from that seed funding is starting to wind down and he’s having to look at “How do I either make this thing profitable or raise more money?”, what does that do to the focus? Where does that take them?

Again, Evan has built amazing tools, that have made almost everyone in the JavaScript world’s lives better. He has also done one of the better jobs I’ve seen in terms of starting something as a benevolent dictator, and spreading it into a team-driven project. Vue governance is phenomenal. I haven’t been as close to what’s going on in Vite, but I imagine it’s the same. It’s gone from like one dude, to “Hey, this is a community project that is well-run by the community, that still has this brilliant guy contributing a lot to it.”

So he’s going to do something really cool by taking VC funding. I think that dramatically ups the likelihood that what he does that is really cool starts shifting over into some sort of paid service, and the open source tool chain suffers for it.

David Berenstein: The usage and adoption has been quite good, in terms of the number of datasets that have been released. So you mentioned the Intel Orca DPO dataset, which was an example use case of how we were initially using it, where we had this original dataset that had been labeled by Intel employees, with preferences of what would be the preferred response to a given prompt. And we actually used this label to kind of clean that, based on prompting LLMs ourselves to re-evaluate these chosen rejected pairs within the original dataset, filtering out all of the ambiguity. So sometimes the LLM wouldn’t align with the original chosen/rejected pair, and based on that, we were actually able to scale down the dataset by 50%, leading to less training time, and also leading to a higher-performing model.

And that was one of the really famous examples that kind of inspired some people within the open source community to actually start looking at this label, to start using this label to generate datasets. There are some Hugging Face teams that actually have been generating millions and millions of rows of synthetic data using Distilabel, and that’s pretty cool, to see that people are actually using it at scale.

And besides that, there’s also these smaller companies, so to say, [00:52:34.02] the German startup that I mentioned before, using it to also rewrite and resynthesize emails within actual production use cases.

Łukasz Langa: Yes. So we can make this good cop, bad cop, or actually devil’s advocate… You know, this guy - he’s trying to convince you this is good. So I’m also the release manager of some ancient Python versions. In fact, when Python 3.13 comes out, the first version I released, which is Python 3.8, is going end of life. So we’re going to say goodbye to that.

It was a very, very nice release. I really enjoyed Python 3.8, but it’s time to move on. So if your use case, if your production is still running on 3.8, now it’s high time to move, since it’s not going to receive any security updates anymore.

Right. So at the time I joined as the release manager, the release process was a little bit hand-wavy in terms of when are we releasing Python. So the theory said we’re releasing it every 18 month-ish. But it could be anywhere between 18 and 2 years, and you know, you couldn’t really tell. And definitely, what you could not expect was which time of the year is this going to happen in. And the consequence of this was that Linux distributions in particular, but also other operating systems and users, were lagging behind adoption of Python 3 versions a lot. And people are like “Well, Python 2 no, because Python 2.7.” But Python 2.7 was out, and then essentially frozen for a long, long time. So people forgot how this thing looked like before, in times of Python 2.3, 2.4, 2.5, 2.6, and then 2.7. That unstable release cadence was problematic. And that caused, for example, for Fedora, which later is source for what is happening in Red Hat, was lagging behind with the releases that we had. And it turns out that the infrastructure that the big Linux distributions have, like Ubuntu and like Red Hat, is extremely useful for us to early find bugs in a new version that we are developing, in the betas, in the release candidates, and so on. So it would be worthwhile if we could actually ship the newest version of Python with those Linux distributions as they are also developed and go through their respective betas, and so on. That’s also great for the end user, because then by your autumn release of Fedora, you are released with the newest version of Python, that was just released. That is a great experience for the end user.

So I wrote a PEP, a Python Enhancement Proposal document, arguing those things that I’m just telling you… That it would be amazing to have a fixed release cadence, that we can trust and share with the Linux distributions, such that they can essentially rely on us having certain milestones in the release, like reaching beta 1, like reaching release candidate 1, so that they can use the latest version as soon as possible. And we switched to that release cadence in Python 3.9, and we’ve been using it ever since. So yeah, your honor, that’s my position on this issue.

David Flanagan: I mean, I’ve sold my soul a few times over now, but yeah, I’m in a good place. Yeah, DevRel’s – things are tough right now. I’ve got a lot of friends that have lost their jobs, and the entire tech market is in a major phase of cutbacks… But DevRel’s not going anywhere. I think we all agree, developers - we smell market bull***t a mile away. And the problem was all these companies hired DevRels to be marketers, and not to do proper developer advocacy and relations. And then they put out market [unintelligible 00:42:11.20] content, developers smelled the bull***t, and now they’re all like “Oh, we’re not getting the results we expected.” Like, no s**t. Like, you can’t just take the same thing you’ve been doing for the last 20 years, call it DevRel, and then expect to have a massive upturn in your business.

And there’s also the challenge that a lot of people are looking at like the Linux Foundation and the Cloud Native Foundation as free marketing, donating their projects… And that’s causing a lot of hassle too, because these projects think “Oh, we’re now an incubating CNCF project. We’re going to get all of these contributors. People are going to fix all the bugs and we’re going to get all this adoption.” But you’re still just one project in a sea of many, in an evolving landscape, with developers that are frustrated trying to keep up with this race that they didn’t sign up for. No, it’s not going to work.

So I think we’re going to see a lot of change over the next two to five years. Developer advocacy and relations is going to be stronger than ever, with the right people, with authentic, credible messaging, with companies that get it. And everyone else will go back to doing what they were doing before. Dodgy mailing lists, dodgy advertising, and… Yeah.

Jerod Santo: [00:18:21.01] Well, perhaps in the spirit of open source we can also help them do that. I think our adoption would be useful in that sense. Let’s talk about some other things going on. Of course, with open source companies, you’re always afraid of a rug pull, as we’ve experienced many a pulls, especially of late… How about this? I’m calling it “the reverse rug pull”, in which they, I don’t know, put the rug back. Elastic. Elasticsearch. Open source once again.

Adam Stacoviak: What does it take to go from this DIY proof of concept to adoption and production? What would it take to make that become real?

Christopher Hiller: So it’s a different, separate system. But yeah, you can do that sort of thing. I haven’t needed to yet, and I can report back if I ever do… Which I’m sure I will, eventually. But yeah, the mocking stuff works great. Assert is still assert, which is not super… But there are other assertion libraries out there, too. And yeah, I’m pleased with it. I’m happy it’s there. The more adoption it gets, the more terrible things that people are going to try to do with it, and so… Who knows if that’s going to become an issue later. But for now, I’m really happy with it. It works great. And kudos to Colin and the rest who have been working on it. I think Rafael or something, too. But yeah, happy with that. Node’s test runner.

Jerod Santo: Well, someone’s going to do it. I mean, as you guys have success – now, whether or not they can actually pull it off is the question, right? But there will be, at some point, as WarpStream continues to grow, a Hacker News number one story, “X is like WarpStream, only it’s open source and self-hosted.” And it’ll get 500 to 1,000 – and maybe it gets adoption, maybe it doesn’t. Maybe by then you guys are so far ahead it doesn’t matter… There’s tons of what ifs. But it will happen, from somewhere in the world, if you’re successful.