 I'm Brandon Ramirez and I'm the research lead at The Graph. Today I'm going to be talking about ending land ops lessings in tech. One thing that I find when I'm meeting people at these conferences is that everyone kind of has their own vision for what makes blockchain decentralization exciting. And for me what really counts for my imagination for the first time was this quote from the original theory.org website. This idea of building unstoppable applications. And it's fascinating to me because this is not something that we're used to thinking about in the real world, right? This is kind of the stuff of fantasy, right? Like some mythical sword that you read about that lasts forever. But in the physical world we deal with the second law of thermodynamics that entropy is always decreasing and we kind of come to expect that physical products will fail and degrade over time. But it actually puts you that we do have some products today that last forever. And specifically they're information products. So things like books, music, movies and not under physical form, right? Because pages on the book will degrade but in their pure essence these things are just information. Information doesn't have any intrinsic expiration date, right? Like maybe the hard drive that something's on will fail but you know the information itself just requires a medium to be played through. But really it should last forever. Now another type of information product that we have that we don't come to expect this property from the software but software really is at its essence still just information. So why is it that the ops that we love and the ops that we use all the time kind of just come to accept that these things fail, right? When these things are at their core just information. And I would contend that software is just like music except that the boombox that you play it through is just way more complex. And we haven't figured out how to give it the same properties. And so I think you can trace this all the way back to the Great Depression. This is when the idea of planned ops lessons was first produced. And at the time it was seen as this like breakthrough and like economic thinking, right? People were kind of desperate. There was a sense that the economy was failing because there wasn't enough purchasing power in consumer scans. This is at the same time the John Maynard Keynes said that it would be better to bury a bunch of money in glass jars to drive employment than do nothing. I think this idea is actually stuck with us and to become part of the zeitgeist of what we expect from consumer products over the last century. So shortly after those ideas were put to the test a cartel of light bulb manufacturers were realizing that the light bulbs they were producing were lasting way too long. And so they formed a cartel called the Phoebus Cartel where they decided to collectively limit the amount of hours that any given light bulb would be designed to last. So on the right, this is actually a picture of what's called the Centennial light bulb. This is a light bulb built before that era that's still burning in a fire station in Livermore, California today. So it kind of gives you a sense of what these products could have been like. There's a bunch of forms of planelapsolescence. Today we mainly focus on contrived durability. I think this is the one that we tend to identify with the most with that term. But it's not one that we tend to identify with software products. So let me explain what I mean when I say contrived durability for software. And specifically it's that the apps that we use weren't designed to outlive the companies that built them. And this wouldn't have been a problem maybe 100 years ago. You know when the average lifespan of a company was closer to 60 years, at least on the S&P. You know today it's closer to 20 years, it's projected to keep decreasing. So we need to accept that this reality that companies are going to last less and less time. And we need to start thinking about what that means for the products that they create. So there's a lot of reasons for this. These are just like a couple of ones that you see a lot. Which is that for a long time the Playbook is kind of a go-better at home for especially consumer applications. Success stories like Instagram or Snapchat didn't even start thinking about monetization until it gears into their growth plan. And those are kind of the success stories, but many companies fall far short of that. And they get maybe tens of thousands of users and they decide that's not enough scale to drive a business off of them. And so they shut down or they become strategic oppositions for like large deployments that then shut them down or try to migrate their users onto other products. So I'm going to give you that this is a form of planned loss of lessons because these businesses are basically planning for this world where only in the case of massive success will their users be taken care of rather than planning for their products to outlive the companies themselves. So there's a lot of reasons that we should care about this. And so I'd like to build some empathy for the people that are affected by this. Which I would contend is everyone in this room. So I have a few teammates here. Just this year, a couple of products that we used and relied upon were shut down against our will. One of them was our project management app. We had spent hundreds of hours tweaking it, tuning it, putting our data into it. We were happy to pay for it and that was shut down. You're talking thousands and thousands of dollars for the engineer's time that has kind of stolen from us against our will. You can go to this website that I like, killedbygoogle.com and you can see like 150 plus projects that they've killed over the years. And so I just want you to think about the users that kind of gave those products a shot. Spent their time getting excited about it, playing with it. And then later also punished for taking that chance. And think about what that does to user psychology. We want startups to be successful. But if we train users that taking a risk on a new startup project is a fool's errand, then we're going to see a lot less innovation and adoption of new projects. Another dimension to this is technological stagnation. So this is something that Peter Field talks about a lot. He says that we have a lot of innovation in the world of bits, but not atoms. Another key one of this is that we're redoing the same work over and over again. So if we go back to that list that I've shown before, one of these products, one of the left that's highlighted is Mailbox. It was this kind of innovative mail app that came up with this nice set of UX features. It was acquired by Thoughtbox and shut down. Then Inbox came around later. Basically it just copied the exact same set of features. And then so I switched to that and then that was shut down. I'm sure in a year or two we're going to find another startup that says, hey, you know, those two apps are really great, but let's rebuild these same features. I'm going to argue that in 10 years from now we're still talking about the latest calendar app, to-do list app, mail app, and we haven't done our job correctly. So a common denominator that you'll see with a lot of products that are designed to be obsolete is what I call bundling. It's really bundling of parts that have different levels of durability properties. So it's very common to see parts that have really strong durability properties, the greatest being information, which is infinitely durable, with parts that are more brittle. So you see this across the board when it comes to planned ops lessons. So you see physical components, like LED lights for example. There was a study that showed that for outdoor LED bulbs in only 10% of catastrophic failures was the LED bulb itself responsible. And then the other 90%, it was either the power supply or some other parts that were kind of bundled into the LED bulb. But they don't design these things to be swapped out. You know, autonomically, so we're just throwing working LED bulbs in the trash and buying new ones every so often. You see this with the latest addition of MacBook Pros, right? People were very very upset that they started to include the RAM battery onto the motherboard, meaning that if one of these parts fails, now you're swapping out your entire motherboard instead of replacing one of these things piecemeal. We kind of talked already about information in physical media, right? So if we were still in the world where we were printing all our books on, you know, paper and binding, then we would still be in a world where books were designed to fail, right? Less intuitive is information and resources. So a lot of people don't realize, we don't think about what happens when we navigate to a web page. You know, we put the URL in the browser, text and book deal. What we're doing is it's mapping to an IP address through DNS. So like if you're going to like Wikipedia, for example, it's going to go to your DNS provider, you're going to get the IP address. And what that IP address really represents is a physical location on the network. So if we're taking this thing, that's just information, Wikipedia, and we're tying it to this physical spot on the network. And if that location fails, then the information is gone. We see that all the time, by the way, it's called link rot, if you want to look it up. When we get into the Ronald X software, my web app becomes a little bit more complicated. So we're bundling software with the compute storage and other services required to make that software work. Not only that, we're also bundling those compute storage resources to specific business and economic entities through these kind of complex value chains. So if you're using many applications today, like Facebook, you might have the end user watching ads. That's the monetization strategy that kind of indirectly goes to Facebook. And then Facebook re-routes that value to its compute storage resources to keep that product or service running. And so we're in this world today where if the business stops working and stops paying for those resources, then everything stops working. And that's kind of what I want to focus on today. But to give you an analogy, this would be like if when you bought a television from a company, you were also buying the electricity to run that television from that company. Yes, that's kind of the core of the network today with software. So the answer to this I would argue is full stack decentralization. And this is what a lot of us in this space are working towards. And right now we're kind of just at the bottom of the stack. The networking layer of the stack is what we've come to think of as operating like a utility. Which is to say that the value flows that keep the network running aren't directly tied to the businesses that run the network. You pay for your internet service based on your meter usage of that service. And in the future that's how we think every part of the application stack should work. So I'm going to focus on two major parts of this. The one is data and storage which we saw in the previous slide. So instead of having webpages like Wikipedia tied to specific locations on the network like physical box, we can address these things by the information that they contain. So this is called content addressing. And then you can use that content address to go to a decentralized network of node operators and say hey, who has this piece of information? But no longer have we bundled the information with a specific location where you could find that information. With services it becomes a little bit more involved. Not only now do we want to decouple the information from the physical location, we also want to decouple the value flows. So what I'm showing in this diagram is that the developer who builds the application deploys the logic to this decentralized network of service providers. But then the value flows that keep that service running are direct between the end user and the network. So if this developer wants to walk away, wants to work on something else, goes out of business, this piece of infrastructure continues to operate. So this is how Ethereum works. The developer deploys a smart contract. But unless there's some weird logic built into it, you wouldn't expect it to stop working. Once that developer walks away, it becomes public infrastructure. This is how Layer 2 serves protocols like the graph or left peer work where for us you deploy a sub graph to the graph, which defines the query and indexing layer for your application. But once that's deployed, it sees value flows between the graph and the end user that keep that piece of infrastructure working. So the goal here is full stack decentralization. And this is what we're going to see over the next few years is that for every piece of the stack, we're going to see an equivalent service network either at the base layer or Layer 2, Layer 3 that kind of adopts these properties where really the only thing that's a product is this very top level thing, the front end application. And everything below that is kind of based on the metered usage of the end user. So this is part of a long run for some time. This isn't something that started with decentralization. So we've talked before about the physical media information. So that kind of started with the admin, digital computing. Ben Thompson runs this popular tech and business blog on Stratechery where he talks about aggregation theory and how the internet unbundled products from distribution channels and all the ways in which that changed our economy. And we can kind of think of this as being like the logical next step to aggregation theory. We're now not only unbundled products from distribution, but we've also unbundled information and software from the computing storage resources required to operate it. And the end game here is so in addition to getting unstoppable products, we move towards an economy that starts recognizing the time and data that we put into the products that we use has labor. So these things have value that we confer to it by virtue of the fact that we used it and so we shouldn't accept a role in which the businesses that we buy software from have power to steal that labor from us arbitrarily. I think this is going to lead to unlocking a lot of innovation and entrepreneurship not just because consumers will be more amenable to trying out new products with the knowledge that these things won't fail if the startup fails, but also because going back to that full stack slide, there's going to be so much more shared infrastructure for new developers and new businesses to build on. Like imagine if today a developer wanting to build an internet application also had to rewrite TCP and the rest of the network and stack. I think how much less innovation we would get, but that's what we're doing with the rest of the application stack today. The other thing that we're doing here is we're unbundling ideas and labor from corporations. So this is going to change the nature of work and so I think it's actually going to change work to be much more like the work that we see done on other information products. So the way movies get built, for example, how an idea you assemble a team, there's kind of many contractors or consultants involved and that team gets together to build this information product and then it's done. We wouldn't expect the team that built Jurassic Park, for example, to stick around for 20 years as a corporation that like monetizes and extracts value from Jurassic Park. Instead we have studios that come together and build many different information products. And the other thing I think we're going to see here is that as the amount of shared infrastructure grows we're going to see building software as much more of a small business activity. We're going to reduce the barrier to entry to building useful niche applications that maybe wouldn't have worked in a world where you had to rebuild an entire person's stack just to build something new and useful. And kind of as a closing thought, the reason I want to talk about this today is just that I think we tend to get caught up a lot on the idealism of Love 3 and I think that sometimes that creates a disconnect between people in this space that are really excited and like when we try to talk about Love 3 and blockchain, people are in the real world but I think this is something that's really tangible or concrete that we can all rally behind. Like everyone's used a product or spent time on a product that's failed and I think the solutions to this are becoming very real today and so this is something that I'd like to see spoken up more as part of the promise of blockchain and Love 3. Thank you.