Max Howell: Yeah, so we’ve built it… We’ve been running the testnet since February, and we got 1.7 million people who’ve signed up to use this testnet… Which are pretty great numbers by any standards, but especially in the Web3 space, you don’t get that kind of users. I think it’s a testament to people understanding that what we’re doing is important, but also that we’ve cracked it, that we understand how to take the value of open source and actually expose it.

So until now, we all understand the value of open source. Everyone builds everything on top of it. But very little of that value ends up going back to the people who maintain it. That’s my story. Homebrew was a passion project that became my full-time job for free. And I had to keep taking new jobs, quitting them after I’d saved up some money working on it… And that’s why I founded Tea Protocol. I was once again in that position, wanting to work on open source full-time.

So our system - yeah, it changes the economics of open source. That was one of my conclusions before founding Tea Protocol, is that the system of economics that we use in this world - it doesn’t fit cleanly onto how open source works.

Open source is really weird. There’s no real thing that’s like it elsewhere in the world, so it was necessary to build something new, that used economics in a new fashion. So that’s what we’ve built.

[00:52:07.04] We have an on-chain oracle called Chai, that computes the impact of all the open source projects, all 10.5 million of them, using package manager data and dependency data to calculate that. The higher your impact, the higher your rewards. Every 24 hours we just give you free Tea token. And then we have – with the 1.7 million people who signed up, only a third of them are developers. Two-thirds of them are people that maybe didn’t even know about open source before. Once they heard the story of how everything they’ve used on the internet for the last 30 years is built on top of this open source, they understood that there’s a huge amount of untapped value there, that they want to participate in. So they’re the input for the monetary parts that allow the open source to be remunerated.

And I’ve had loads of tokenomics experts looking at it over the last three years… You have to calculate the sell and the buy pressure correctly in order to make it so the token price stabilizes at something, which then makes it so the open source maintainers can sell their token, and use it to fund the development.

Austin Parker: Yeah. The economics of children’s YouTubes… I don’t to think about it, because…

Zac Smith: Yeah, I mean, I love the rack scale concept there. Super-timely and applicable. And he and his team have done just such a great job at building open… Like, literally building a whole new computer, versus just skipping a whole bunch of the hard stuff around firmware, and bootloaders, and related… Which is awesome, and I presume makes them super-confident and running awesome computers for people. And I know that they’ve been able to offer a really high-quality experience with these Oxide racks because of that.

But I think there’s also this opportunity for them to maybe think – and I don’t know, because I’ve not bought an Oxide rack, but I’d love to. I’d love to have a reason to. Which is to change the economic model too, and allow people to subscribe to them, which I think would be super-cool, and really give them that competitive edge. I’m sure they’re thinking about it because Brian’s super-smart, and thinks ahead about 15 steps… So make the computer, make the rack better, and then now that you have disruptively scalable and efficient economics making computers, figure out how to run them better for people.

Jerod Santo: There’s an analogue to this in economics. Benedict Evans talks about the process of bundling and unbundling, and he says in any given industry you’re either in a bundling process or an unbundling process… And it’s cyclical, right? So an example of that is television, where we’re all cable TV, everything was bundled as one, and then we broke out of that individual, on-demand, subscribe to this, that and the other thing, and how we’re like in a rebundling that’s happening; you can see it with YouTube TV, and different aggregators trying to pool together content. And that sounds very inefficient… Your heptagon sounds inefficient, because it’s like, “Well, we’re going around in this circle.”

But what I’ve heard pointed out is that progress often looks like a circle when you look at it on its head, like in a two-dimensional plane… But then when you look at it in three-dimensional, it’s more like a helix, where it is moving in a circular way, but it’s getting better as it goes… And I think with software, that’s a lot of what we’re seeing - these iterations, and a lot of times returning to the old idea, but you’re returning to it with new eyes. You’re returning with new tools. And so you are building up, but you’re not like building blocks on top of each other; you’re kind of like circling the wagon, but you’re going up… You know, it’s like a helix rising… Which is slower than we would want it to, but it’s still progress, right?

Jerod Santo: Yeah. Well, this doesn’t exactly match up, but it at least rhymes with what happened on the HashiCorp and Terraform side of open source, where that was around a relicense rug pull. This is a different kind of thing, different kind of – it’s like a certainty pull; he pulled the certainty out, not necessarily the rug. Although the rug was definitely pulled out on those WP Engine customers. But over there, when HashiCorp, pressured by economics and their need to make more money, relicensed Terraform. And what we saw there was Open Tofu, which was a community fork created by the other big players in that place. There’s lots of companies building businesses on top of Terraform… And the verdict’s still out whether or not Open Tofu will become a replacement of Terraform, if HashiCorp will survive… But it’s caused a rift, it’s caused a fork, and a pretty well-executed fork. That’s the key of the fork, is you’ve got to get a lot of people behind it, you have to dedicate resources… You can’t just hit the fork button on GitHub and think that you actually have something going. It ain’t easy.

Kevin Ball: [01:02:57.03] Yeah. It’s actually – I think, to step back on this for a second, all of the capabilities exist in the world. Building this is not a massively hard problem. The question is, what’s going to fund it to be created? That might be a hobby project, but then even more importantly, maintain it over time. I think 80% of software expenses is maintenance. So how does this thing stay maintained over time? What’s paying for that to happen? I’m not sure the economics are there for it, unless you can get somebody who’s really excited about it. I mean, maybe the JSParty audience wants this to exist, and they’ll all throw in 50 bucks.

Erez Zukerman: No, not a huge concern. As a business, actually, our costs are super-high. Our economics are weird. Much more of the total cost of the keyboard that you pay goes into actually making the thing… And I’m fine with that, I’m okay, because again, we make them – we make the keyboards in Taiwan, and they’re made by people who are employees; not our employees, but Tibbo’s employees. And they’re paid well, and… The whole thing is just expensive to make. When you do something right, it tends to be expensive. And if I really believed that wireless was the way to go, value-wise, I would go for it. Even if it made the keyboard more expensive, that’s fine. That’s not – I don’t compete on price.

Mat Ryer: I like the “Why don’t we see dead people?” But the obvious answer is they’re terrible on dates. But I think I’m going for print more money. I think most people would just be like… If you understand economics and the tools that they have at that level, you do talk about printing money… But also, if you’re an absolute idiot - and I’m not saying you’ve got a lot of idiots in Nebraska. I don’t know. But imagine there’s an idiot walking down the street, who just thinks money’s just printed, and they’ve got like a printer… Why don’t they just do more of it, and then everyone’s got more money?

Adam Stacoviak: [01:00:09.18] What about greenfield? Is there anybody that’s like “Okay, we need to adopt Kafka or something like it, but what is out there, before we go and write a line of code, or flesh out our infrastructure model, or make any plans?” What about those that are not migrating? What’s the path, I suppose? What’s the inbound of those folks, and what’s the path to the DX? Because one of the things you mentioned is that you solve a few problems. You solve cloud economics, you solve operational overhead, and one thing that you mentioned, at least the article that was from last year, was a major problem with Kafka, which was developer user experience. And that’s what I’m trying to get to there, is like, those who are coming on green, brand new, what does that user experience like, and what’s the path like for them?

Carlana Johnson: Yeah, go big or go home. Nowadays, in 2024, you can get 10 pounds of dog food shipped to you, and it’s not a big deal. But that’s because now Amazon has a warehouse on every street corner, and so the economics are different. Versus like “We’re gonna start with 10 pounds of dogfood.”

Philipp Burckhardt: [00:11:56.12] You could think suddenly it can power a web server, but it can also be in a terminal, if you need to do something; you can just use it. And so that’s kind of in the background there… And after my bachelor’s I didn’t really know what to do. I did a bachelor’s in economics, I didn’t really like it, and so I pivoted, so to speak, to statistics, and I did a lot of [unintelligible 00:12:16.28] programming. That’s kind of the preferred language for like statisticians. And it has some nice benefits, but also some downsides, as all things do. But I ended my master’s, and while doing that, we were working on a project to kind of model the political – the sentiment around different political topics on the platform, I guess now X, formerly Twitter. We did a scraper to scrape newspaper articles from all kinds of sources. And then we extracted that information, and I used MongoDB as a document store. And that has a JavaScript REPL environment, which you can interact with it…

So that was what I was doing, was trying to kind of do topic modeling, which is kind of probabilistically modeling these topics, and we added a time dimension such that you can see how do they emerge over time, and then maybe also collapse again if they – if the new cycle is very short-lived, where there’s a few topics that blow up, and then they suddenly disappear again.

And what I was doing though – so I needed to do some calculations. And I was already using Mongo, and I had to use JavaScript kind of to interact with the Mongo app, and I also had to do the scraping. And for the scraping – at the time; now it has like [unintelligible 00:13:38.21] that whole ecosystem wasn’t really there at the time. It was very in the early stages as well. So now it’s very grown, and there’s a lot there, but at the time it was just like working a DOM tree, and extracting content from a website, you couldn’t do in R. So again, I used I think jsdom [unintelligible 00:14:01.12] And in my job now at Socket [unintelligible 00:14:06.23] is my coworker, so it’s kind of interesting… The world is small and you always end up crossing paths again.

Nestor Maslej: [00:42:50.12] Yeah, I’d probably say three big things. I think the first one is scaling [unintelligible 00:42:51.23] So we talked about this already, but I think a lot of these companies are making these bets that they’ll feed more data into the systems, they’re gonna get a lot better… And I don’t dispute that they’re not going to improve; I think that the improvements are going to continue. I do wonder by how much, and if in fact the improvements aren’t as great as we anticipate them to be, what might that mean for the economics of AI?

I think number two, looking at how are businesses actually integrating this technology. If you look at literature on a lot of other technological transformations, a lot of economists argue that it typically takes decades from the launch of a technology to the point at which it actually registers positive productivity impacts, largely because very often you don’t have infrastructure that’s necessary to leverage a technology when it kind of appears out of the box. And I could imagine a similar thing with AI. Now, I don’t think it’s going to take decades for AI to kind of have its productivity impact being widely felt, but it will be curious to me to see if businesses start thinking a little bit more critically about how they want to use this tool and how they want to integrate this tool.

And I think third, kind of keeping an eye on what happens in the domain of policy - you talked about what is something that I’m kind of encouraged by or kind of watching out for… I think it’s - yeah, what is the policymaking response going to be? And I’m encouraged, because I know that I think looking back at the example of social media, I think it took us close to a decade from when these tools were launched, to when we started really kind of thinking about them on a political level in terms of kind of regulating them, and ensuring that we built them with the right kind of incentives and in the right kinds of ways. And if you kind of point to 2022 as this moment where AI was kind of officially launched - I mean, we had pretty landmark legislation in 2023 with the EU AI act, as well as Biden’s executive order… So it’s encouraging to me that policymakers are thinking about these things. I guess an open question for me is going to be “Where does the tone of policymaking go, and what comparative priorities do policymakers in different parts of the worlds have when it comes to launching these AI tools and models?”

Don Beyer: Chris, I should have been more afraid than I was. [laughter] I had originally graduated in 1972, a degree in economics. And I worked for a year or so, and then I decided that – I didn’t know what I wanted to do, I was wandering around… So I thought “Well, I’ll go to med school”, but I didn’t have any of the prereqs. So I went back and did the whole pre-med thing in about 12 months. And at the time, I had figured out that it was just sailing; I was competing against 18, 19, 20-year olds, and I was 23, and I’d worked for a year, I was married… And I crushed. I just felt like I dominated. So I thought maybe I would again; that all these kids were – they’re too busy trying to figure out who their next romantic liaison might be, and how much they could drink tonight… And boy, was I wrong. The kids that I was in school with are so serious, and they have these great technical backgrounds from high school, and they were the ones crushing me. So it was really a great exercise in humility for me.

And I honestly say, I did well in college, and taken courses here and there over the years… I’ve never worked harder in a course than I did on this last Java course. I typed 193 pages of notes.

Bryan Cantrill: They’re making more. And if you’re going to run compute for years, at scale, you should own it. And I think that you’re going to have – I believe that in this arbitrary future, the choice between on prem and cloud computing should not be the choice between modernity and antiquity the way it is today. It should not be the choice between a product and a DIY mess the way it is today. It should not be the choice between “I’ve got actually a vendor who is very responsive to me”, be it at Amazon, or GCP, or whomever, versus this finger pointing exercise I have between… It’s like, that should not be the choice. The choice should be purely around economics, around risk management, around latency… And I think that for a bunch of people, they will remain on prem, they will choose to be on prem… And then I think you’re also going to have people who are going to always have to be on prem, and I think in many ways the thing that is most satisfying in Oxide is bringing those folks modernity. Because they’ve got no choice. They’ve gotta be on prem.

[01:54:13.28] I’m a naval vessel at sea, right? It has to be on prem, sorry. We’re not using the public cloud on an aircraft carrier. And it’s like, “But what is that using for its infrastructure? And shouldn’t that infrastructure also be elastic infrastructure?” And I think that that’s where you’re allowing people to do things that they fundamentally couldn’t do before.

So in terms of how it settles out, I think it’ll be interesting. I think it’s hard to imagine that public cloud will be any less than a third of compute, maybe even two thirds of compute, kind of somewhere in there… It’s hard to imagine that on prem is going to be less than a third of all compute. So I think it’s going to be kind of a third – I would say a third, very strict on prem, a third probably very strict public cloud, because it just makes sense… And then you’ve got a third that will be kind of swinging a little bit in the middle. But in a world where people are not having to choose between modernity and antiquity; they’re able to get that modernity wherever they are.

Yoav Shoham: But maybe some of it is common to others. So first of all, the baseline is a general-purpose, very capable model. There’s a need for that. Now, there are companies who provide services using other people’s models, and that’s totally legit. If you actually own the model, you can do things that you wouldn’t be able to otherwise. And our emphasis, in addition to the general capability of the model, is in order to make it practical, there are two things, especially in the enterprise.

[00:10:07.00] So if you’re using a chatbot to write a homework assignment, the stakes are low. A mistake doesn’t carry a big penalty, and probably nobody would read it anyway. But if you’re writing a memo to your boss, or to your prized client, and if you’re brilliant 95% of the time, and garbage 5% of the time, you’re dead in the water. And so reliability is key, and as we know, large language models are these amazing, creative, knowledgeable assistants, but probabilistic. And so you will get – here’s another term I don’t like… Hallucination. But you’ll get stuff that either isn’t grounded in fact, doesn’t make logical sense, and so on. And so you can’t do that. So you need to get high reliability. That’s number one. I’ll tell you in a moment how we do that.

But the other thing, it needs to be efficient. For every customer query, you’re going to pay $10 to answer it, and it’ll take you 20 seconds to answer it. That’s no good either. So you need to address that also. So we have several things we’re doing in this regard. The first is what we call task-specific models. In addition to our general-purpose model, like Jamba, that came out, we provide language models that are tailored to specific use cases. You can think about it as a matrix. You have industries, and you have use cases, and it turns out that while initially you might think that “Oh, I’m going to do a healthcare LLM, or finance”, that’s a little bit boiling the ocean. You want to be more specific, and one way to be specific is to think about what you’re going to use it for; these are the columns.

So for example, take summarization. That’s a specific task, and I can optimize your system… And I am deliberately saying “system” and not “language model.” I’ll tell you in a moment why. But you can optimize that for that use case. So all companies now are experimenting with multiple solutions, as they should. And in this particular use case, a very large financial institution took several of their financial documents, several hundred, and tested various solutions; our task-specific model, in summarization, and some of the general-purpose models of other companies. And ours were just hands-down better in terms of the quality of the answers they got. There was no hallucination, if you pardon the expression; very on point, very grounded, and so on, because it was optimized for the task. But by the way, the system is a fraction of the size of a general-purpose model, so you get the answers immediately, and the cost of serving is low. And this enables use cases that those latency-immune economics enable use cases that would just be unrealistic otherwise. So our task-specific models are one approach. And maybe I won’t overload my answer with saying why it’s not only models, but we’ll get to AI systems.

The other is - and it’s related - having models that are highly efficient. That goes to Jamba, as an example of a model that’s very capable, but not big. If I were to jump ahead, and let’s think about 2024… What are we going to see in this space? Among other things, you will see focus on total cost of ownership of the reality of serving these models; you’re going to see a focus on reliability, and you’re also going to see a focus on - another term I hate - agents, but AI systems that are more elaborate than this transactional interactions with [unintelligible 00:13:47.29] about tokens in, a few seconds, token back, thank you, onto the next one. More elaborate. So this is, I think, what’s going to happen technologically in the industry. You’re also going to see correlated with that the industry move from what today is a mass experimentation to actual deployments. We’re seeing signs of it now, and I think in ‘24 you’ll see this sort of phase shift there also.

Break: [00:14:16.02]

Kevin Ball: Yeah. So this is a technology that has the potential to dramatically impact the productivity of software engineers. And I think there’s a couple of different things around that, as we think – so short-term, that can create some disruption. Short-term, that means that a company that had been running on, say, five engineers, and might have needed to hire and expand to 15, now they don’t have to expand nearly as soon, and things like that.

So I think there is the potential for relatively short-term disruption. I will say, both – the history of economics broadly and software in particular is that every time we make it easier to code, we discover there a whole world now that we can address and build software around, that we couldn’t before. So if, for example – and this, actually… There’s a particular example of this that I think is interesting to dive into. So one of the big economic challenges in the tech industry in the last four or five years is that we had these massive tech companies, with incredibly high revenue per employee: Google Meta, Netflix… The FAANGs, mostly. And so they were able to set the salary bar that was super-high; they were paying ridiculous amounts of money - that’s a technical term, ridiculous - for software engineers.

[00:18:09.26] And then when we had very low interest rates, and a ton of VC money flowing into the industry, there were lots of companies whose fundamental business economics do not support that level of salary per software engineer, who were nevertheless paying that amount of salary per software engineer based on VC capital. And sort of this thesis that “Okay, we’ll be able to scale out of this, and we’ll get whatever.” And I think that caused a lot of distortions and problems in the field.

Now, if suddenly software engineers are three to five times more productive, the range of businesses that could use software, but previously could not afford to compete with the FAANGs etc. of the world - there’s a whole set of business models in there that become viable, because it’s that much cheaper to develop software. And so I can imagine this actually dramatically expanding the number of viable, either software businesses, or businesses that are non-tech, but would like to include software, or could have custom software, and dramatically expanding the number of those that haven’t.

So long-term I don’t think it’s a negative impact on the software engineering career path. I think that what it means to be a software engineer looks a little bit different when you have different types of tooling. That has been true as long as I’ve been around. JavaScript land - I remember when jQuery was a revelation. Oh, my gosh, this is gonna make me much more productive. It did make me so much more productive, all these other different things. And now the level of tooling that we have there that supports our productivity building things on the frontend is astronomical. And has that taken away from the number of people running JavaScript?

Kevin Ball: Yeah. So this is a technology that has the potential to dramatically impact the productivity of software engineers. And I think there’s a couple of different things around that, as we think – so short-term, that can create some disruption. Short-term, that means that a company that had been running on, say, five engineers, and might have needed to hire and expand to 15, now they don’t have to expand nearly as soon, and things like that.

[18:00] So I think there is the potential for relatively short-term disruption. I will say, both – the history of economics broadly and software in particular is that every time we make it easier to code, we discover there a whole world now that we can address and build software around, that we couldn’t before. So if, for example – and this, actually… There’s a particular example of this that I think is interesting to dive into. So one of the big economic challenges in the tech industry in the last four or five years is that we had these massive tech companies, with incredibly high revenue per employee: Google Meta, Netflix… The FAANGs, mostly. And so they were able to set the salary bar that was super-high; they were paying ridiculous amounts of money - that’s a technical term, ridiculous - for software engineers.

And then when we had very low interest rates, and a ton of VC money flowing into the industry, there were lots of companies whose fundamental business economics do not support that level of salary per software engineer, who were nevertheless paying that amount of salary per software engineer based on VC capital. And sort of this thesis that “Okay, we’ll be able to scale out of this, and we’ll get whatever.” And I think that caused a lot of distortions and problems in the field.

Now, if suddenly software engineers are three to five times more productive, the range of businesses that could use software, but previously could not afford to compete with the FAANGs etc. of the world - there’s a whole set of business models in there that become viable, because it’s that much cheaper to develop software. And so I can imagine this actually dramatically expanding the number of viable, either software businesses, or businesses that are non-tech, but would like to include software, or could have custom software, and dramatically expanding the number of those that haven’t.

So long-term I don’t think it’s a negative impact on the software engineering career path. I think that what it means to be a software engineer looks a little bit different when you have different types of tooling. That has been true as long as I’ve been around. JavaScript land - I remember when jQuery was a revelation. Oh, my gosh, this is gonna make me much more productive. It did make me so much more productive, all these other different things. And now the level of tooling that we have there that supports our productivity building things on the frontend is astronomical. And has that taken away from the number of people running JavaScript?