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

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

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

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

Jerod Santo: Yeah, that’s really powerful stuff. I also think when you’re doing feasibility – again, if we go back to the opportunity to start a business or have a business that actually, you know, the dog hunts… You know, you’re comparing your potential revenue versus your potential costs. So the cost calculations, if you’re gonna be cloud-based, a lot of times is exactly what you’re doing - you’re estimating how much this is gonna require us, what are we gonna be paying out a month to Amazon or to Microsoft or to Google, and is that gonna actually scale alongside the revenue that will come in?

So you can have your napkin math on the revenue side, and your napkin math on the expenses side, and start to make some decisions on “Is this completely upside down? Is it tight? Is it obviously an opportunity?” And then once you start having those answers, then you can say “Well, it’s obviously an opportunity. Let’s get more specific. Let’s fill in those gaps and take out the napkin and put it in the calculator, in the more specific spreadsheets, and drill in.” But if it’s completely backwards, let’s not waste our time with the details. It’s not gonna work.

John-Daniel Trask: My personal view – I always treat everything as a learning experience. I think that there is a broadly accepted untruth that a lot of very successful people had a clarity of vision right out the gate… When the reality actually is that if you’re a strategic thinker and you kind of do a check-in frequently about where you’re at, and you adjust your sight… Again, I’ll lean on our good friend Bill Gates - he has a quote from early Microsoft, which is “One day Microsoft might be a large company. It might employ 30 people.” Bill Gates didn’t set out going “I’m going to dominate the entire industry.”

One other Microsoft story that a lot of people aren’t aware of is that their original internal motto was “We set the standard.” That was their view - anything that was gonna happen in computers, they wanted to at least be the one that’s setting the bar. And I think that was actually the signal really about the ambition. So ambition [unintelligible 00:51:21.08] but the other two kind of adjust based on the current situation.

All that is to say is that I have very large ambitions. Raygun is a part of that story for now. It may not be part of the story forever. It may still be a piece of the story.

I personally – you can probably piece together from some of the people I’ve referred to in here, like Warren Buffett… I’m a big believer in the power of SaaS businesses, and the idea of having multiple revenue streams, and things like that. So the potential to one day have a portfolio of companies that are all sort of acting in unison, or at least part of my “conglomerate”, if you will… That’s probably a little bit what I’m starting to map out. Don’t hold me to that - it might change over time - but that’s kind of what I’m thinking.

[52:14] The other thing - I know we talked about it before we actually jumped on here, but we haven’t discussed much… I’m down here in New Zealand, and one thing that’s going on here is our country is the largest exporters of agriculture. We make great meat, we have a lot of land, low population density… Software and technology is our number four export at the moment for the country, and I am a huge, huge believer that software should be New Zealand’s number one export. As you noted as well, New Zealand is tucked right down the bottom of the South Pacific. We are in a world where climate change is a thing. The miles to market is hugely problematic for us. Why would we focus on industries that play to our natural disadvantages?

Compare that to, say, my business, where it’s like “Well, we can host our data anywhere.” Time to market is measured in milliseconds. There’s very little in the way of a Carbon footprint of trying to get something from New Zealand to the world if it’s on the internet… And you even asked before we started about the challenges of getting to market. Well, thanks to the internet, it would be more work to not be an international player. A lot of people don’t know we’re a New Zealand business, to be honest. We don’t flaunt it in any major way… But this actually plugs a little bit into my own purpose, which is I would like to be a significant contributor to getting the IT exports from New Zealand to the number one spot, and being a significant component of that export revenue for New Zealand.

Now, that might not sound like the ambition of an Elon Musk or a Bill Gates or anything like that, but it’s kind of where my next steps lie… Because if I can achieve that, then the question becomes the next size of the game, like how do you take it from there.

Adam Stacoviak: So the plan is to potentially revenue, or for sure…?

Adam Stacoviak: That’s right. You piqued my interest with leveraging SLOs as a product thing. Like, how do you have product tiers. And that’s really a Chief Revenue Officer’s opportunity, potentially. So how do you market to a CRO, for example, with SLOs? “Well, hey, adopt SLOs, and maybe you have healthier teams, or healthier products.” If you have tiers, one that’s more expensive, more premium, and you can quantify the sell, for a lack of better terms, with an SLO.” That to me simplifies things. So your customer there is like product owners, Chief Revenue Officers, potentially marketers… So you’re not really marketing to, say, director of engineering, in that case, who probably cares a lot about SLOs…

Amal Hussein: Yeah. And then it’s also just good to point out that WebKit is an open source projects, it has contributors from outside of Apple… People at Intel, Sony… All kinds of places. Google… They’re all kind of contributing to WebKit. So like you pointed out, Alex, if I go ahead and add service workers support to make everything – you know, it being there doesn’t mean it’s gonna get turned on and enabled, right? So that’s the key point there; thanks for making that.

To kind of go back to the wider problem of why you all started this work - essentially, Apple doesn’t seem to have an incentive to really enable browser choice, but what’s driving that? What’s the dark horse here that’s causing this tension in browser land for Apple? What’s the other revenue source for them potentially that’s impacting support for the web?

Adam Stacoviak: That means revenue was in place potentially… So you really were able to, I guess, navigate this acquisition, this acquihire, knowing that – I’m sure you got some sort of payout yourself as part of it, but then also the next thing in, to continue to be able to invest in Elixir - I can imagine how that would make you feel pretty secure about your next steps.

Adam Stacoviak: Brian, thanks for your time, man. We appreciate you being a man on this mission, and a team on this mission to help a better web be safer, more secure, and then potentially publishers like us finding new ways to generate sustainable revenue from the attention our users and/or listeners desire to give us in ways that just make sense for the future and the way that web will work, so… Thanks so much for your hard work and for sharing your time with us today.

James Long: Okay, sure. Yeah, Actual is a product that I built, it as a personal finance manager… Just the typical things where you import or add your transactions, and then it provides a way to budget and track your finances. The original goal was to be just a super-powerful tool built for personal finance geeks, in a way, or people who just like to manage their finances in a more detailed way. The primary method of budgeting right now is something called zero-based budgeting, which is a pretty detailed way to budget, which is where you actually track things down to every single dollar, and then if you overspend in one category, you have to sort of make up for it in the next month.

And so the overarching goal was not only to be – because users are very detailed people, typically they also want powerful reporting, and ways to get insights from their data. And so the original goal was to have this whole thing, and the other big difference here is that it’s actually a local-first app, so it’s an app that you can run on your computer, all of the data is local… The big benefit for that was, in theory, I should be able to build a whole reporting mechanism that you can actually do custom queries and just dig into your data a whole lot more than you typically could on other apps, because other apps are just more constrained by the server, or they’re running all of their clients queries on the server, and so you can’t do certain things.

So in theory, if you wanted to, you could write a custom SQL query, which sounds super-geeky, and it is super-geeky, but if you can do that, then you can build up a higher level of things that aren’t as complex… But it was a cool idea from the start to be “Hey, what if I could actually just write SQL queries against my personal finances?” And you can still technically do that today; it was a lot more work than I imagined, and so I never really got to the point where I was able to figure out the user experience of how to do that… It is still a potential avenue. So I never fulfilled that vision quite as much as I wanted to, but that was kind of the original vision.

I started hacking on it just for me probably around 2016. I was using it in a very limited way for a couple years, and then as I built it up, I sort of got to a point where it was “Hey, I’ve always wanted to launch a product. I have this thing, I might as well use this as the thing that I experience a launch.” And so I launched it I think in January, I believe it was 2019, on Product Hunt. It got to number four of the day, it got a decent amount of users there, interest. I think I got 30 users, and it was very bare bones at that point. And then over the years, I gradually gained a couple hundred more users, and over time, up until the open source, I was at a point where I had a small, but decent income stream.

Adam Stacoviak: And what you’re saying, Shay, is in retrospect things were different then. Maybe a license change was not the right potential way, which - obviously we get to reverse rug pulls. We’re back here again discussing this. We’re trying to understand why it happened in the first place. Could it have been just simply a court ruling or a court dispute over trademark law, and a trademark misuse over a community-disruptive license change?

Beyang Liu: We can get into it… I don’t want to go down that rabbit hole just yet. But the point I want to get across here is that we both feel that this is a really cool thing to be working in. And that’s one of the things that we chose this path as the professional path that we want to pursue.

The flip side of that was our experience at Palantir showed us that the pain that we felt in trying to practice this craft in a professional setting is felt across the entire industry, and it gets exponentially more critical the more impactful your software is. Because the more impact your software is driving, the more users and revenue it has, or it’s generating, and the messier the codebase is. So it was kind of the marriage of these two things. It was personally fulfilling to be thinking about advancing the state of this craft that you feel a deep personal connection to, and then knowing that it’s tied to just this huge amount of potential economic impact.

And so there, our thinking was like with the technology that we have today, if we focus on the fundamentals, building core technical capabilities, and then rolling those into delightful product experiences, there will be a huge company here that we could spend the rest of our lives working on.

Jerod Santo: I’m funding Ladybird because I can’t fund Firefox

Jack Kelly, in light of last week’s announcement of the Ladybird Browser Initiative:

Chrome is eating the web. I have wanted to help fund a serious alternative browser for quite some time, and while Firefox remains the largest potential alternative, Mozilla has never let me. Since I can’t fund Firefox, I’m going to show there’s money in user-funded web browsers by funding Ladybird instead. You should too.

If you’re curious why Jack can’t fund Firefox, TIL they won’t let you?!

Despite desperately trying to find more revenue sources, Mozilla Corporation stubbornly refuses to just let users fund Firefox. Mozilla Foundation even has a specific donation form for Thunderbird (Mozilla’s mail client), but not Firefox. I’m sure they could have found some way of making it work with their corporate structure, and it baffles me that they haven’t.

Adam & I discussed the Ladybird news on last week’s Friends and we’re hoping to get Andreas back on the show for an even deeper-dive…

Bryan Cantrill: There you go. And we’ll go there. But there is a line that I do love in Halt and Catch Fire, which is “We’re not the thing. We’re the thing that gets us to the thing.” And to me what that means is computing is a tool for humanity. And it’s a tool to allow people to do extraordinary things. And I just feel really strongly that the meaning of being in computing infrastructure is to unlock the potential that people can go create for themselves. And that necessitates a relationship with customers that is based on trust. And you can’t have this transactional antagonistic relationship with your customers, because you lose the meaning. It’s like, no longer is it about “How can I use your thing to go create something larger than the two of us together?”, it’s about you trying to extract the most amount of licensing revenue from me, or whatever. And it’s just like “Nah. No, thank you.”

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?

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?

Scott Johnston: [14:25] Yeah, yeah. So a lot of pain on the frontend of that. So when we did the divestiture recapitalization, the pivot, we unfortunately cleaved off a whole set of commercial technology. The Docker Enterprise Data Center, Product Data Center and Production/Product - we unfortunately had to say goodbye to 360 employees. So we went from 420 employees down to 60. And that was incredibly painful. And we also – we sold off all the customers. So we had 600-some customers that had revenue associated with it, and all of that went to a buyer.

And so as painful as that was, it was intentional in the spirit of letting the company shed its past, and just simplify and focus on the needs of developers. Because as you know, there’s no such thing as one and done. You always have a customer you have to take care of, or a legacy code you have to maintain… And we just knew we couldn’t make forward progress if we brought all that along. So we had to say goodbye to all that.

And then we really got back to basics, Adam. We knew that with that type of severe pivot, that we had to take care of the people first, the employees first… And so we really made sure we communicated early and often with the remaining employees, we sat down and started rebuilding our culture… And we really thought about, “Okay, what is important for us as a team, as we go on this next chapter of the journey together, with the pain of the pivot kind of sharp in everyone’s memory?” And so the first virtue we came up with is like humility. We wanted to be able to acknowledge our mistakes, listen to our community, listen to each other, and really be honest with ourselves in terms of what we’re seeing.

The second though, maybe to your question, was developer obsession. And that second virtue started as customer obsession, and we said, “No, no, no, that’s not sharp enough.” And so within a month, we said, “It’s developer obsession.” And virtues, as with other values, other frameworks, other companies use, they’re designed such that executives, CEOs don’t have to be in the room for employees to have guideposts and guidance in terms of what direction. So I’ll be in the room, and employees will ask, “Well, is this developer obsession?” “Let’s talk through that. What does that mean in this decision, or this feature, or this trade-off that we’re trying to make?”

The third one is open collaboration, and fourth is bias for considered action. And then the bias for considered action is there because we were at 60 people again, and we had an opportunity to move quickly, to listen, and make decisions. And we wanted to take advantage of that small size.

And so that was the start of it… And then we also were very transparent and humble and vulnerable with the community, particularly the Docker captains, who are kind of our Uber community members… And we sat with them and said, “Okay, developer obsession, serving developers… As you touch with products, and as you work with the community, what are you hearing that needs to be addressed? What are you hearing that we need to focus on?” And so really - I mean, it sounds kind of obvious, Adam, but it took a lot of work, and focus, and saying no to potential distractions, to focus on these points… And thereafter kind of flowed the product roadmap, right? We’ve found ways in which we needed to smooth rough edges off the products, we found things we could do to improve the product experience, entirely new products… And then on the go-to-market side, we knew that developers don’t want to talk to salespeople, developers don’t want to have contracts, and paper going back and forth… And so we very much focused on a self-service, credit card-based bottoms up, where if they wanted more value than was in the free product, they could swipe a credit card for five bucks a seat a month, and if they wanted value for a team, which typically is like private repos and additional security management, they could swipe their credit card for $9 a seat a month.

[17:56] So hopefully you’re hearing an intentionality of both features that serve developers on their day to day, but also a go-to-market model that respected where they were, and gave them the freedom to make economic decisions on their own timeframe, was really the impetus and the way we kind of jumpstarted things three and a half years ago.

And maybe just to zoom back and share with you kind of where we are, that we’re holding both those true - both the monetization, as well as the community. Another stat is we have about 14 and a half registered developers. So the 20-some at the top of the funnel are anonymous, a subset of those registered with us, 14.5 million registered with us, about 1.1 million of those are subscribers, meaning paid seats across pro team and business, which means 13-some million are still using the free product, the free open source, which is entirely by design. It’s entirely like “Hey, have at it, have a great time. If you find there’s additional security management features that you find valuable, swipe a card and go.”

So I wandered a little bit there toward the end, Adam, but hopefully that shares with you kind of where we were three and a half years ago, and how we set about restarting this next chapter.

Adam Jacob: Well, but here’s the thing… So this is where we come back to the funnel. Now we’re back to the business. So - sure, maybe Amazon – but this is why it’s good business for Amazon, to launch your stuff as a service, instead of just compete with you directly. So you brilliantly elucidated why they would want to launch a Mongo service in the first place, right? But as soon as they do that, if the top of the funnel was fixed, if that created no more interest in your product than it did before, then you’d be right. But it doesn’t. Instead, it turns out that the single largest pool of software developers on the planet are the ones that use Amazon and AWS, or Azure, or Google. How many of those developers are using one of those platforms? And if your stuff is on all three of those platforms and it’s not on the others, how many eyeballs do you get that Cockroach doesn’t? The answer “A ton of eyeballs! So many eyeballs!”

So the size of that funnel, your possible monetization gets bigger, hugely bigger than it was before. And in that moment, your ability to capture that revenue - every single one of those cut-rate DocumentDB users is a potential lead that’s already using your product. So all you have to do is go find them and be like “Yo, did you see how much better our console is, how much better our operations stuff is? How you can get on a Zoom with a dude that wrote that indexing feature when it’s broken? I dare you to get that out of Amazon.” And the next thing you know, Citibank is like “You know, Atlas looks pretty good.”

Adam Jacob: Yeah, that’s good. But as soon as they do that, if the top of the funnel was fixed, if that created no more interest in your product than it did before, then you’d be right. But it doesn’t. Instead, it turns out that the single largest pool of software developers on the planet are the ones that use Amazon and AWS, or Azure, or Google. How many of those developers are using one of those platforms? And if your stuff is on all three of those platforms and it’s not on the others, how many eyeballs do you get that Cockroach doesn’t? And the answer is a TON of eyeballs! So many eyeballs!

So the size of that funnel, your possible monetization gets bigger, hugely bigger than it was before. And in that moment, your ability to capture that revenue - every single one of those cut-rate DocumentDB users is a potential lead that’s already using your product. So all you have to do is go find them and be like “Yo, did you see how much better our console is, how much better our operations stuff is? How you can get on a Zoom with the dude that wrote that indexing feature when it’s broken? I dare you to get that out of Amazon.” And the next thing you know Citibank is like “You know, Atlas looks pretty good”, you know?

Isaac Schlueter: So when we were doing our seed round we kind of just accepted that “Yeah, npm is a Node thing. It’d be great to provide some features for front-end JavaScript, but first we’ve gotta not be on fire. And there’s some pretty clear enterprise opportunities we can go after; a lot of big companies using Node, depending on it, so let’s go there.” And some of the pushback that we got was, like I mentioned, you don’t have the Node team on your team, so how are you gonna succeed as a Node thing?

Some other folks just kind of doubted the – I wish I’d taken notes, I wish I’d kept better receipts, but there were a couple VC’s who said “Node is never gonna be a really big thing in the enterprise” or “JavaScript is never gonna take the place of something like Java or Go.” And I think that Node itself as a server-side language platform has really found its niche, which is as a thing for web developers. It’s a thing that you use to run tooling, it’s mostly to run tooling, but also a lot of times build out kind of the last server-side layer, like the view layer of your web application… And you know, it’s good for other things too, but that’s kind of where it shines. That’s where something like Rust or Go don’t do as well as Node.

The other thing - “Well, we don’t know how big JavaScript is.” That’s just not a bit of pushback we get now. A half or more of all developers are using JavaScript on a regular basis; every single company is using npm, every single web app is using npm… That’s not the pushback we get now. Now it’s more like, “Well, can you turn this into a commercial success?” And as you get later and later in the stages of a company, you become less judged based on the potential and more judged based on your actual results. They don’t wanna see a big community, they wanna see a product that’s actually in the market, that is getting really good buying signals and producing a lot of revenue.

Joseph Jacks: Yeah, that is a really good question. I think there’s lots of ways to answer that question, but one potential way of looking at it is 2018 is a really huge year for commercial open source. I guess open source software overall is about 20-25 years old, and just in the last five(ish) years we’ve seen a huge amount of growth in this kind of emerging category of companies that you could classify as commercial open source software companies. Your mention of the index that we’ve been managing/maintaining for several years kind of indicates that obviously there’s quite a lot of activity in companies that have formed, that have reached huge levels of scale.

100 million in revenue or 25 million revenue/quarter was chosen as a metric just based on that revenue number being pretty relevant to companies that can kind of go public, or have large outcomes.

So “Why now?” I think is really a function of 2018. I’m actually just at the GitHub Universe event right now, so GitHub’s a good one to mention, but… So far, in aggregate, we’ve had over 30 billion dollars in either IPOs, private equity events, or mergers and acquisitions of commercial open source software companies. Most of those are companies that have been in existence for several years, at least 5, 6 or 7 years, in some cases 10 years… So it takes a sort of similar or same amount of time roughly for commercial open source software companies. I believe it’s possible to do this in a shorter period, but roughly between 8 to 10 years to become large, sustainable, public, IPO-able companies…

[08:11] And I think 2018 has been sort of this tipping point year for public markets, and then seeing lots of these large outcomes occur, where most of these companies are venture-funded. But as we’ve talked about in the opening, we haven’t really seen a focused firm I think mostly because there just hasn’t been the synthesis of appreciating these companies are fundamentally different as compared to proprietary, closed source enterprise software companies or just software companies in general.

We very strongly believe that commercial open source software companies are fundamentally different functionally in almost every way, as compared to proprietary closed source software companies. And that’s kind of another motivator for starting OSS Capital - the founders need to be served differently, the support structure is very different along lots of different dimensions, and the companies kind of just grow and evolve and go to market and build products for businesses also quite differently.

But just to answer your question, I think 2018 has been a really remarkable year for large open source outcomes, obviously GitHub being bought by Microsoft, MuleSoft having their second exit to SalesForce after IPO-ing last year, Magento getting acquired by Adobe, SUSE getting acquired by a private equity firm, Elastic’s IPO, CoreOS getting acquired by Red Hat, Alfresco getting acquired by a private equity firm… We think there’s quite a lot of IPO dominoes (if you will) that are gonna fall over the next several months even. We think there’s probably a few more between now and the end of the year… So that’s one of the other factors of 2018.

I guess maybe one last comment - in 2018 almost on a monthly basis, like January, February, March, April, May, every single month we’ve actually seen a large commercial open source outcome… Every single month. So it’s been pretty amazing so far, as a year.

Quincy Larson: Yeah, that’s an excellent question. So the actual staff is pretty small when you compare it to all the open source contributors. But we do have kind of a core team, if you will, of people who we’ve brought on, that were open source contributors that we were able to budget, bringing them on to work full-time. So generally, the way this works is I’ll hop on a call with them, they’ll be like a prolific, long-term contributor, and I’ll learn more about them. And if they seem like they’re a good fit, and they seem like the person who would responsibly be able to manage themselves… Because I don’t manage people. We don’t have any sort of management hierarchy. I definitely admire what militaries and giant corporations can do in terms of creating hierarchies, that get things done, and stuff like that… But that’s not for us. We’re a remote distributed team.

So I get on a call basically, and I talk to people, and I’m like “Hey, if you could continue to contribute – right now you’re contributing five hours a week, six hours a week. You’re getting so much done with this limited amount of time. What if you could contribute 40 hours a week?” And if they’re like “Oh, well, then I’d focus on this, and I’d do this, and this area really needs improvement”, or “I’d to go deeper into this and potentially incorporate that into the curriculum”, then I’m like “Awesome. Well, let’s bring you on and you can do that.”

And so over time, we’ve – I think we have 35 people on the team, in 21 different countries. So we’re an extremely international – we’ve never had an office. I have never even gotten a WeWork type thing. Like, I’ve always just worked out of my home, first my closet, and now we moved from San Francisco to Texas and I have a proper house that has a yard that I mow every week, and things like that. So I just work out of one of the rooms in the house… So we fly these 35 people from around the world to Texas, here in Plano, Texas, which is a good school district. That’s why we moved here; it’s a really good public school. And we just hang out, and we go to different public libraries. I call it the library tour, and we go to several different – like the Plano Library, the Coppell Library, the Lewisville Library… And we go into all these different libraries for about two or three hours, and we [unintelligible 00:14:17.27] the sessions.

[00:14:19.26] And then we go and hang out at the National Video Game Museum, which is this amazing video game museum, if you’re ever in Plano… We go play – they have a perfectly restored 1980s style video arcade, and stuff inside it, among other things.

So if you look at the people on the team, it very much mirrors the kind of people that are contributing to the open source effort. And it’s not just the open source effort on GitHub; people who are writing books and articles that we’re publishing through freeCodeCamp Press, freeCodeCamp.org/news, people who are publishing video courses on the freeCodeCamp YouTube channel… Yeah, just chill human beings that feel like they can contribute to the global knowledge base, essentially. The way that people acquire skills.

So that’s a very long-winded answer, but almost everybody on the team is a developer, who has also had some classroom teaching experience usually… And everybody’s a jack of all trades. I can give you a lot of insight over the years in how the team has changed in terms of priorities and configuration, but it’s basically been the same people that we brought on four or five years ago; we had the budget to start bringing more people on, because we got our charity tax-exempt status… And then we started getting donations from the community, and those donations have gradually grown. We’ve also gotten some ad revenue from YouTube, and display ads… If you go to the freeCodeCamp publication, you might see ads for upcoming conferences, or books, and things like that… And that has helped us kind of expand and sustain ourselves as a charity. So the team has not grown a lot. The team was – it basically kind of stabilized at around 35 people.

Adam Stacoviak: What bothers me in the marketplace is when an up-and-coming, maybe even a company that’s using venture capital in a way that has sustainability behind it cannot generate revenue, or is completely wiped clean because a behemoth, of the FAANGs, potentially, decides to make their thing free. And I think just maybe in the case of our friends at Zulip, you’ve got Teams, that is generally given away. It’s paid, there’s a paid version of it…

[01:32:11.29] There’s a lot of it where they’re able to give away so much for free, because they’re so big, and you have a hard time competing. That’s another challenge, too. I’m not against – but again, in the world of commerce, you kind of have to be flexible, you know? But I agree with you on there’s healthy ways to take venture capital, and there’s unhealthy ways to take venture capital. And there’s things that unhealthy venture capital does to you as a leader of your product after you take the money; things that get forced on you. That’s my simple retort. Okay.

Ryan Worl: That’s a really good question, and to take a step back from that question for a second, talking about the commercial open source stuff… This is obviously a little bit inside baseball, but as a part of going through that decision process, we talked to the founders of a lot of commercial open source companies, and we asked them “Let’s say you were starting our company today. What would you do?” And without hesitation, the answer we got was “I would not start it as a commercial open source company today.”

[01:07:53.19] And there are a lot of different reasons that they gave for that, and I can’t really give some of those reasons without potentially identifying who those people are, and I don’t want to do that… But the challenges of an commercial open source company today, with the – it’s not even just the hyperscaler cloud providers anymore taking your stuff and running it. That’s obviously a concern, but you can get around that with – like, the AGPL does a decent job of preventing some flavors of that.

The other issue is just like the competition within the category that they’re building their product in is extremely high, and having your source code out there in the wild, and letting everybody know your secrets, essentially, about how you made your product better - you lose a lot of the juice behind why you have these huge staffs of developers working on interesting things. It’s not to say you can’t protect that other ways either, with software patents and stuff like that, but people don’t – the appetite for software patents… It would do a lot of brand reputation, I think, if these commercial open source companies created a bunch of software patents and started enforcing them against each other, for example. It’s a very challenging situation today.

A lot of the companies that you might view as successful commercial open source projects, they might be successful in the iteration that they exist in today, or yesterday in the case of all these real licenses, where they have good adoption in the developer community, and they might have good success in the VC-funded startup segment of the world… But there is an inevitable push to go upmarket, and to go after larger and larger customers, because it’s effectively the only way to support growth. The growth of what you can achieve within the small – if your customers are all small startups, even medium-sized startups, and developers playing around in their personal capacity or stuff like that, the revenue opportunity is just really small, unfortunately, for a lot of these businesses. It’s much easier to sell a million dollar a year contract to an enterprise than it is to get a million dollars of revenue out of a bunch of small and medium-sized businesses.

So the temptation when the growth starts to slow down is “I need to go do that now.” Like, that’s the first thing your investors are going to tell you, is you need to go upmarket and get enterprise customers. If the product that you’re selling them is support or a couple of features on top of an open source project, your ability to exert pricing pressure on that enterprise buyer, to get them to pay a higher price, or to get them to pay at all in the case of a lot of these open source projects, where they spent so much time making it good that the enterprise can just hire one person to maintain it internally, and just move on with their life and run the open source forever, and maybe pay you a peanuts support contract, essentially; not actually enough to support the business. It’s just really hard.

I completely understand where you’re coming from, and it might’ve felt as if these companies were successful from the outside, and some of them definitely were… But just, there is that inevitable pressure to keep the growth rate up, and the only way to do that is to go upmarket. And when you’re going upmarket, you need to provide something that looks valuable. And if your project is open source and the alternative is hiring a developer to maintain it internally, you kind of have a cap on how much you can charge.

It’s the same thing if you’re offering a cloud version of an open source project, for example. The premium someone will pay for your cloud version - it may be lower than you expect if they can self-host, because they’re always looking at that… They’re looking at both sides of the coin. “How much will it cost me to self-host this, versus how much does it cost to use your cloud-hosted version?” And that calculus does not always come out in your favor as a vendor. You may have to charge significantly more to make the numbers work on your side than what they think they can run it for internally. It’s really challenging stuff.

[01:12:18.08] We wanted to provide the best product possible, with the best product experience possible, and we didn’t feel like the shape of an open source commercial company was the right way to do it without having a lot of these distractions about the things that I’m talking about right now come up along the way. And we didn’t feel like it would be right to do that, the bait and switch thing that people are doing these days. We wanted to be honest, basically, from day one.

Demetrios Brinkmann: Yeah, I mean, it is wild that you can go so far… I talk to startups almost every day in my day job, which is not the MLOps community… And they have real revenue, and a lot of them, I’m always asking them “Oh, so how are you doing this behind the scenes?” and a lot of them aren’t even using vector databases. But they’re like cashing in, and they have a product that’s working, and it’s working at scale… And so there is this misconception I think sometimes that we need all the bells and whistles, and this stack that I just was talking about, and saying that the vector databases are the champions - potentially, for your use case… Do you really need it? Because it does add that complexity. So going back to the tried and true principle - just keep it simple.

Break: [16:19]

Jerod Santo: Yeah. So in summary, they were responding… This is on a thread about ChatGPT, and they say – this is a Googler, and they say “It’s one thing to put up a demo that interested nerds can play with, but it’s quite another thing to try to integrate it deeply in a system that serves billions of requests a day, when you take into account serving costs, added latency, and the fact that average revenue on something like a Google search is close to infinitesimal (which is the word I can’t say out loud) already. I think I remember the presenter saying something like they’d want to reduce the cost by at least 10 times before it could be feasible to integrate models like this in products like Google search. A 10x or even 100x improvement is obviously an attainable target in the next few years, so I think technology like this is coming in the next few years.”

So that’s one insider’s take on where Google stands. Obviously, Google has tons of resources dedicated to these areas of expertise, right? It’s not like Google’s asleep at the wheel, and is going to completely have their lunch eaten by OpenAI. But right now, there’s a lot of people who are training new habits, right? They’re like, “I’m not gonna use Google anymore. I’m gonna start using OpenAI.” I think it’s something on the order of one million users in their first few days have signed up… How long can Google potentially bleed people before it becomes an actual problem? I don’t know. I don’t know the answer to these things.

Ian Miell: [35:53] Well, yes, this opaqueness is absolutely part of the problem. I think what I was talking about earlier was more like structural stuff. But if we’re talking from a point of view of an engineer - when I was working for very large organizations, I had the same question, “How can we measure the value we’re generating for the business and then justify more revenue as a result?” And they got really political and complicated, because the best measure we came out with was the number of teams in production, or using the platform. And there were different measures: production, testing, dev etc. And we took those numbers, but we didn’t even really know where to take them, because as I say, we had these yearly budget cycles, which were way up the chain, beyond what we could understand. We had no idea if this information was going up to that part.

So even that structure wasn’t set up for people to think about things in terms of “Well, I’m delivering this value to the business, and therefore I can justify this funding for future growth.” It just hadn’t been joined up.

When you’re a company of a certain size - and being opaque is fine; most people don’t have the time, or energy, or inclination to think about these things. When those companies want to change, they just say to themselves “Oh, we’ll just be Agile now. We’ll put some posters up, and we’ll have some courses, and we’ll use a few new words to describe small things, and we’re okay. We’re Agile now.” And my feedback to companies who were trying to do that is always “You have to think deeper than that.” And usually, we stop at culture. But I’m starting to think that’s not enough, because like I said, okay, our culture is broken. Now what do we do? You can’t just magic up a culture. It’s very vague.

In fact, I read a blog piece called “Five things I did to change an IT team’s culture.” I was given the task of managing an IT team where the director had left… I did five specific things to change the team’s culture, from firing someone, to getting my hands dirty on the floor and looking at the pipes of work that were coming in… Because I wanted to say – you can’t just say culture is a problem and then walk away. “Here’s my invoice. Culture’s a problem.” You’ve gotta actually suggest something. And so at the time, the things I was suggesting were tough things, like firing people, and getting your hands dirty on the floor to see what’s happening. Like the goal in the book we were talking about before the podcast; one of the key things in that book was that the manager never actually went to the floor until he had to. So he had all these reports about the machines in the factory, and then he went on the floor and he’s like “Hang on a sec, that doesn’t really match. The reality on the floor is that we have these two machines which are sitting idle. Why are they sitting idle?” “Oh, because you told us we should use the new machines, which are less productive.” Like, “No, switch the old machines on. We need to deliver.”

Going to the floor is a huge thing. That’s practical thinking, too. But another practical thing that I’m thinking about now is this whole money flows things. And it’s not an easy sell, because “Why is this guy who knows about Kubernetes suddenly telling me about cap ex, and op ex, and money flows? This is not what I hired him for.” So you kind of have to be patient. But eventually, you get there with them, and they can start to see that this is a problem potentially. But I think it’s a very underexplored area, and I’m super interested.

Craig Wiley: Yeah, this is one of these questions that gets harder every month for me to answer. If you had asked me this question a couple of years ago, I would have said “Oh, people build great recommendation systems, and people build great forecasts, or great vision models”, or something like that. And the kind of application of models is still relatively narrow, but today, if I look at a company like Unity - Unity uses Google Cloud and TensorFlow Enterprise to quickly test, build and scale out ML models at a massive scale, allowing them to serve the most relevant ads and drive revenue for game developers.

[20:13] When we turn on the game on our phone or light up the most recent game that we’re excited about, we don’t think about the fact that there is tremendous technology going on behind the scenes to target those ads, to pay for that game, so that it can continue to be free for us. This is something that is very important to Unity and its developers and customers, and they have found tremendous success using TensorFlow, using TensorFlow Enterprise and using Google Cloud to be able to scale this problem that requires them to kick off hundreds, thousands or tens of thousands of models, in an effort to highly target their advertising, and what have you. I’d take that as one example.

On the other end, I can call at a company like GM Cruise. GM Cruise is a strong leader in autonomous vehicles, and is a TensorFlow Enterprise customer. The deep collaborations between Google Cloud, TensorFlow and GM Cruise have given us the ability to reduce their training times from – I think when they arrived it was something along the order of four days, and now it’s less than a day. So when you’re able to achieve a 4x reduction in cycle time, now all of a sudden they can potentially move four times faster in trying to get to the solution to their problem.

As the father of a young child, I have to say, the idea that he’ll never drive a car is a very exciting idea to me… So I’m more than willing to help all of these folks get as far down that path as they can, as quickly as possible.

David Cramer: I want to replace New Relic in the industry, and we’re not gonna do that with where we are today… Certainly not quickly. And that’s a much bigger ambition. And maybe that’s not actually replace New Relic, but I wanna tackle a lot of the problem that New Relic has owned for a very long time, in a very specific market, very differently… And the challenges of that - it’s potentially a lot of stuff to build, it’s a lot of stuff to support; it’s much bigger than this error tracking component that Sentry has today.

What venture capital is honestly for - it’s purely to allow you to spend a lot of money to make big bets, and those big bets are entirely “Maybe grow faster”, right? A very common reason to raise money is because you’re an enterprise product or something, and you have a sales force, and it takes about a year or maybe two years to get the revenue back from that sale, but you can sort of predictably do that. So you’re gonna go raise a ton of money, hire a ton of salespeople, you’re gonna lose a lot of money for the next 1-2 years, but then after that, you’re gonna see a drastic increase in cashflow. That’s not us, to be clear, but we would like to drastically expand our engineering presence and our product line. Doing that is either going to take us until I’m old and grey, or it’s gonna take a lot more people.

If we raise money again, it will certainly be to go for a much bigger target, is how I would talk about it. Not that it’s a bigger target than what we already have internally, but publicly it’s a bigger target than what it looks like we might have today.

Julia Grace: Yeah, absolutely. So we have over nine million weekly active users and over six million daily active users. There’s over two million paid users. What I think is super-cool… So of those paid users, the two million paid, 43% of Fortune 100 companies use Slack. So a lot of the companies that you think about - credit cards, Capital One - they’re running their business on Slack. Super-cool. TicketMaster, if you’re buying tickets on Slack. But also a lot of fascinating and exciting, like NASA - I have talked about that before - doing really cool stuff on top of Slack. And of course, there’s a lot of technology companies - the Paypals, the LinkedIns, Spotify, Pinterest… They’re all running their businesses on Slack.

[59:46] And not only do we have rapidly growing numbers of users, but I think the demands on the service in terms of “We can never go down” are really high. If you think about consumer internet businesses, for example Twitter (we talked about them earlier), or Facebook - when those services go down, of course that really sucks, and there’s clearly a loss for those companies in ad revenue. When Slack goes down, the people at Capital One can’t do their work, and that’s terrible. If TicketMaster goes down, then potentially they can’t process orders. So the reliability and scalability constraints are real, and I think that’s really exciting, because I think it means that we’ve built an incredible product, that people love and that people rely on every day to do their job, and ideally, we’re in the background… Like, we just work.

Segueing into – you had asked a few other numbers… When I first started using Slack, before I ever thought about working at the company, I had started a company and I installed all the engineering integrations on top of Slack. So I did GitHub, continuous integration, PagerDuty, we also use Zendesk for our customer support tickets… So we have a really active and vibrant developer community that builds on top of the APIs, so we’ve got something like 1,000 apps in our app directory. The app directory was actually the first big launch that I was part of at Slack, which was super cool, because you had to go search for apps, and that’s how in my early Slack days I found apps - I would do a google search; now you can search in the app directory.

This is just so cool, because I’ve built apps before I even joined the company; I built integrations, so I could send data, pipe data from our systems into Slack, so that if something was going wrong, I hooked up our error servers to Slack so that I could see the channel light up, versus waiting for the email or waiting for the page, because I was in Slack all the time…

There’s something like 155,000 of these weekly active developers building on Slack. So that’s a lot of people building on Slack, and I think that’s so cool, because they are building things that we never could have imagined, in a wonderful way.