Adam Stacoviak: Mm-hm. The main concern, I think, if I understood correctly, around even making this a concern for you was the fact that Synadia was having challenges securing certain contracts because of its incubation status of NATS, which Synadia is built on top of as the commercialized version of it… Is that the summary of your initial concern?

Anthony Eden: So we’ve never – aside from the very early days, we’ve never grown a ton. My CFO likes to call us DNReliable, because the growth rate is just so kind of steady. This is to say that’s exactly how – that’s fine, because that’s exactly what I wanted in a business. When I first started DNSimple, I very – again, I made a conscious choice. I said, “I don’t want to take other people’s money. This is not a business that’s going to be a rocket ship that if we throw dollars into it, it’s going to return tens of thousands of dollars”, it wasn’t the goal, “for each dollar we put in.” It was meant to facilitate the life that I wanted to have. I have four kids. They’re all – the last one is almost ready to graduate high school. And they were kids throughout the entirety of DNSimple, and the vast majority of time I was able to be there with them and for them, we were able to travel together, we were able to enjoy our lives together… They had all kinds of opportunities to do things because it wasn’t a business where I had to go “Oh, I’m going to spend 80-90 hours because I’m trying to help somebody else become rich.” I was already rich in time. And that was an essential part of the construction of the business.

We have grown though, and we continue to grow. So the way we grow, for example, right now is that – engineers are still our champions, but we’ve found ways to work ourselves into some enterprise-level contracts. And so we do that because there’s a lot of enterprises that are still on legacy software or legacy registrars that are really suffering. And so we go to them and we say “We can help you. We can help you on board, we can help move your domains off these other providers, we’ll do whatever it takes to get you on board. And once you’re with us, you’ll have a stable system and you can have a consolidated system.”

And then we built other software. One of the things we launched a year and a half, two years ago was what we call our domain control plane. The idea was that if you have some domains that you’re managing at, say, Route 53, or in Azure, you can actually connect from DNSimple to those services and see those domains and actually edit them and have bidirectional synchronization between DNSimple, Route 53, as your core DNS on-prem. And that’s cool. Like, that’s something we think that some of these folks that are running in legacy systems – or the reality of running enterprises is that you don’t have just one place where you put everything. You were talking about that earlier. Like, “How did we end up with four or five different registrars?” Well, that’s just business, baby. You are gonna get spread out, because as your company grows, you’re gonna have people off here doing something different than people off here, and their needs are gonna be different.

[00:40:05.09] So yeah, that’s how we’ve kind of facilitated the growth over the years. But we’ve never strived for massive, fast, rapid growth, because it just wasn’t in what I wanted to do, it wasn’t – I had done a little bit of that in the previous startups. I worked for LivingSocial as well for a little while, so I saw the good and the bad of trying to do that.

Amal Hussein: It was like this horrible thing where they – yeah, only three people got offers to transition into GitHub. One of them was the founder, the other one was the community face, so they couldn’t… Obviously, that would be bad. And then the other one would be – the other person was just the lead, the architect that was still there. The single person that had the continuity of the legacy codebase. And then other folks were put on short-term contracts just to finish up, and/or laid off. It was rough. So yeah, after that I ended up at a pretty – at the time, a pretty cool unicorn startup called Indigo, which is like an ag tech company.

Salvatore Sanfilippo: Exactly. I believe so as well. There was, I believe, some – I was not part of the company when this happened, but I believe that this was a consideration. But then, you know, sometimes also the legal advice that you get… I will say something a bit maybe unpopular, but I think that the legal offices in companies sometimes create the worst possible setups for companies. Because the legal offices don’t really try to usually balance the risk, the legal risk with the company potential, but they are mostly going always to err on the safe part, in order to be right later. If you are super-conservative, you never do anything wrong from your point of view. However, you are paralyzing the company.

Many times when I had to do contracts, I skipped the lawyers that were in between and we could not understand each other, and said “Okay, I will write the contract. This is the contract. If you want, you can fix the form”, and immediately, the thing started to immediately to work, the conversation. And I believe that sometimes it can happen that choices are – but if you read the AGPL license very, very well, you actually discover that also the form is not extremely clear. It’s not very well written. So I believe that it’s very hard that somebody will authorize to use it in a software as a service setup without any kind of a signed paper by the folks that have the copyright. And this could be a good – I think that they did a good thing switching back. Basically, in this kind of changing setup, you try, and you believe “This is very similar to AGPL. People will accept it.” Instead, you find the cultural resistance, and then you step back, “It makes sense. I can understand that.”

Break: [00:40:09.20]

Adam Stacoviak: For sure. I’m actively trying to fit it in into everything I do, is I guess my perspective. If it’s home lab, it’s that; if it’s contracts, agreements, proposals, if it’s thinking, if it’s exploration, if it’s coding, if it’s… You pick it’s, your if it’s, kind of thing. I’m trying to fit it in, and I’m just – so I’m sitting down on my bench, I’ve got my socks on and I’m trying to put the shoe on, let’s just say…

Adam Stacoviak: But I feel like that’s kind of cool that you can do that. I feel like Ollama is – and maybe thanks to DeepSeek… We’ve been talking about Ollama for a while, but I’ve just never actually been curious enough to play with it. For whatever reason I just haven’t, let’s just say. But now I’m in this kick, like I mentioned, of – I’ve got two things resonating with me.

I really want to build some sort of AI home lab, and thus far I’m just using what I have… Because I think that’s where you should begin, right? If you want to know where to begin, what do you have? Play with that. Even if it can’t run anything super-powerful, begin where you are, basically. But now I’m curious enough to be like “Well, would it make sense for me to take my hard-earned dollars and invest in hardware?” One, for just curiosity. Two, maybe we can get a sponsor to pay for it. Three, maybe we can make some content from it. But four, just have this AI as a service with models I’m going to swap out as this becomes more and more popular, on my own network. You know, tie in a Home Assistant, like you’ve done, maybe even side-train a model where I can take this sort of like really small model and say “This is the way we propose things. And these are all of our contracts over the last two years”, and let it have that source of truth. And now it’s just super-smart with the way we do business.

I don’t want to give that kind of – sure, I could probably do that with ChatGPT… But man, wow, what an exposure point. Here’s all of our contracts over the last two or three years… Could you imagine that? No. I would feel much more comfortable doing it… And I think that’s the angst, is like everyone has to give up some version of privacy to play with artificial intelligence; or you have some version of plagiarism. Well, I’m sorry to tell everybody, like, AI is here to stay. There’s no putting that genie back in the bottle. And you can be against it if you want to be, and you can ignore it if you want to, but you will be behind. You will. Because young folks - and I don’t want to say just young folks, but people that are born into the world today, with the way technology is, they don’t know any different. You and I, Tim, we grew up probably in the dial-up days. You probably remember how AOL sounds, right?

Adam Stacoviak: [01:36:04.22] Well, I think it’s normal to fantasize about that. I think it’s normal to fantasize about that up until the point of actually doing it almost, because it is kind of the… I don’t want to call it the Easy button necessarily, but it’s certainly a lot easier than the constant roller coaster of running or creating your own thing. Because when you run or create your own thing, you are fully in charge, especially in a scenario like we are in in particular, which is indie media. We literally have yearly contracts that change, if not quarterly contracts that change. So it’s super-challenging for us to build a business foundation beneath that… And we only get driven by previous year’s data. So if the trajectory is up into the right, we feel a lot easier pushing on the gas. But every year is a roll of the dice, basically. Like, who’s going to come back and love us the same that they did the previous year? Or who’s coming up new that we really can support, that will support this indie media business we’re building?

And I think it’s super-normal to fantasize about this “What if I just got a real job? And then I wouldn’t have to worry about any of this stuff.” But then I think, “Gosh, I would have no, or seemingly no agency over my day-to-day.” I can’t command my own dreams. I can’t have these big ideas, and then begin to execute on them incrementally, over time, and tackle big problems I think are worthy of solving, versus what someone else tells me their dreams are. Something they think is worth being solved. And I think that’s where I empathize, because the Easy button, to some degree, is just to go get a job, and work on somebody else’s dreams. The hard button really is to work on your own. But that is the most, in my opinion, the most rewarding.

Adam Stacoviak: You were talking about Tigris, and correcting yourself… Tigris is basically like the promise of object storage, but it allows you to actually build a CDN. Like, you can basically run a – you can write some JavaScript, use Tigris, and you have a CDN baked into your application. You couldn’t build anything like that before. You could try and do this with S3, but it’s so complicated to like manage multiple regions of data that it’s impossible. Supabase for Postgres is like this. Supabase is a Postgres that lets you build new kinds of apps, or build apps faster. It really gives developers power.

And so the Rebel Alliance idea was if the future is developers are picking cloud platforms, the best possible cloud platform for developers is 10 companies that have built a very special version of infrastructure, that makes developers more powerful by itself… And then obviously, developers would just use those 10 to 50 things together. Like, why would they use my object storage when they could use Tigris? Why would they use my Postgres when they could use Supabase? Why would they use my GPUs when they could use Replicate, for example? And I think it’s like – I don’t know, it’s one of those things that I could still rationalize it. It seems like a thing I’d really enjoy, but there’s actually huge structural problems with it, which is what people tend to want when they launch an app, is actually a really consistent UX, that solves a higher order problem than they can solve by themselves. So a PaaS like Heroku – Postgres isn’t a product. It’s actually part of the product. It’s a feature of the PaaS. And so you can do cool things like do PR reviews with your existing Postgres data, for example. And so there’s a UX issue here, where you can’t actually solve problems as well with 10 to 50 different companies as you could if you were just doing it all yourself. And there’s weird compliance issues…

One of the things about getting a HIPAA BAA, so you can do a healthcare app, is you actually end up having to sign with each of those 10 companies. You can’t just do one HIPAA BAA with us… Which I think is a real burden for developers. I don’t think they wanna do – even if you can unify [unintelligible 00:26:52.14] I don’t think they wanna do multiple contracts with companies, you know? It just creates more and more friction.

So there are actual practical issues with like a Rebel Alliance cloud. But also, I think that a lot of it is just politics. There’s just very few companies who have a low enough ego to give up a big chunk of potential revenue like that. Us saying “We’re not gonna take the Postgres revenue” is pretty big, because EC2 – I mean, most of AWS’es profits come from RDS. That’s like a huge market, that we just said “Hey, we’re not gonna have this. You can have this.” And that’s not a thing most companies would be saying. In some ways, we needed a company to come back and be like “Fine, then we’re gonna give up the compute revenue”, you know? And that was actually relatively rare, to find people who were that… Communist? I don’t know. [laughs]

Nick Nisi: I’m curious - you mentioned the contracts that it helps you to keep and create with your team. Was that the main thing that made it click? Or was there some specific thing that was like “Oh, okay, I do get this now.”

Marc Boorshtein: We haven’t really been impacted by any of the Azure-specific security… Like, the Cosmo one didn’t impact us. The log4j was a big one for us, because we’re Java-based… That was a weird day, because I’ve got other contracts inside the county that use us… And I got up and I started looking at Twitter, and I was like “Oh, log4j. Oh, great. Well, let’s see what’s going on…” I’m like “Oh, holy *bleep*. Wife, please go drop the kids off. I’m not going to be – I’ve gotta focus on this now.” So that was a day. But Azure’s issues from a security standpoint - we’ve mostly been insulated, just because we haven’t used the services that have gotten beaten up that badly…

Jerod Santo: That’s true. So don’t listen to anything I say. I’m coming from the indie side. Go ahead, tell us - you need contracts, you need to have an agreement on what it’s going to say… And I’m assuming – and you don’t want to have to just invent that every time.

Avindra Fernando: Well, I was telling Jerod earlier that I do have a capacity. I’m always constantly looking to keep a couple of clients at the same time. So I can agree to some more contracts, and get those hours in.

Tom Occhino: Absolutely. I do not think that this should be a trade-off at all. And I’ll give one example of the opposite case than what you described. In order to enable a truly exceptional user experience, the developer experience was so bad that nobody wanted to contribute to the thing, and so it eventually just died. Facebook built an app called Paper for iOS, and it was around the time that the iPhone 4S was released. It was such an incredible app, ahead of its time. Every gesture was smooth, everything was 60 frames per second animation. It was built on a technology called Async Display Kit, but it was so manual. Everything was very hard to work with as a developer, and it was very easy to get things wrong. One sort of line out of place and you were segfaulting the app and hard-crashing, because it was doing direct memory access, direct access to underlying canvas painted views.

And so unequivocally, you could use this app and you’d be like “This is the best feeling app I’ve ever used. It’s an amazing user experience.” But because the developer experience was so – it was full of what we call footguns, or it didn’t enable developers to fall into the pit of success, developers didn’t want to work on it. And so that great user experience - there were two or three people who had it in their head, that could make changes, but ultimately the app kind of just didn’t scale, and we kind of shut it down eventually. We took some of the lessons and some of the tech and incorporated it into the main Facebook app, but Paper didn’t live on.

And then on the other hand I think every day we’re confronted with software that we use, that is clearly optimized for sort of time to market, and nobody really put any care or craft into it, and it’s just like “Look, I can tell you just kind of like put this out there, and it solves a purpose, it solves a need, but it’s not where I want to spend a bunch of my time. It’s not a delightful, exceptional user experience.”
[00:32:07.10] So my strong belief - and actually I think at one of the React Conf keynotes I gave a whole spiel about this… The only reason to invest in a great developer experience is in service of creating an exceptional user experience, and then being able to evolve your app and keep it relevant over time, while preserving and maintaining and enhancing the user experience.

I think that these two things go hand in hand, and you should be focused on - as a framework author, as a platform author, you should be focused on great developer APIs that by default create great user experiences. We’ve seen quite a bit of this in Swift and Swift UI. I think Apple’s doing a pretty good job here of making it so that “Hey, if you just write your code this way, look at the great user experience you get.” And you’re like “Oh my gosh, this code is easier to write.” And that’s what I love about React as well. Because we have this component as the isolation boundary, component as the sort of logical “This is my container”, I can optimize the insides of that component and the user experience associated with that component, and maintain the same contract with the rest of the application, and then somebody else can work on this piece and that piece. And even though we’re working on different parts, because we’ve maintained these contracts, we can have a really good-feeling application. I can continue to refine my one component and make it better and better and better, without degrading any of the rest of the app. So yeah, I think they go hand in hand.

Max Howell: Well, you’re totally right that a lot of developers are very anti-crypto, and so it’s been a battle from the start. Hacker News hate me even more than usual. But inside the cryptosphere, it’s very popular. Like, 1.7 million signups is pretty unheard of. And what it turns out to be the case, to my surprise… I’ve spoken to over 300 open source devs over the last three years, just for market research reasons. A lot of them don’t care if it’s crypto or not. They like crypto in the respect that they like technology. Open source devs aren’t as anti-crypto as the others, the rest of the devs. And yeah, I think we have a reasonable chance of showing that crypto is just a technology. We’re not a scam. There’s nothing scammy about what’s going on with us at all. They’ll see that once we’ve gone live and no one’s rugging the token, or anything like that. And it’s all open. That’s one of the beautiful things about Web3. All those smart contracts are transparent, readable. You can see what’s going on.

Jerod Santo: Fascinating, fascinating. There are, definitely – so I’ve been around the entire time as well, and there are people and projects that came after Rails that list specific things that Rails does in their inspirations. I think convention over configuration, for instance, has not just stood the test of time inside of Rails, but has actually permeated other projects. And then, of course, there’s always those that rail against - pun not intended there - whatever is currently the status quo, because that’s how they get the likes, the contracts… I mean, what’s new is what sells. And so we’re very much highly motivated to do that.

Adam Azzam: If I return back to – I gave like five or six theses of things where I was encountering failure a lot… And I think that some of those things are sources of failure that many folks are familiar with. I’m calling out to an external service, and the service is flaky, and it’s bad… That’s existed forever. As long as people are building data pipelines, upstream sources being flaky - that makes sense. Hitting deterministic errors of like - I’m ingesting data, but somebody added a new field, or they removed a field, and I’m dependent on that, and now my pipelines broken. Or I’m scraping something, and target.com, instead of labeling the name of their product with a div whose name or ID is this, they’ve changed it to that, and now all of my data is corrupted, because I couldn’t detect that in real time.

[00:16:12.02] And then the last piece is the loading part, where you’ve gotten, you’ve cleaned all your data, and now you want to go put it in a persistent place where you can go query, or do analytics on. So that’s like classical stuff. The extraction, calling out to an external service, the transformation that you’re doing deterministically in the loading. So the sort of ETL business of all of that. That’s like a persistent problem that exists far before Gen AI, or ML workflows… And that’s sort of what’s been category-defining for workflow orchestration. That’s like the single case that people usually break in an orchestrator for is when they’re doing ETL type jobs.

I would say that what’s unique these days is that since workflows in LLM land are now more dynamic, so you really can’t plot out every single thing that’s going to happen from the start, they are now basically – we’re dealing in English now, or you may not know the full space of their responses at the beginning of a workflow. So I think that LLMs introduce a dynamism component that’s hard to reason about, and has kind of escaped classical workflow orchestration.

I think the second piece is that the nature of errors here just feel totally new. So the fact that you can ask an LLM for a particular shape of a response, and then you can get parsing errors out on the end of it - that’s a new source of failure that’s now buttoned up with, say, some commercial LLM providers that give you very structured, guaranteed output, so you don’t see as much parsing errors… But now – I like to joke that you can lead an LLM to JSON, but you cannot make it think, where - like, you can say “Look, I’ve got this job description, and the title is… I’m going to give you a schema that says the job title, the location”, or whatever. And sometimes you’ll say the title, it’s required, it has to be a string, and the response you get out is “I’m sorry, but I could not find a title.” And when you’re doing this at tens of thousands of jobs, now you also have to reason about “Okay, I got now the parsing error, but the error was pushed down deeper in the stack.” Now there’s data quality errors that I have to reason about, that I didn’t really have to account for in last generation’s ETL. Things were much more deterministic, we had stronger contracts about what you’re going to get.

And then I would say the last piece is – what makes this harder is that so far… And I hate to keep throwing out random definitions. I hate being a merchant of complexity, and talking about why things are super-hard… But trying to at least motivate why this is a new source of difficulty, right? Like, we’ve got tools to handle this, but why do we have these tools in the first place? And the last piece is around like agentic workflows. Now, this is a buzz term… So what do I mean when I say “agentic workflows”? Everything that I’ve talked about so far, of like I get a document, and I want to extract stuff from it. Or maybe I want to classify it, or I want to summarize it. These are all sort of modern takes on classical ML problems, right? You don’t have to bring as much training data, you don’t have to train a model first… You’re basically throwing the weight of the compressed internet at every problem that you come across.

But with agentic workflows, what I mean by that - those are things that operate in a loop, are able to call out to external tools should it choose to, and can create, refine and reflect on its own plan, which means when you’re orchestrating agentic workflows, you have to do this interplay between who’s doing the orchestration… There are some times where I’m coming correct with a plan, and I’m saying “First extract this topic, then classify it, then write an email and send it off”, but now I have to be able to add resiliency to a workflow that I’m unaware of at the beginning of it. So if it decides “Call out to this tool, call out to this API”, I now need to be able to reason about resiliency for a workflow that I don’t have any visibility to at the beginning.

And so I would say that those last three pieces around parsing, around not knowing your your full decision space at the beginning, and then how that feeds into now having to hand off some bits of orchestration to the LLM to create its own tasks that you now have to execute, I think that’s what makes the new generation of orchestration a much harder and a much more interesting problem.

Break: [00:20:44.08]

Ryan Dahl: I’ve definitely thought about it, because I – I mean, I’m like a nerdy engineer. I’m not necessarily the best salesperson… And doing the CEO job, I think you have to be kind of a salesperson. You have to have to go out and close contracts, and that sort of thing. But the focus in my life isn’t to be like the best programmer in the world. Like, I’m just trying to build cool stuff, and I think it’s interesting to learn new skills. Like, doing Deno as a company has been pretty eye-opening, because before that in my career I was an engineer only; and learning how to raise money, how to manage people, how to do sales, how to do product… All of this stuff has its own interesting bits. And I think it’s about solving the problem at the end of the day, and you do what it takes to solve the problem.

Ryan Dahl: I’ve definitely thought about it, because I – I mean, I’m like a nerdy engineer. I’m not necessarily the best salesperson… And doing the CEO job, I think you have to be kind of a salesperson. You have to have to go out and close contracts, and that sort of thing. But the focus in my life isn’t to be like the best programmer in the world. Like, I’m just trying to build cool stuff, and I think it’s interesting to learn new skills. Like, doing Deno as a company has been pretty eye-opening, because before that in my career I was an engineer only; and learning how to raise money, how to manage people, how to do sales, how to do product… All of this stuff has its own interesting bits. And I think it’s about solving the problem at the end of the day, and you do what it takes to solve the problem.

Kevin Ball: [00:05:39.12] You can get some amount of that if you do a consulting contractor type of thing, if you work at it… Like, I knew a guy, also based in Southern California, actually, who over a period of years set up a set of freelance contracts with people where they – it was with companies that wanted his skill set, but were okay working asynchronously, had a bunch of work that they were willing to pay to get done, but didn’t have strong deadlines on… And to do that, he made other trade-offs. He was sometimes working at a lower rate than somebody in the most on-demand thing, or he was working with older technologies, or whatever. There were trade-offs involved. But he did this, and he cultivated this set of clients, and then he told me “Okay, I’ve spent five years setting up my life, so now I can choose every hour, any day, any time zone. Do I want to work today, or do I want to work this hour or not?” And he took off around the world, and just was doing that from everywhere. So it is possible even in a work environment, if you craft it enough, but it’s hard.

Justin Garrison: Yeah. And then a lot of stuff changed in the early twenties; this golden era of movies shifted when basically the government broke up the movie theater and said “You cannot own the full stack. You can’t own the movie theater, the studio that creates the content, and the people that are working for you, because you can treat all of them poorly.” And so they had to break it up and say “You get a movie theater over here.” That’s an external company. And now they’re actors and actresses, they broke contracts and they didn’t have to work for a studio, and they could go around. But then they still needed some collective way to say “Hey, don’t treat me like crap.”

Kris Brandow: Yeah, I mean, I think that that’s perfectly fine, of saying “The specification as date x.” You can get snapshots of the HTML specification, for instance, that are tied to a specific date. So you can go implement something in your browser and you’re like “Well, this was what it was at this specific date.” But also, it really depends on the type of contract that you’re doing. HTML works in the way it does because of, you know, you have these browser vendors, and there’s kind of like nobody here that can be like “No, you must do it this way.” So it’s all a shared agreement. Which is not dissimilar from how APIs you consume from third parties work. It’s just different, because there’s only one implementation instead of multiple implementations. So now you have to extract that same sort of promise in a slightly different way, but I don’t necessarily think we need the version numbers to give us that. Or even even dates, really. It doesn’t matter.

[00:48:16.12] At the end of the day, what you want is sign something that says, or have an agreement that says “This is what I expect from you. And if you want to change it, then we need to have a conversation”, or someone needs to have a conversation. Or in the case of a consultant or a contractor to a company, if the contract changes on their end, you can bring me back, but you can’t come after me and say I didn’t do the right thing. I did the right thing as of this. So if you want to judge my work, you’ve got to judge it based on this specific thing. Which once again, whatever pointer you use to reference that thing, whether it’s a version number or a date or hash or what have you, as long as the thing itself is stable and stuck in time, that’s what you care about. That’s the agreement you want to be focused on.

And I think at the end of the day, version numbers, like… I don’t know, even with all these version-numbered APIs, can you actually – with Open API you can. But with other things, can you go download the actual contract that’s being agreed to? If they go back and they change all of their documentation and just completely [unintelligible 00:49:14.28] an entire API endpoint, how are you going to be like “No, it said this before.” I mean, I guess you could go use the Wayback machine if they’re big enough, but that just seems like a very precarious situation to put yourself in, instead of having the “No, here’s a contract that I had of some sort.”

And I think things like Open API can be those contracts. I think that’s why we have these at the end of the day, is because they function in that way. I think we just kind of muck them up a bit with version numbers.