Greg Allen: Sure. I would start by saying that two countries are specifically named by the National Defense Strategy, which came out in 2018. Two countries are specifically named as strategic competitors. And that is Russia and China. These are countries who have interests that are identified as being contrary and in contradiction to (in many cases) the interests of the United States, and also who have oriented their national security establishments in competition with the United States. And that’s not a very surprising statement, I would say, to most.

When the National Defense Strategy came out, it was sort of putting on paper the sorts of things that a lot of United States leaders had been saying, and frankly that a lot of leaders in the two countries I just mentioned were also saying. So that’s sort of the basic backdrop of strategic competition.

Into artificial intelligence - of course, this is the national security world we’re talking about, and the military we’re talking about, so we remain quite interested in what is going on around the world, and we would be silly not to be paying attention to that.

I think, speaking about China and Russia each in turn - China’s AI strategy, which came out in 2017, specifically identifies that they see AI as a transformative technology in many different areas, including in national security. It also identifies AI as a leapfrog technology. The term leapfrog is interesting in this use case, because it is describe elsewhere by Chinese military thinkers and strategists as really sort of describing their belief about what AI technology will enable their military, compared to the United States’ military.

If you can think about the example of cellular telecommunications infrastructure in developing countries, notably many developing countries in Africa - this is the canonical example of a leapfrog technology. There were many developing countries in Africa who did not have well built out landline telephone infrastructure, and yet this was no disadvantage whatsoever in adopting cellular telephone infrastructure. They just skipped the development step of landline telephones and went straight to cell phones. That skipping is referred to as leapfrogging.

In our competition with China in military technology, there are many things that we are quite good at, that they have a very hard time with in the technological sense; things like jet engines, things like aircraft carriers - these are really tough, really complicated technologies, that we as a country tend to be quite good at, and that China as a country has historically had a lot of difficulty with.

So when they write about AI technology, they’re saying “Well, if we could really develop an interesting advantage in AI, perhaps we could leapfrog the United States”, which is to say “Perhaps we would not have to catch up to them in aircraft carriers, or catch up to them in jet engines, because we will shift the basis of competition.” And Chinese military thinkers often write quite optimistically about China’s opportunity to compete with the United States technologically in these terms. So we would be remiss if we were not paying attention to that.

[23:52] The second thing I’ll say is that, as pointed out by the Secretary of Defense at the National Security Commission on AI, in his speech at that commission - there are many Chinese weapons manufacturers who are currently selling on international markets weapons systems advertised as being autonomous, meaning they can make their own decisions and act independently, and also having that full combat autonomy, meaning they can actually be responsible for the use of lethal force.

So that’s what China is sort of up to today, at least in terms of what they’re advertising on the international market.

Russia is similarly very interested in AI technology. One quote that everybody really paid attention to was in September of 2017 when Vladimir Putin said that whoever leads in AI technology will be the ruler of the world. And I think Russia does not have a very clear path to leading in AI technology, whereas the United States and China regularly top the lists of who is publishing the most AI research papers annually, and who is publishing the best AI research papers annually, and similarly lead in measurements about who is attracting the most venture capital for AI companies.

Russia is pretty low on all of the rankings that I just mentioned, so I don’t think that Russia has a clear path to leading in AI technology. Unfortunately, they do have a reasonably clear path to leading in the weaponization of AI technology. I think this is a pretty similar story to the internet. Russia was not a leader in any of the foundational technologies for computer networking or the internet, and yet nevertheless Russia developed a very advanced and broad and deep military cyber capability. So similarly, I think Russia is looking to be a leader in the weaponization of AI, just as they were a leader in the weaponization of the internet.

In terms of what they’re doing, it’s a lot of what you would expect. The social media disinformation campaigns, and influence operations that Russia has been in the news a lot for lately - they are also interested in bringing in more advanced machine learning and AI capabilities to these operations.

And then secondarily, combat robotics is an area that Russia has devoted a lot of investment, and has shown a lot interest, and they’re experimenting with a lot of their military robotic systems operationally, literally using some of these systems in Syria. So both Russia and China are moving out aggressively to incorporate AI capabilities into their military.

I would say in terms of the United States’ response, our intent is to lead the world in the military use of AI for the benefit of United States’ national security. I don’t think we’re so much obsessing over each individual capability that comes out of China or Russia, so much as we are looking at the broader landscape. I think AI is a general-purpose technology, the way electricity is a general-purpose technology. It’s useful for things like radio, but it’s also useful for light bulbs. Similarly, computers are useful for just about everything, and we similarly think that AI ultimately has a lot of application-specific opportunities for us. So we’re interested in leading in AI, in the broad sense.

Kevin Ball: [20:18] I don’t know the answer. My understanding of the situation is it’s around IE. Another thing though, looking at the [unintelligible 00:20:31.12] something that we often neglect talking about things over in the U.S. is some of the international browsers. It looks like actually UC Browser, which is one of the pretty common ones overseas, does support proxies. The Baidu browser does not.

The reason I bring that up is Vue has a very large audience in China, and so their browser market is probably pretty different than ours, and I don’t know what the distribution is there, but I think it’s going to influence it. Something that’s gonna come up - we talked about reusable components - to the N-th degree when you start talking about frameworks is you have to be conscious of all those edge cases and users.

For example, when I was working on ZURB Foundation a lot, we turned down a lot of features or put them as sort of extensions to the framework because we had a large audience, a large set of users who were doing government work, and a lot of government work still has to support not only IE11, but often IE10, and IE9. So when you’re doing frameworks and tooling, you have to be a little bit more – well, I shouldn’t say “have to be.” If you want to be kind to your users and you want to have a large audience, often you need to make conservative technology support decisions.

Nick Nisi: I think when they’re that big, they have this much market share, and this much usage, it’s really hard for them to inject any further opinion, because they’re gonna alienate someone at some point. But that does leave a lot of room for smaller frameworks to come up and add opinion to that. Arguably, Astro does that a little bit, because it supports React. You can still write React, but do it in a more opinionated way, with this full ecosystem around it to support the needs that Astro is trying to solve, the problems that Astro is solving. And the same thing with other frameworks, and they can take ideas from that and kind of build on it… But the core ideas there are kind of solidified.

Nick O’Leary: Yeah. I don’t know what sparked it, but one of our most active communities is in Japan. They have a Node-RED user group, they have monthly well-attended meetups… I have been invited and dialed into a couple of their meetups, and sat through an hour of Node representations in Japanese… Not understanding a word, but seeing some really nice demonstrations and slides.

I don’t know what exactly sparked it, but yeah, there does seem to have been a really awesome community that sprung up in Japan, to the extent – I mean, clearly, Hitachi is based in Japan, and they have a large investment, but… The Node-RED user group spans multiple companies, and individuals and companies in Japan. People often ask me “Why haven’t you written a book about Node-RED?” and it’s on the to-do list… But I slightly tongue-in-cheek point them at the three Japanese books about Node-RED on Amazon. I have copies of two of them on the shelf behind me, and I just think it’s brilliant.

As Node-RED is an editor, it’s very user-centric, early in its life I was strongly encouraged to build in internationalization in the UI… And I sort of begrudgingly did it, because it was like three months of not adding any new features, of just building an infrastructure to support multiple languages, finding every message and putting it out into a catalog… It was a slog, but we did it. But by virtue of doing that, then along comes Hitachi, who now maintains the Japanese translations. We have Chinese translations, we have Korean translations, we’ve recently gained German translations…

Again, that has certainly helped the fact that, you know, here’s a tool that if it was English-only - sure, it would get adoption around everyone resigns themselves to having to use English around the world; but the fact that, particularly for the Japanese market, they are able to use it in Japanese, clearly that has helped there. And as ever, interesting challenges around an open source project and maintaining translations, because that is hard work, particularly when it is a language that you are neither a native speaker, nor – I can get by in a number of European languages, and I don’t mean conversant; I can look at the translation and with Google Translate figure it out… But Japanese, Chinese - I would not have the confidence at all to… You know, when we get a pull request fixing a spelling, it’s –

Kevin Ball: Yeah, I don’t use them. This kind of brings up an interesting point of what is the audience for which these things really make sense? Even looking at – as Safia pointed out, iOS is very much a Western phenomenon, you’re talking the U.S. and the Western Europe are the ones where iOS has gotten huge penetration… But even in that audience, the behavior of folks on iOS devices versus Android devices is very different. There’s documents, studies showing that folks would install way more applications on iOS, they’re more willing to pay for things - all these different pieces, so they may not be the market for PWAs.

If I think about the folks that I interact with on a regular basis, the young man who’s the most excited about PWAs lives in India, because you have this vast market of folks who are using slow connections, who are using either very low-end Android phones or feature phones that don’t have space… If you dig through, one of the big benefits of a PWA is it’s way smaller to install than a native application, but way less bandwidth-intensive than a web application. So you can target those folks who just don’t have the data and the bandwidth to play with.

Quinn Slack: You know, it’s unfolding – I won’t say exactly; we didn’t have a crystal ball back then. But it’s unfolding roughly as we expected. And we knew that to do more automation and code, to take away that grunt work from developers, so they could focus on actual problems and the stuff they love, that you needed to have the computer have a deep understanding of the codebase. It couldn’t just all be in devs’ heads. So it was no big surprise to our board or our team that this was something that we would do, that we would go and build our code AI. And it was also not some complete luck of the draw that we found ourselves in a really good position to go and build the most powerful and accurate code AI. So none of this is coincidental. But when do we do that? And I think if we had started to do that say in 2018, where there were plenty of other attempts to do ML on code, I think that we would have failed, because the fundamental underlying technology of LLMs was just not good enough back then.

[00:09:57.16] And the danger there is if we had started doing it in 2018 and we failed, we might have as an organization learned that stuff doesn’t work. And then we would have been behind the ball when it actually did start to work. So getting the timing right was the tough part. And I actually think that we probably waited too long, because we could have brought something to market even sooner. But it’s still so early in terms of adoption of code AI, and even less than 0.5% of GitHub users are using GitHub Copilot, so it’s still very early. Most devs are not using even the most basic code AI that exists. So it’s still very early.

But getting the timing right, and making a big shift, starting back last December… That was when we started to see Cody really start to do some interesting things. That felt early to a lot of people on the team. And it took a lot of work to get the team on board, and to champion what the team was doing that was working, and to shift some of the things that we could see were not going to be as important going forward.

David Heinemeier Hansson: It’s very easy to lose the connection of shipping that is so pertinent for survival in the early days of a business, where you simply – either you ship or you die. When you get to have a long-running, stable business, you can actually coast for a very long time. You can talk about things for a very long time, and it does not have immediate impacts on your ability to survive as a business. So I feel that it is our obligation. Jason and I in particular, as the founders of these businesses, to continue to keep the pace, to keep the expectations of the pace of what does a successful project look like. What is the, as we like to say, return on effort? Are we spending a lot of time talking about things, worrying about things, or building vastly over-built pieces of software? I think in many ways that’s as much of a dangerous under-building software, or making software that is full of bugs, is to overbuild it. Gold-platin it, as it is also called, where you end up with a system that just overshoots. The customers don’t care about all the bells and whistles that you’ve added to it, but you feel like “Well, we’ve done a good job.”

And you can do that when you end up in this situation where your survival is not depending on shipping. And that’s, I think, perhaps the key constraint that is so powerful in those early days of the business, is that you simply can’t afford that. You can’t just hire 20 people and send them off to work on something for 18 months, and then they come up empty-handed. If that ever happens in a startup, it’s dead; it will not survive.

So you have these pressures, you have these constraints that force in the early days, and in the later days, you have to recreate those constraints through sort of willpower. And that’s actually much harder; it’s so much easier to become flappy when you don’t have to be tight, when you don’t have to be clear.

So I write these shipping principles as much to myself, as much to Jason as I’m writing it to everyone else at the company, that we need to remind ourselves of what we believe to be true. And then we need to live it. We’ve been going at this, with Basecamp, for example, for 18 years, right? The threat is there constantly to lean back, and just – when I say coast though, I don’t mean relax. No one ever relaxes. Everyone is busy all the time. But there are a universe of people who are busy all day long, all week long, all year long, who accomplishes very, very little. Who are not effective; they may be very efficient, and they may use their eight hours a day in a way where things move around, but they don’t necessarily move forward. And I think that’s the key for me, with this focus on shipping. The shipping is the moment of truth. The moment of truth where whatever you’ve built now has to meet the market. And the market

is like turning the lights on. Right? You can have all these ideas in your head about the quality of what you build, or whatever. They’re just illusions. Until you turn on the light, until it meets the market, they’re fantasies, and I love dispelling fantasies; in either direction. Either the fantasy actually turns into reality, and we build something wonderful, and people love it. That’s obviously great.

[22:21] But I also think it’s great occasionally, to release something that people don’t love, right? Like, it’s a way to buttress your own humility here, that building software is hard, even if you’re very good at it. Even if you’ve been doing it for a long time. Even if you have a successful product, building software continues to be difficult. This is why we have not automated it away, despite the numerous attempts over the decades to like, “Oh, actually, programming - we’ve solved it. We’ve solved programming. Here’s fourth generation languages, here’s no code, here’s all these other things…” And it’s not that these things don’t have a place, it’s just that they don’t actually solve sort of the crux of programming, because the crux of programming is to make decisions that matter.

Now, if you can abstract those decisions away, that’s wonderful. It probably means you work in a quite constrained domain. An Excel spreadsheet is one of the most powerful programming environments that have existed in humanity. Right? And lots of programs are written inside Excel spreadsheets. Great. Can you write Hey, an email system in Excel? No. You’ve gotta go down to the building blocks, at the level where the decisions matter. And again, this is this wonderful horizon that I care so much about.

Ruby on Rails, the framework that we use to build all our software, and that I extracted and created from the initial version of Basecamp, lives at this horizon. Can we take more of the things, more of the decisions that don’t actually matter that much, that don’t express themselves in a particular articulation of software, and abstract those away? Wonderful, I love that. That is the domain of conceptual compression, which is one of my favorite things to do, where you take something that’s a big, fuzzy, difficult domain, and then you compress all that complexity, and you make it easy, or at least approachable. And we’ve tried to do that in so many domains.

Ruby on Rails obviously have Active Record for dealing with the database; it makes it so much simpler. And most recently, Hotwire, the work we’ve been doing on the frontend, to dramatically compress all the, in my opinion, astounding complexity we found ourselves in when it comes to JavaScript development, down to a very small, core group where more people can build the kind of competitive apps that we all want to build, right? But with an iota of the effort. Hey I think is a great example of that. When we first shipped Hey - an email client, by the way, that goes head to head with Gmail, that competes with Gmail. Gmail shipped a - or ships still; when you load the Inbox, it ships 4.8 megabytes of compressed JavaScript, which actually expands to, I think, 29 megabytes of JavaScript. An astounding amount of code, right? Hey, ship, the first bundle - 30 kilobytes. 30 kilobytes with an application that goes head to head with Gmail, in a modern way. That’s the kind of conceptual compression where we’re talking orders of magnitude less stuff to solve the same problem, in a, in my opinion, far more pleasurable, enjoyable way to work, a far more labor-intensive way to work, and one were, we shipped, we met the market, and the market says, “This is good.”

Kevin Ball: I also just have concerns about the level of concentration of power at Google. Frankly, they own too much, and I feel conflicted about this, because unlike Facebook, which I also have concerns about… Facebook - I could leave their product behind and not be bothered. Google - I love a lot of the stuff they’re doing. Search is amazing, Gmail is amazing, they’ve got the best calendaring options… They’re doing great, great stuff, but they also have just a ridiculous level of control of the web. They suck up over half of the web’s advertising dollars, they have massive browser market share, they have massive email market share, they have massive market share along all these different dimensions, all in one company that has basically shown that their business model is to get the best possible model of who you are as a person, so they can show you the best ads. That’s terrifying.

Danese Cooper: [11:48] You know, I don’t remember that that’s why Linus chose the license. I think Linus chose the GNU license because it was the only one he knew. Richard Stallman did a lot of running around, talking to universities about why freedom was important, and his style is very sympathetic to people of that age and that ilk and a lot of projects from that era are licensed under a GNU license because they had heard Richard speak and they knew it better than any of the other options; they didn’t really understand what the other options were.

But the BSD project, which was the permissive licensing that Bill Joy invented, happened almost – well, now I’m in trouble, because MIT was working at almost the same thing at almost the same time… But permissive licensing dates from almost the same era as the free software licensing, and the projects pre-date the projects that Richard Stallman launched under that new license… So I think there’s always been both sides. I have to say that – I mean, I have a bias, because I’ve been an Apache member for a long time… I think that in my experiments for Sun with pretty much every licensing model you could possibly imagine, including all the possible hybrids, permissive licensing definitely drives adoption better, if you happen to be a deep pocket, trying to get non-members of your community to join in, right? Which is a bunch of ifs. But there is that situation.

In the early days of corporate involvement in open source, the very first corporate project was Mozilla, and Netscape at the time was considered a big company; not as big as IBM, but they had a pocket and they were worried when they constructed their project. They did it as a Hail Mary, because Microsoft had just destroyed their market by distributing Internet Explorer with every copy of Windows for free, and Windows was 98% of the install base at that point… So this is why that whole lawsuit happened about anti-competitive practices that Microsoft was doing. And they’d been doing various other things, it wasn’t just open source were picking on. They were anti-competitive all over town, but this was a really obvious example.

So Mozilla, among other things, did a Hail Mary and put their client software that was competitive with IE as open source, thinking that that would drive adoption and keep them alive. And it worked, right? But they were so worried that people would not feel comfortable as individual contributors, because at that time most open source people were hobbyists and individual contributors. They basically waded everything in their license to reassure the individual contributor that they weren’t going to harm them, while still being fairly legalistic about things like copyright jurisdiction, patents and a bunch of other stuff. They were really bending over backwards. As it turned out, they needn’t have worried because their initial code push was kind of a mess, it wasn’t really set up for anybody to use it.

The next thing that happened was they got a new owner, and the new owner didn’t like the way that open source worked - this was AOL - so they were gonna pull the plug, because they couldn’t get their own stuff in fast enough, and because the community vetting process was frustrating to them.

We were in the middle of that lawsuit, and Sun decided that it couldn’t afford to have that browser go away, and so another Hail Mary thing happened where IBM and Sun’s lawyers went and talked to AOL and convinced them to release the IP into a foundation, and then to give a little bit of funding; Sun and IBM each also gave a little funding, and that’s how the team was provisioned to write Firefox.

Jerod Santo: Why GitHub actually won

Scott Chacon writes up his insider’s take on why GitHub became the de facto code collaboration site. Here’s the quick version:

I can boil it down to exactly two reasons that happened to resonate with each other at the perfect frequency.

1. GitHub started at the right time
2. GitHub had good taste

All four GitHub cofounders had flops both before and after GitHub. Chris and PJ couldn’t quite make FamSpam work before GitHub, Tom and I couldn’t quite make Chatterbug explode after GitHub. I think both of these ventures had good taste and great product, but it wasn’t the right place or time or market or whatever for them to become GitHub level.

One of the problems with success is that so much of it relies on timing… which is one of the big things we cannot control. What we can control, however, is what we decide to build:

We cared about the developer experience and had the creativity to throw away assumptions about what it was supposed to be and build how we wanted to work. Everyone else tried to build what they thought they could sell to advertisers or CTOs.

This strategy is commonplace today, but it was avant garde back in 2008. Definitely read Scott’s entire post of the full history lesson on what developer tooling looked like when GitHub entered the scene.

Alex Russell: Yeah, it’s a really deep question. So my perspective is that a couple of things stopped being true that had been true in the past… And if you look at the 2010, ’11, ’12, ‘13 moment of frameworks coming in from the cold as like this brave new way to do everything, they had mostly been built in a desktop-first world. The mobile web was not a sidelight at the moment at the time. Post 2008, post iPhone, mobile users were a real thing. Every business was thinking through, “Do I do responsive? Do I do [unintelligible 00:21:19.11] What is my approach to doing all of this?” Those conversations started to fall away at some point, because the tools that people would pick up, that they preferred, had been built for this desktop era, and they just weren’t working on the mobile side of things. So a lot of businesses actually split their vote, and said, “Okay, well, we’re going to do apps for mobile, and we’re going to do web for desktop, and never the twain shall meet.” And of course, this creates a whole new series of product problems. But the key thing about this is that the JavaScript community, the web community was kind of high on its own supply by 2010, and had started to furiously discount the reality of mobile.

And then as soon as 2015 happened, and Apple started to pull away, like really pull away on CPU performance for devices, the fact that the wealthy developers who were the JavaScript intelligencia all carried iPhones started to create an ever tighter privilege bubble around their experiences, in which they couldn’t understand what people like me were on about. I gave this talk in 2016, talking about - I’ll find you a link - how the performance of the stuff wasn’t working, and trying to put a finger on exactly these factors. But Moore’s Law was working, in the sense that every 18 to 24 months we would continue to see a doubling of transistors for a given price, right? Like, that’s kind of the outcome of Moore’s law. But because the price of devices were just falling as they entered mass market, that meant that we had a fixed performance budget every year, because we were in an explosion of distribution to ever poorer users, year on year; the next marginal user who’d get a smartphone that for the first time, the person who was somewhere in rural Indonesia, or rural India, or a tier three city in India, who were swapping out their flip phone that they’d had for a decade, for the first smartphone, they weren’t paying $400, $500, $600.

For the last decade, that median price of a smartphone has basically been the same, at about 300 bucks; it’s been hovering – like, it fluctuates a little bit. At the same time, I think if you’re wealthy like us, if you live in a house in the United States, like your wealthy world historically - if you’re wealthy like us, then the price that you will pay for a new unlocked device has only continued to escalate, as has the performance of that device.

[23:48] So we have been experiencing a discontinuity, where our previous alignment as developers to something that kind of felt a little bit like the lives of our users - like, maybe we’d have slightly faster computers, maybe we’d have slightly better network access… But you know, we had friends and family whose experiences were basically kind of in line, if they were online; that is now a yawning chasm. People talk about the digital divide - this is the digital divide, is the median to low-end smartphones versus the wealthy people devices. And that has also kind of, by the way, started to take hold in desktops as well, although it’s a much smaller market. Desktops are important, obviously; Microsoft thinks desktops are important, but they are not the same thing as where the puck is going.

And so web developers didn’t adapt to that new evidence, and as the evidence started to show up, it became pretty clear that there was a whole pile of people who didn’t want to engage with it, because it was going to invalidate some of their preferences and priors. So this post I wrote this last week is – like, I gave a talk in 2016 that said, “Hey, we can fix this yet.” And I gave a talk in 2019, where I went through a bunch of the data about how it still wasn’t going well. This is the final straw. This is “Yeah, done f****d up. It’s not working.” And in that sense, I have seen so much over this long arc of so many teams get stranded in exactly the same way, and they all think that there’s something wrong with them.

Adam Wiggins: [06:04] So I guess we had the luxury of being able to think in terms of a slightly longer time horizon, and were less thinking in terms of, “Okay, what’s the startup we can start tomorrow that solves a really immediate pain point, and we can get customers, and get into YC?” and sort of that very pragmatic aspect of commercial business. And we all started to get interested in more academic research. In particular, we ended up kind of taking a deep dive on the industrial research labs that have been very influential in our industry. So Xerox PARC is one that I think is oft quoted; they basically invented the modern GUI, and the laser printer, and Ethernet, and so on… But then you go more back in time, you can also look at something like Bell Labs, where Unix was invented. And also lasers, and also GPS, and also transistors. Now, they obviously had a very long run over several generations, but that’s a dramatic example. And there’s others; you can go even further back and look at someone like Thomas Edison, for example, and what he did with his Menlo Park; it was like a private industrial research lab, you might say.

So looking at all these historic examples, we got inspired and said, “Okay, well, we want to think about what the future of computing looks, not just in terms of what’s an immediate pain point we can solve right now, that might be a business opportunity, but taking a little bit longer time horizon, a more academic perspective.” And we sort of combined that interest in what’s called R&D, if you like, with a look at the current state of computing. So in 2015, the iPhone and the App Store have become pretty well entrenched, Facebook has become this juggernaut, social media generally… And it’s interesting, between the time when we started Heroku and where we were here, thinking about “Okay, what’s next?”, the computing industry had gone through a shift where before – you go back to, I don’t know, certainly when I cut my teeth in computers in the ’80s and ‘90s, but even in the 2000s, computers were really for making things. They were for word processors, spreadsheets, programming, Photoshop etc. And you could do email, and stuff like that, but in general, they were devices for productivity and creating things. And I think the thing that really happened in the last decade or two is a shift to the mass market, where they’ve become more consumption devices, right? Like, a phone is more for messaging with your friends, looking at social media, watching videos, shopping, that sort of thing. And that obviously has been an unprecedented boom for the computing industry, and we see more people using computers than ever before, and there’s many, many ways that’s a good thing. But we had this strange feeling that what we thought of as the original use of computers was sort of languishing away.

I always like to think of the example of like - think of how far we’ve come in something like the ability to watch movies, or TV; what did that look like circa the ‘90s? It was like broadcast TV, and VHS tapes that you could rent from Blockbuster, or whatever… And you compare it to today’s always on demand streaming, on your iPad, whatever… It’s like science fiction technology, comparatively.

Mike McQuaid: The hard bit of Homebrew is there are 10,000 packages in there, all of which are built and installed and tested slightly differently, all of which pull slightly different things from slightly different places, and interact in slightly different ways with each other, and the ecosystem… And some of those packages are very easy to update, some of them are very painful to update. Some of this stuff is easy to change, and some of it is not easy to change. And essentially, you need to take over – I think that’s the thing, is that it’s not just a matter of “Well, Apple can kind of point everything to themselves.” But what we said earlier about maintenance - Homebrew requires fairly… I mean, considering how relatively few people have worked on Homebrew in its history, it requires an astonishing amount of maintenance. And just keeping all of that software working, and up to date, and compatible with macOS releases and stuff like that is a lot of work. And one of the great things Max did in the early days was Homebrew was released relatively shortly after GitHub was public. Less than five years, I think, after kind of GitHub was on the kind of public internet, and you could sign up… And one of the smart things Max did was making it so that Homebrew was from the outset not maintained explicitly by Max, but was like “Hey, I’m Max, I do some stuff, but Homebrew is maintained by the community.” And again, this is the problem with – this is the nice thing we have with kind of open source projects… People may have gotten annoyed with analytics in Homebrew and various other stuff, but no one has actually ever seriously and successfully forked the project. But if Apple were to take it over, I would think there would be a very real chance at the same time you have a bunch of community people who are like “Hey, we want to go and do that.” And also, the community people are happy to kind of work on a project where some of our maintainers get like a small stipend, but no one’s being paid anywhere approaching market rates for any of their time, right? And no one is employed by Homebrew to work on Homebrew.

How much do you want to spend your evenings and weekends contributing to one of the world’s richest companies to run their package manager? Essentially, they would have to insource not just what the maintainers do, but what all the volunteers do, essentially, as well, because most of those people are probably not gonna want to spend all their time kind of helping Apple for free. So yeah, I think it’s interesting. I think it’s definitely kind of a tricky situation… But as I said before, I don’t see a world in which that happens, because –

Matias Pan: I think it’s interesting, because it’s a context that probably a lot of people are finding themselves in. A lot of companies went through really crazy hyper-growth, and then all of a sudden the bear market hit, and they were left with this application that grew very rapidly, with a team that probably didn’t know much or at all about infrastructure, and a really big team, but not really all that amount of money that they can use to continue growing. And when you get to that point and you want to continue making your product better - because you’re not reaching hyper-growth, you’re reaching for the classical breakeven, or in a way making your product profitable - you will have to make a lot of decisions regarding your architecture and your infrastructure, that they all have to keep in mind that what you want to do is reach that breakeven. You want to actually be able to continue to deliver value to users, and hopefully, that value gives money back to you, and you can keep the company running.

So when I joined Lemon - Lemon Cash is the full name of the company - that was the exact context in which the company was in. There was a really, really big, monolithic codebase, that had so much code, from so many different domains. We’re talking about a bank/crypto, so it has a lot of things related to a bank, but it also breaches you into the crypto world. And not just like tokens, not just like currencies, but also like NF Ts, and the entire gamification that the crypto industry is trying to bring.

[05:53] So this was a big up. A lot of very clear, separated domains in this single place, and the entire infrastructure in which this was laid on was not something that happened on purpose. So it wasn’t far off. It was “Hey, we have to get this to production now. What do we know about it?” “Not much.” “Okay, there’s this thing called ECS, that they’re saying it’s serverless, and they’re saying it’s super-easy, and there’s this blog post that a big company wrote. Let’s just use that.”

And then when I joined, the company grew from 5 developers to 300 people, which brings a lot of really different problems where you’re working on that monolithic codebase… And the idea of going to a service-oriented architecture was kind of natural, in a way. And when I say natural, I don’t mean that it’s the obvious choice. It’s going to depend on what context you’re in. But we’re talking about a bank that has the most critical thing at hand, which is money. And you always want that bank to work perfectly. So for a bank, the idea of services allows you to separate the failure domains in a very clear way, and make sure that the product is the best thing that you can do.

So yeah, the decision itself had already been taken, and when I joined, they were already discussing about going into a service-oriented architecture. But there were no discussions around the infrastructure side of going to that architecture. And for me, at least, that’s the biggest problem you have to at least think about and solve in part, before actually committing to that. It’s perfectly fine to start separating the code, understanding the domains and doing that exercise, but when you want to actually execute that, solving the infrastructure part, the observability part, the monitoring, how you get things to production, how you operate on those services, how do you have on-call policies - everything related to having a service in production also needs to be discussed.

So that’s where this proposal that you mentioned came to be. It tries to tackle how you should be deploying services, at Lemon specifically - that’s why it’s in the title - and it puts that in the context of all these other things that we also have to solve in order for the company to operate services gracefully, I would say, in production.

Emily Robinson: [24:03] Yeah, I think the job market right now is pretty good for people who’ve had at least one year of data science experience… So with a job title like data scientist, or something very similar. I think it is harder for people who are, say, coming out of a bootcamp, or undergraduate, or trying to just change careers, doing online courses, just because there are just more of them. There are fewer people who have had experience working in data science.

Companies use different methods to understand whether someone is really good, and often the easiest one for a recruiter to do who maybe doesn’t know know the field that well is just “Did this person have the title that they would have here? …which means that some other company said that they could do this job, or at least thought they could do this job enough to hire them, and they’ve had experience doing it.”

So what do you do if you haven’t had – how do you get over this paradox of needing experience for getting experience. Needing a data science job to get a data science job. And I do think that’s where the portfolio piece can really help. A portfolio would be having your code and some projects up on GitHub, and I think ideally on a blog. Why I think that’s important is 1) to have something to show employers, to show that you can do the job that they’re asking you to do. That you can take a question that you come up with, find the data, analyze it, and present it back, whether that’s by writing a blog post or by making a web application. I do think this can really help yourself stand out, especially if it’s an original portfolio project.

So what I don’t think would be really helpful here is, for example, your script for trying to predict who’s gonna die on the Titanic, which is a very classic Kaggle, beginning data problem… Because that’s not especially original. Who knows if you copied that code from someone else… Versus, “Hey, I’m really interested in fashion, so I use New York Times’ API to pull all the fashion articles, and then I did some topic modeling to see how different trends came in and out of fashion.” That’s a very original idea, it shows some personality too, and I think that can be a really strong way to help you stand out.

But at the end of the day, I mentioned a little bit earlier, networking is really important. A lot of jobs go to someone who was referred by someone who’s currently working at that company, or through meeting the person who is hiring, or meeting someone related on that team… And I think trying to expand your data science network can be a really good step in getting that first job.

Eric Berry: A hundred percent. In fact, I gave a talk at a conference, the Ruby Hack conference back in April, and in that talk I actually defined how developers’ roles need to change in order to really increase funding in open source. Now, any developer that comes in, the easiest thing to do would be to add a button to their repo and say “Hey, donate money if you’re using this.” Very easy. But the likelihood of any return on that is next to nil.

Kent C. Dodds, which is a fantastic person, we both know… The creator of Cross and many, many wonderful libraries - he had those buttons on every one of his projects for a year and he didn’t receive one donation. Not one. So in this talk, I visualized a graph that’s essentially an exponential curve, and on the bottom part of the graph is the amount of money that you can receive, potential earnings. And on the left part of the graph, going up, is the amount of change that a developer is required to perform in order to make that happen.

And you mentioned the entrepreneur, which there’s a lot of money to be made in that entrepreneurs’ side of open source, if that’s the way you wanna go. It’s been proven with Sidekiq, and it’s been proven with many other libraries, but at the end of the day, you’ve gotta be a unicorn to pull that off; you really have to know how to market yourself, how to advertise, how to build a company, how to create a business model that’s gonna turn a profit, and how to maintain both sides of the free and for-cost of this project. And on top of that, your project has to be popular enough to justify that type of thing. The middle ground that I’ve found is support.

Now, a good example that I show is Trailblazer. Trailblazer is like a framework that sits on top of Rails, that changes things around and makes it a little bit more – I wanna say verbose… Go to Trailblazer if you wanna find out what they do, but you go to their website, and I see three things - there’s a premium support, there’s a book (they sell a book), and they are sending out stickers. They’re doing a lot of marketing and support for that, and I’m sure they’re getting pretty decent money doing that. They’re not seeing Mike Perham money, but they’re still seeing money.

But again, it comes back to what does a developer wanna do? Do you want to be a support person? Do you want to write books? Do you want to start a business with this, or do you just wanna continue building open source? And unfortunately, I don’t see a lot of ways, aside from licensing software or advertising, that will let you continue acting as you have always before, and still make a decent amount of money back.

Adam Stacoviak: That’s definitely a neat idea. I think that a lot of people are approaching that market, and probably 90% of them don’t have quite the understanding you do of technology or how to actually execute and build something. One thing I like about your perspective, Sam, and your story, is what you’ve just said there, which is to work yourself up to something and then lose it all and then work back to it… I think having that perspective and having been through that few times - I mean, we said earlier that you’re like a professional seller of stuff, because you’re used to just kind of like buying things and getting rid of them, and then kind of opening new chapters, but… You kind of wrestle with life; I mean, not that you are in control of it, because obviously you’re not, and you deal with the hurdles and constraints and boundaries that you have in different ways than other people, but I think what you’ve proven to yourself is that stuff and things are interchangeable and they don’t really matter quite as much as people let them think they believe - a house, a salary, where you’re at…

[01:00:17.10] You know, life is what you’re gonna make it, and you’re tougher than let’s say not so much the average person, but you’re just tougher than life lets you think you might be… Because sometimes we lie to ourselves that “I’m not that strong and I can’t bounce back should I lose my house, or should I do whatever”, and put this risk out there and lose it all. You’ve kind of like taken the bull by the horn, so to speak, and just don’t look back, and win.

Danielle Rath: Yeah, I think one of the trickiest things about studying caffeine and energy drinks is that there’s always been this temptation to bucket everything into “safe” or “dangerous”. Or “All energy drinks have this much caffeine, this much sugar, and these ingredients.” And the challenge is that if you look at the products on the marketplace, whether they’re powders or pills or liquids, that have caffeine in them, they’re all different.

So it’s always been very difficult to address questions about caffeine safety, or putting butter in your coffee, or “Do energy drinks kill people?” because there’s so much diversity in this field of caffeinated products… And some things that people think are very dangerous, like Red Bull, are actually weak sauce and less scary to me professionally than some of the drinks that people have never heard of, or drinks that people love, like Bang. So there’s the disparity in terms of the consumer perception and what I believe as a scientist is actually the biggest threat.

Jerod Santo: The pain that is Github Actions

Gerd Zellweger had to redo their CI setup on GitHub Actions and shares a bunch of the pain points he hit along the way:

Our CI is complex: merge queues, multiple runners (self-hosted, blacksmith.sh, GitHub-hosted), Rust builds, Docker images, and heavy integration tests. Every PR we merge burns through an hour of CI time, running across multiple parallel runners.

There are a few things we’d like to have (which we deem as “good software practice”) but it’s nothing unheard of:

1. Everything that goes into main must pass all tests.
2. Trivial mistakes (formatting, unused deps, lint issues) should be fixed automatically, not cause failures.
3. The artifacts we test with in CI should be the exact ones we release.
4. CI should complete quickly (to keep developers happy).

GitHub Actions technically allows all of this—but setting it up is a frustrating mess, full of hidden gotchas, inconsistent behavior, and a debugging experience that makes me question my choices.

One of my concerns when GitHub first got into the CI game was that their already-the-host advantage (which is real and great) would be so massive that they wouldn’t have to innovate much beyond the basics to completely take over the market. Maybe that concern was valid?

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.

John Nunemaker: Yeah, so we’re super-conservative. A lot of people are like “Oh, being an entrepreneur is so risky. I could never do that. I could never start my own thing.” And I’m just – I’m the opposite. I’m like “It’s the easiest way for me to reduce risk.” Because you can control things. So for myself, when I look at “What are we going to do with Fireside?” I’m like, “Initially, we’re just going to let the dust settle.” So let’s update some software; it’s on older versions of Ruby Rails… Again, just boring stuff. Let’s show customers that we care, let’s be fast responding to support, let’s help people… Let’s actually actively market it. That’s I think the biggest thing that nothing has happened with in the last, let’s say two years, is that there’s just no marketing. And so I’m like, that’s one of the reasons why one of the people that I wanted to make sure was in it was my friend, Chris, because that’s what he does. He does marketing.

[28:27] So we’ll get an email list going, we’ll get things when you sign up, where it’s like “Here’s how you can better use us.” The normal things that every SaaS app basically does to kind of hopefully increase engagement and usage and stuff like that. There’s a lot of low-hanging fruit that I think we can do because it’s kind of just sat and in an awesome way chugged along.

So I feel like that’s step number one, is like the rest of this year is probably “Look, let’s stabilize it. Let’s start building some trust back up that we’re going to do things with it, and talk about it”, and get to where we can start moving more quickly. And then next year will probably be like “Okay, here’s some new features” and things like that.

So as far as what we have actually picked out to work on and stuff, we’ve definitely got some ideas. I wouldn’t say we’ve said “This is what we’re going to do first.” The goal is not all in, the goal is not – again, I always have like two or three things, so my goal is never be all in. My goal is always – which has always felt wrong, because everyone’s always like “You’ve got to focus on one thing. And if you’re doing two things, you’re stupid”, you know? And I’m like, I can work at 110% if I do 80% on this and 30% on another. But I can’t work at 110% on one thing. I just can’t do it. It’s boring. I just – you get locked up once in a while on an issue and your brain’s got to process that in the background. Sometimes there’s just no way past it. And so then I can just move on to another thing, and it’s like, my brain lets go, and then it can solve that other thing while I’m doing something else. It’s not full multitasking, but it kind of – I find it’s helpful for me. I’m able to kind of stay more engaged in things for a longer period of time, because there’s more things to keep my brain busy.

So it’s not an all-in thing. So Garrett will be a couple of weeks on Box Out, a couple of weeks on Fireside… My hours that I’ve worked with my partners, that they’re okay with me doing on Box Out every week, and then the rest will put towards Fireside, and Flipper, and stuff like that. And then the goal is definitely to grow it. I would say conservatively – I’ve never worked on a SaaS that hasn’t grown at like 20% consistently. Maybe Fireside is the first where I can’t do that, because there’s just so many people in the space… I have no idea. We’ll find out. But in my head, I think 5% is totally reasonable. And at that rate, I’ve done the math; based on the capital we started with - and we financed it a lot of it - based on those two things, I think I can have… Even at 0%, we could pay off the loan in five years. Let’s say 5% growth. At 5% growth, we can pay off the loan in like four years. At 10%, at the end of year three; whereas maybe it was the middle of year four at like 15%… It’s like three years, and it’s paid off, if we want to. Again, from free cashflow. And that’s with taking money out of the business to pay ourselves some money as well.

So if we can just grow like a little bit, and take a little bit of – so let’s say you have a hundred thousand in free cashflow, you do some amount each for some salary to work on it, and then you take out some more; it has more than that, but let’s just say it’s that. It’s easy to do some math and say “Okay, we’re going to take 50% out for the people working on it, and the other 50% will go towards dividends, and paying off the loan early.” So that’s kind of like how we look at it. We’re like “Look, we don’t have to be full-time all-in.” We don’t have to beat Transistor, Buzzsprout, any of the other – whatever, there’s a million out there that do this kind of stuff. All we’ve gotta do is like do the things we know how to do on every SaaS we’ve ever worked on, and the likelihood of us growing is good. Perhaps that’s naive, perhaps that’s just like 20 years of experience and it will be accurate, and it’s not naive… I don’t know on that. I’ll probably need to come on in a year or two years and then we’ll have a better –

Benjamin Consolvo: Yeah, thanks. Probably the best place to start on this is and what I’m excited about is Falcon Shores, like you pointed out. So Falcon Shores will be kind of the culmination of combining the Gaudi product line with the GPU, with our current Max Series GPU. And it will be a GPU, a graphics processing unit, so it will be a full GPU capable of not only the AI workloads, but also graphics and other applications that people want to use GPUs for.

So I think that’s probably the most exciting thing that we’re kind of aiming at, that we know the market needs. And then yeah, iterations on, as you mentioned, the AI PC. In the future we’ll also have a new, more powerful AI PC with the Lunar Lake chip coming out, and again, it will include the CPU, GPU, NPU, but it’ll be a much more powerful, more memory form factor, where developers will get even more out of their local machines. So yeah, those are a couple of things.

And then the other thing that I’m excited about just as an AI software developer myself is the integrations with – like I pointed out at the beginning, the integrations with PyTorch. I think it’s huge that we’re aiming at getting all of our optimizations and everything we can into this framework, that is by far one of the most popular deep learning frameworks, and one that I use on a regular basis.

[00:38:14.29] So that’s really exciting to me as well, that just natively I’ll be able to work with PyTorch and say “Hey, I want to use the XPU”, which is for the Intel GPU. And same with the AI PC, just have that direct integration. So yeah, those are a couple of things that are exciting for me coming out soon.

Adam Stacoviak: I like the idea of the TUI/command line utility being symbiotic in the fact that you might hop into the TUI to do a more deeper visual application-like experience, that also has, like you had said, a configuration or setting. I’m thinking like even Tailscale; I’m wearing the T-shirt today. Big fan of Tailscale. Not sponsored… Where they can even have a TUI like that, where you’ve got multiple machines across your tail net kind of thing. You might go there and configure a collection of machines… I don’t know, do some cool stuff in the TUI. But at the same time you still have the traditional Tailscale CLI, or even in the same case here with [unintelligible 01:29:26.12] It’s like, the application is just one more way you enjoy the CLI, the command line interface that is there. It’s just a visual version of it built probably on top of it, with Textualize, or Textual, or Rich, or whatever they’re trying to use. I think more people should adopt these things, man… It’s just like an underserved market. I like it. Please do more of it. Please.

[01:29:51.27] Let me ask you one question here, Nick, on this Docker Stats, if you don’t mind… Because I have a question, because I did this on my Plexbox, which is an Ubuntu machine, in a VM, on Proxmox, so it’s got a single usage. Yes, I know I’m running Docker on top of a VM, on top of Proxmox, there’s multiple layers… It’s kind of unnecessary, but I like it, because it just keeps it siloed. But anyways, I digress. So when I type in “docker stats” on this Plexbox, which literally is only a single Ubuntu box dedicated to running Docker, to run a single Docker container, which is the Plex Docker container. Just to give you a full circumference of the reason for the machine. The CPU - I run Docker Stats, and it’s real time… The CPU is at 66 point whatever. But then - because I run tmux - I go into a new tab and I SSH back into that box again, and then I type htop, because that’s what I have on that box… And I see that my CPU is not being taxed at all at that percentage. What’s the deal? Why is Docker Stat seeing such a high CPU usage and it’s not?

Benn Stancil: But I think that if you have – people are generally aware, I would say, that the data industry is full of a lot of tools that were propped up by the good times of 2021-2022, and probably are vulnerable in a number of ways. They’re like businesses that are not really designed for a slower market, they’re businesses that were sort of spending as though there was no tomorrow, and stuff like that… They’ve made the adjustments and sort of – they’re not still doing that necessarily. But it’s hard to sort of restructure a business to that degree.

I think there’s a lot of understanding that these products, some of them are like good ideas, but there’s space to reimplement them, or like just build really good versions of it… And I think there’s a lot of investors that are chasing the Notions and Linears and Figmas of the world that are kind of this polished craftsmanship version of an existing tool. I think you can pitch that. You can be like “Look, we are the same as these other things, but we’re just gonna do a really good job of it. We have this great team. Let us show you the quality of our craft.” People will always – I think you can sell that pitch.

So no, I don’t think you have to bootstrap. I don’t think you can raise at the sort of astronomical valuations by any means, but yeah, I think if you come along with something that’s like “Yeah, this looks exactly the same as the other thing, but our goal is we’re just gonna make it really good, and we know how to do that, and we’re great at our craft.” I think there’s always sort of money to be had in that pitch.

Shawn Wang: Right. And this is not to say that data scientists demand has gone down at all. This has been a secular growth trend for decades. I would just say this is just a different type of skill set that makes you successful in this era, rather than the previous era. And whether or not you are successful here relies a lot more on your creativity and full stack product development skills than just pure data science… Because data science comes in later, when you have data to work with. But now when you have foundation models that you can just prompt and make an MVP so quickly, you actually need to be creative and quick to market, rather than being deliberative and analytical. Being analytical actually slows you down, and makes you too conservative. Like, what are you doing worrying about costs when the cost of intelligence for GPT 3 goes down 90% a year? That kind of stuff.

Scott Chacon: But I do want to differentiate a little bit, in that I think one of the things that we miss from this conversation a lot is the differences between I think three functional classes of software. One is libraries, which cannot be GPL. I mean, in lots of cases. Because if something’s GPL or AGPL in the library – like, we run Cargo stuff on Rust all the time we’re distributing a binary. We need to be very, very, very clear that there’s no GPL code that we’re linking into the app. So OSI is not the important definition. It is “Is it copyleft?” So copyleft is an important definition to me.

The other is infrastructure. And so if it’s an infrastructure tool, I think, or if something you want to build infrastructure tooling off of, like – I mean, I would even argue Redis, or Open Search or something goes under this, right? Like, is it okay for you to change licenses at some point? Because I think that the answer is generally no, because people assume that infrastructure is going to be available in the way that it’s available. And the downside for somebody building it – like, this does create a marketability thing - somebody will adopt it because it’s under a specific license. And then you can’t have that market share unless you’re really, really good at it. And I don’t want to use – I think I want to use the one that I have in my AWS instance, or whatever, that I’ve already built off of. So that does feel like a little bit of a rug pull, because it makes me do work when they change that, theoretically.

And then the third class that I think is really important is applications. And applications, I think, are different than infrastructure, because you can’t – what is competition in that sense? It’s a very different thing than trying to build something on this sort of infrastructure, a sort of tool, to say “Okay, it’s the Git client, or some desktop application, or your web browser”, or something like that. Like, of saying “Okay, only Google can distribute Chrome”, right? Yeah, that has implications, but I don’t think anybody that’s contributed to Chrome were people who wanted it to be Brave, or something. Like, had that in mind. If Google switched to being Chrome’s FSL, or something, I feel like most contributors - maybe some, but I feel like most contributors don’t care that much, because that’s not really what the value of it is. The value of having it source available is a little bit different than being able to depend on it for being able to deploy infrastructure, or build infrastructure around something.

Anyways, I don’t know really what the answer is, but I do think that when we talk about licensing and commercial licensing and open source licensing, that it’s important to sort of differentiate these classes of software, because they have very different implications of what licensing means in those contexts.

Kevin Ball: So high level, there’s a couple of things that I’m referring to here. So one is they’re pumping up the market, “This is a standalone – why get a coding assistant? Get something that can go and do your software.” And they published some data on it, and it does do better than the state of the art in terms of tackling going from a GitHub issue, to “Okay, I’m gonna actually solve this [unintelligible 00:03:50.05] to happen.” But the number they published, I think, was 13.86% of issues unresolved. So that’s about one in seven. So you pointed out a list of issues, and it can independently go and solve one in seven. And first off, to me, I’m like “That is not an independent software developer.” And furthermore, I find myself asking “If its success rate is one in seven, how do you know which one?” Are the other six those “It just got stuck”? Or has it submitted something broken? Because if it sets up something broken, that doesn’t actually solve the issue, not only do you have it only actually solving one in seven, but you’ve added load, because you have to go and debug and figure out which things are broken. You have a whole bunch of additional load. So I think the marketing stance there is little over the top relative to what’s being delivered.

The other thing - and this is around… I think a part of what they do is “Oh, it can spin up resources for you.” And they showed this cool demo of “You point it at this thing and it allocates a bunch of different production resources for you.” And the person who’s handled DevOps in me before, and now the engineering leader who has to sign off on our Digital Ocean, or AWS, or Google Cloud or whatever expenditures you might have, looks at that and is terrified by “I’m gonna give an LLM, which is known for hallucination, which is…” These things are not – you have to design an application… And I’m building applications [unintelligible 00:05:24.16] but you have to design around their unpredictability and their willingness to lie… And I’m going to give that raw access to spinning up resources in my cloud? Like, that sounds – well, it sounds like something I would not sign up for, I’ll say that.

Kevin Ball: So high level, there’s a couple of things that I’m referring to here. So one is they’re pumping up the market, “This is a standalone – why get a coding assistant? Get something that can go and do your software.” And they published some data on it, and it does do better than the state of the art in terms of tackling going from a GitHub issue, to “Okay, I’m gonna actually solve this [unintelligible 00:04:29.17] to happen.” But the number they published, I think, was 13.86% of issues unresolved. So that’s about one in seven. So you point out a list of issues, and it can independently go and solve one in seven. And first off, to me, I’m like “That is not an independent software developer.” And furthermore, I find myself asking “If its success rate is one in seven, how do you know which one?” Are the other six those “It just got stuck”? Or has it submitted something broken? Because if it sets up something broken, that doesn’t actually solve the issue, not only do you have it only actually solving one in seven, but you’ve added load, because you have to go and debug and figure out which things are broken. You have a whole bunch of additional load. So I think the marketing stance there is little over the top relative to what’s being delivered.

The other thing - and this is around… I think a part of what they do is “Oh, it can spin up resources for you.” And they showed this cool demo of “You point it at this thing and it allocates a bunch of different production resources for you.” And the person who’s handled DevOps in me before, and now the engineering leader who has to sign off on our Digital Ocean, or AWS, or Google Cloud or whatever expenditures you might have, looks at that and is terrified by “I’m gonna give an LLM, which is known for hallucination, which is…” These things are not – you have to design an application… And I’m building applications with an LLM, but you have to design around their unpredictability and their willingness to lie… And I’m going to give that raw access to spinning up resources in my cloud? Like, that sounds – well, it sounds like something I would not sign up for, I’ll say that.

Nathan Sobo: I don’t know. I don’t know that I fully even understand what it’s gonna take to get to Linux… But I think we can get there within low-single-digit months of a fraction of the team, and then we’re going to see what the ongoing maintenance cost of it is relative to its value.

In terms of the business model, what we’re focused on right now is adoption. So adding a second platform opens up a very large number of potential users who might be interested in it. So it serves that goal. And community development is another business goal we have right now.

In my mind, again, the nature of a company is – obviously, we do need to become profitable and have a plan for becoming profitable… But every venture capitalist knows how large the market is of developers, and how valuable that market is… And so right now I think we just need to stay focused on getting adoption. I’m happy to take people’s money, and one thing we’re thinking about is just like at least giving people a good out-of-the-box code gen experience to use LLMs. And that’s something we could offer like a trial for, for example, just so that people can see it. And then it’s like, you get to the end of the trial, or you get to the end of the fast usage, and your rate limit is constricted, and now you can like decide to go to Open AI and sign up, and get an API key, or bring your own local model… Or if you want to just give us your credit card, we’ll take your money there.

But it’s not really our key focus right now, is like generating a ton of revenue. I think the key focus is like “Let’s build the community and get a ton of users using this thing”, so that we can like respectfully offer those users things that integrate with their workflow, and make them more productive down the line. And I hope I don’t turn people off with that, that we are planning on eventually offering facilities in our flagship build… But hopefully it being open source gives people the reassurance that if we’re too annoying about that, you can always build it from source, or get it from somebody else. But I think we’re gonna be able, with the collabs stuff – like, we’ve been hanging out with members of the community. It’s been small, but we’re just in these channels, coding… Like, it’s happening right now. There’s a couple of people working on Vim, Conrad and a member of the community… And it’s like - yeah, it’s been so cool just to… Even watching members of the community that we’ve granted write access just pairing with each other and not even involving us.

So I think on that front, the AI front or some unknown front, there’ll be something that we can sell to developers. I was glad you mentioned that, because I was referencing our transcript, Jerod, where you mentioned… If you want to search this, it says “The collaboration part”, the social coding part. And Nathan, you responded by talking about how you’re not trying to compete with GitHub. I think the conversation was around how these channels and this collaboration might circumvent the need for a pull request, because there’s this real-time collaboration happening… And I think that’s really interesting, because that’s what we really gravitated towards the end of the conversation, was how interesting it could be to have these real-time collaborative coding sessions inside the editor. Can you talk more about - like, when you referenced this channel, what exactly is a channel? How do you get granted write access to things? What are some of these terminologies? If a listener is listening to this and they go pick up Zed, how do they interact with channels? What is that to an everyday user? What is that to you all and how you’ve been using channels?

Deepak Prabhakara: Yeah, so there’s two fundamental points for us when we were thinking about go to market. We are serving the developers. And as a developer myself, and having seen my team multiple times before, it’s the best way to go and evaluate something. You’re either thinking about “Do I build this? Or do I pick up something that gives me some kind of foundation to build upon?” But then you can also evaluate it without having to talk to anyone, no sales, marketing language… You can truly see it functional, you can see the value… And that’s how you – it’s like the freemium version for SaaS, effectively. Some [unintelligible 01:19:11.22] we don’t even know who they are, they’re trialing it, and then they might come back around for more questions, or they might stumble into an issue and they’re on our community.

So that was kind of one major aspect, to think about how we’re discovered. But at the same time, we also realized that we’re quite close to infrastructure, and commoditized. We’re building on top of protocols. We’re not trying to reinvent the thing… Fairly interoperable protocols; we wanted to keep it that way. And that’s the best way to kind of bring in contributions from the community. Integrations [unintelligible 01:19:46.22] providers. Some providers we can’t get access to. We have a lot of help from the community who are using that, and are trying us out, and ran into trouble, and could help us troubleshoot, and submit changes to make it work.

[01:20:03.06] Those two were kind of the main reasons why we chose to go – and our license is Apache 2, so no restrictions. Fully free to use it. And what we have done is in an open core model there are certain premium features we identified, that only the larger companies need, and those are kind of locked up as requiring an enterprise edition. But that doesn’t prevent anyone else from not being able to use the full functionality of everything else.

So that was our thinking here, post infrastructure, how developers discover and evaluate us. But in the process, what we really found insightful was we get used in the tech stack in ways that we didn’t anticipate before. Because they can lift and shift us, right? So they’ve used us in places that we did not even think was the use case before. So that was quite insightful, to see the new use cases kind of emerging.