Sessions is temporarily moving to YouTube, check out all our new videos here.

The Revolution Will Not Be Centralized

Edward Faulkner speaking at EmberFest in October, 2017
57Views
 
Great talks, fired to your inbox 👌
No junk, no spam, just great talks. Unsubscribe any time.

About this talk

Ember is steadily reducing the cost of shipping sophisticated applications. By making it easier to compose applications out of high-level, shared pieces, and deploy them on demand to commodity hosting, we've been sowing the seeds for a revolution in how software gets built and paid for. This is a talk about both the technical "how" -- including the latest work in the Cardstack project -- and the "why": our opportunity to grow an open, decentralized software ecosystem that can sustainably pay for open source while respecting user freedom.


Transcript


Okay, good morning Emberfest. Great to see you all here, I hope everybody is awake. Nobody drank too much last night 'cause you might not keep up. I'm gonna blow your minds, no, uh no. This talk is, this is not a talk that's about how to use Ember. We've got a lot of those good talks already. This is more a big picture talk about where, partly about building Ember, which is of course a concern for everybody in the community. We need everybody in the community helping build Ember. It's not something you can do with one small group of people, right, we all help build it. Even the most beginner people have ways to contribute 'cause we need all those voices. So this is a talk about building Ember and building more things on top of and underneath Ember, and I'm gonna that in a roundabout way toward my title here, which is talking about re-decentralizing the web, which is the kind of grand long-distance goal attached with a lot of stuff that inspires me about building open source software. So, inspirational talk. No hard quiz questions or anything like that. Okay, I'll ask you one quiz question. I hope this is an easy one. What is the Ember community's favourite adjective? Yes, ambitious, I think that's a pretty good one. It's much easier when you put the webpage on the screen. Without that, it's a little trickier. So yeah, so, what is ambitious? Depends on your contexts, alright. I have to sneak in a picture here of when you're one years old, climbing on the playground is ambitious. This is my son, Arthur, he's one. But then, when you're six years old, this is my son, Quint, hiking a mountain is ambitious, right? So, our ambition scales to our situation and our context, and in the same is true for Ember. I went on the Wayback Machine and I found the first EmberJS.com that it had, which was December 14, 2011. You could check it out at that link or go to the Wayback Machine to find it, and it's pretty interesting to read the whole page. It's just like one page and it's got everything from like, here's how the object model works, here's why you actually really might want to render in the browser, that was a pretty controversial thing at the time. So, when Ember was born, just the idea of making a desktop class application in the browser was ambitious, and we were extremely successful in that space, right. Just the folks in this room have among us very big apps with very big responsibilities and very complicated requirements, and Ember really excels at that use case. We heard some great examples from the folks at Netflix yesterday from Ophir and Lauren. I know we've got folks here from companies like Intercom, who are massively growing B2B products with complicated requirements. That's an area where our ambitions have been fulfilled. Ember's been good at those ones, and we've not stopped being ambitious, right. So, a lot of what we heard about yesterday was all the current work that's ongoing, and all the future direction that it's taking, and I'm not gonna go repeat all of that, all that good detail, but I do wanna look at kind of a high-level view of just how, like, are we still moving quickly? Are we still being ambitious? So this is a kinda activity graph for the Ember reefo, going all the way back to its first commits, right? And, it's pretty good, it's pretty steady, and measured in JavaScript years, it's really old, right. They're kinda like dog year, I guess. But of course, the Ember reefo by itself is not enough to really see the state of the project in the ecosystem, so let's start layering some things on. Ember data, very steady layer of additional progress, pretty constant added on top of Ember. We, at Ember CLI, we can see where its birth happens. We see massive bursts of activity, and we see very steady investment in Ember CLI. You'll notice as I'm stacking these, if you look at the very right edge of the graph, it's gonna keep going up 'cause we've had a big, recent burst of activity. Here, I'm gonna add the Glimmer-vm repo, and two interesting things here. One is that it goes back really far, right? You might think of Glimmer as a new thing, and it's certainly, as a marketing name, it's a little younger, and as a stand-alone thing, it's even younger, but it's a steady, continuous evolution, all the way back to the first commit, creating what was then called the html bars. As you look at that commit, it's like, got a rake file in it, and it doesn't look anything like what we'd use today, but it's been a steady, continuous evolution from them. Lastly, I'm gonna stick on topic, Glimmer-js, which is the repo that supports the stand-alone, very new kind of way to use Glimmer. Couple things I'll point out about that, it's just that it's small, it's incremental on top. If anybody was worried that all the new efforts going into Glimmer-js and not into Ember Core, it's pretty clearly not true, right? All these projects are very happily chugging along, and also very happily, we're actually at a, pretty close to one of the higher peaks right now. That line is the current month level for our kinda activity on these projects. There's only a few months ever that we're higher than this, so on a code-base that is old in JavaScript years, this is really good, this is signs of very robust health, and it's a sign that we are still being ambitious, right. So, we're being ambitious along what dimensions? So, certainly, these are all areas that are critically important to continue pushing on, and some of these folks have already went to a lot of detail on it in certain areas. I wanna focus first on, or most on, easier development. So, that's a big topic. Is there such a thing? Does it ever get easier? One way to say it is, no, it never actually does. This picture is kinda a funny one. I found it was an interesting one to throw in here. There's a famous essay called No Silver Bullet by Fred Brooks, written in 1986, you might be familiar with. It's pretty famous. In his book, this is the illustration he accompanies that with. So, when I pulled up that essay, when I was thinking about writing this talk, I saw this and I realised it's captioned The Werewolf of Eshenbach, Germany, and I could find nothing, I found no more about the details of this, I have no idea what the story is, so if anybody's from there and wants to tell us all, I would love to hear it later. In case the reference doesn't translate, No Silver Bullet is the idea that, a silver bullet was supposed to be the only thing powerful enough to defeat the werewolf. Alright, and when you say no silver bullet, you mean there's no perfect weapon. There's nothing that will perfectly slay the complexities of software. That was the point of his essay, and he makes a compelling argument that I still think holds true, even so much later. He talks about the distinction between accidental complexities and essential complexities. The accidental complexity is all the stuff that, if you had the most perfect tools, would never bother you. It's all the paper cuts that we all stumble over everyday. And that stuff, certainly sometimes feels like it's the thing that's hard about programming, especially when you're just getting started as a programmer. Sometimes, that's all you're fighting with. It's hard enough to make the tech setter do what you want, and to get the syntax right, and that feels like the hard part, but that stuff is all accidental complexities. There are things that in a perfect world, you wouldn't have to do. But, even as you solve all of those problems, and we, as a wider software engineering world, have gotten much better at solving those problems incrementally over time. What's left after you solve those problems is still very hard. It's the essential complexities of making software. Trying to solve problems in the abstract is just fundamentally hard. If you have a list of 30 requirements that you have to do, there's no getting the list any shorter than that. You gotta do those 30 things, and making software do those things is just, it's mental effort that actually doesn't get easier. You can try to measure, and folks have tried to measure, how much can you push through one programmer? How much can they do? And, there's limits. Until we get to the point where we can enhance ourselves with bionic implants in our brains, or until we invent the perfect general AI that puts us all out of work, this equation doesn't change very much. The way I like to think about it is that, you can really only fit so much complexity per brain, and if you would keep adding more brains, then your communication costs go up by N squared, because every pair of people need to communicate. So, there's just this fairly structural reason, you can only do it with so much complexity at one time. So, why are we even trying? We can't make programming easier. What do we do? Well, we can obviously keep producing the accidental complexities, and that helps quite a lot. But, there's a limit. You don't get 10x better. That was actually the kind of actual number he picked in the original essay. It's basically true, you can chip away at it. So instead, you have to find, there's one good workaround for the problem with solving accidental complexity, which really comes down to, the only software that's easy to write is software that's already written. It's reuse, and another way of saying that is having Higher-Level Abstractions. That shouldn't be too much news to an Ember audience. It's kind of the whole pitch of the framework, right? That we can give you a new higher-level of abstractions and you're always still, as a programmer, working at the limits of your complexity because if it was easy, you'd be done already, right? You're almost always at the limit of your complexity, but if the building blocks you're working with are much more powerful, then the problems you solve can be orders of magnitude bigger, even though you're dealing with a constant level of complexity in your mind, so. That is the whole trick, right? It is sharing higher-level abstractions. That's why we build frameworks. That's actually, what I think, the most important role of frameworks is, it's not just the fact that you get things done, but they let us actually discover what should be the next layer of good abstractions, because if you only solve your own problems by yourself, it's by definition not that abstract. You haven't really proved that you've solved many people's problems, so you need a community to really make abstractions. So, that's how you make programming easy, right? You have a perfect abstraction that solves your problem, and that one looks silly, but we have constant examples where we actually have that level of perfect fit and magic that we just take for granted because once we get these abstractions right, we stop even thinking about them at all, and that's when they're the best. The best abstractions are the ones we don't even think about, and there's an awful lot of them if you keep picking away the layers, it's abstractions all the way down to the silicone. If you think about just all the things that go on when you try to do something like fetch a URL, there's an awful lot of moving pieces there. It's way more than you can hold in your head, or anybody can hold in their head, and it's way more than any one team could implement all by themselves, certainly in 2017, 'cause the world is just too complicated. So, sometimes we get the push-back to this whole argument that says, yeah, but sometimes things feel too magical, and I don't like that, and I don't know what's going on, and that's a very natural response to a real problem, but it states the problem in a bit the wrong way. The real problem is not too much magic, but whether you get the, the abstractions are good or bad. There's not really such a thing as too much of them 'cause if there was, we'd all be doomed because we're all standing on a giant tower of them, so. In the Ember ecosystem, one of the best ways that we've tried to build higher abstractions as a community is the add-ons ecosystem. This is the logo for EmberObserver.com. Something I think is one of the most important strategic assets of the whole community, being able to very organically in the community, raise up new things, try them out, and also have a sense of who else is using them, how much should I trust this thing, how new is it, who's working on it? That's a really nice... It's one of the best things about the community, and in a sense, Ember itself really is kind of like... It really exists to allow that to happen. That's kinda the whole point. It's to give us a new higher level plane to begin building on so that these things can exist, and add-ons are an example of what I'm saying around, it's the only way to actually make software easier is to not write it all yourself. It's to do it together, right? It's to share the load. So, my topic today is really around, how do you grow, what today you might think of as just the Ember add-ons. How do you grow them into something more powerful? Like a step function more powerful, not just 10% better, but like a couple orders of magnitude more powerful, right? What would that look like? I'm gonna look first at, kind of, a typical application architecture, right? You might think of your app in layers, and at the top, we have our client app that runs in the browser, we have our server app that runs our application code, and in an app here somewhere, and we've got some kind of storage layers. There can be many computers involved in any of these layers, but it's a pretty good model. My colours here really are, red is your code, and blue is all the stuff that is not your code. It's community code, or it's vendor code. When you think about it, I think the ratios here are probably pretty correct for a lot of applications. You actually get an awful lot that is already shared, and that's great, and that's why we're able to do what we do. When the web was young, and this stuff didn't exist, it was massively expensive and difficult to launch a very basic website, and now, one person can do what a team of 10 or 20 had to labour over back then because we have all these nice things. At certain layers, the problem is almost so well solved that you would be a bit irresponsible to try to do it all by hand, particularly the storage layer here, which is why I drew it all in blue, right? You have to have a really good reason that you need to write your own database from scratch. Even if that's your whole business plan, it's probably still not a good business plan. It's just not an easy thing to do. And it's great that we don't have to do that, right? Both the server and the client, I think, teams that are shipping ambitious apps heavily leverage existing code. So, clearly in the browser, you've got your Glimmer and your Ember, or your angular or whatever, that's giving you a lot of leverage, and on top of that here, I've drawn add-ons, which are basically chipping away some of what would have had to be your code but is now not. And on the server, it's similar, right. If you have something like a Rails, or Django, or a Struts, that's giving you an awful lot of the hard work, and they've got add-ons too and all that stuff. So, it's already pretty good, but if we wanted to do better, where are the opportunities? One thing to think about is that if we think about the horizontal lines on my slide, we think about splitting the app along that dimension, that's an area where all those boundaries are ones where there's pretty clear... There's pretty clear protocols and abstractions that already exist, and at each of these layers, you have actually quite a lot of choices in terms of open source and commercial products that solve these things, right? Storage layers, there's an awful lot to choose from, like people get the concept of that division, and certainly speaking from server to client is like, there's a few ways to do it, and there's lots of good tools run at both sides, right? 'Cause it could be speaking just MPI, it could be speaking Graph QL, it could do rest, it could do web sockets, and there's great tools around all those things, so each of these boundaries is pretty clear, and then with the boundary between the blue and the red, say on the server's side, that would mean maybe your Rail's API. The boundary between the blue and the red on a client, that's your Ember API, right? And, they're well defined layers that people kind of understand. So my point is that the horizontal lines are basically, we have that, that works. So the question is, can we start to slice it the other direction? How do you slice apps vertically? Can you make it so that two completely separate teams can ship whole feature sets, and share, right? So, can you basically start to make apps smaller? Can you start to invert the relationship between, kind of, components in applications so that everything's a truly component-centric world, so that components can actually shift features all the way down the stack and have out-of-the-box things that work, alright. So, it's hard to do, but that's kinda the topic of my talk, and that's why I live with the ambitious. This is a community that does ambitious stuff. One of the reasons the vertical boundaries are the harder ones is because they don't just require agreement on a protocol, like a wire protocol, or a public API of just a library. They tend to require some kind of design agreement to design in the sense of, not how it looks but how it behaves. Thinking deeply about a system and what it's primitives are, and how users should think about it. We actually do some of that pretty well in Ember. Our add-on system, I've drawn it deliberately with some kind of vertical lines between your app and the add-ons, right? They have to collaborate in a very deep way, and our component composition patterns are very strong. In fact, the ways we can nest them, the ways that component composition lets you build very rich experiences in very elegant ways is part of the pitch. It's part of the key ingredients for what you need to do this. So, next I'm gonna switch to a slide showing what I'm gonna introduce as the cardstack architecture, and some of you may have seen me talk about cardstack at Embercon. In that talk, I was really focused on zooming in on the Ember app and the things that cardstack builds on top of Ember to give you nice features in an Ember app. In this talk, I'm zooming out a little bit, and looking at how the Ember app relates to the rest of the architecture, and why we would build it that way, and what is the opportunity to begin to slice apps in a new way. In the cardstack architecture, I still have kept my own, I have my old server app there. I just moved it down, and I put it in the storage tier. The reason I did that is just because any server you already have can basically be thought of as just another storage tier for a server that comes after it. In big, practical software systems, you almost always have archaeological layers of stuff, and if you try to design a world where you don't support that, or don't like that, that's not the world we live in, so this pattern comes out of a lot of practical apps at big organisations with a lot of data and a lot of systems. It's something you almost always need at that scale, so it's a first-class thing that's supported in this architecture to keep your old server around, as long as you need to, maybe forever. So, in front of all my storage tier things, I put the cardstack/hub. Now, cardstack/hub is a node-based server. Ideally, you don't really, you're not... It's not a framework for writing a server. It's not Rails, it's not Express, it is really more of an out of the box thing, so the way you set it up is, you compile it from you package json, and based on all of the cardstack plugins that are found in there, the build process is going to find them all and assemble a server for you, and, to the extent that you need custom code in there, you just add more plugins that are your plugins, right? The idea here is to invert. Invert even further than frameworks typically go, where they expect, they give you a place to write your app, and they give you some nice walls to write it within. I think that in 2017, we do too much re-writing of too many boring pieces of our apps that we shouldn't have to write. You don't really need to write another auth system again. We don't, you know, I don't wanna ever have to do it again. I wanna do it once really well. So, the idea is to take it further than you go with an app framework that expects you to still sit down and write a whole app, and give you a working programme, right? A working programme that's highly extensible. It is still very targeted as to be a programmable system, and it's totally expected that you're going to wanna write some custom plugins and stick them in there, but we're inverting it, right? You're not expected to handle every request. It's supposed to be just the special things, focusing on the special is one of the themes here. Also, compile, did I mention that we compile it from your package json? That's a word we've heard a lot for a JavaScript conference, I think, this Emberfest, and it's not a coincidence. It's one of the superpowers that helps unlock all these things. So, what does this give us and why would I care? So here, I've drawn an add-on in a new colour, and the one at the very top, it's next to all the other Ember add-ons 'cause it's an Ember add-on. So, the idea is, a single MPM package can be an Ember add-on, and also a cardstack/hub plug-in. So, you instal one thing, and it might give you some components and some services, just like you expect in an Ember app, but it's also giving you code that is gonna get compiled into that hub for you. So, what this means is, now your add-ons can do an awful lot more than they could before. If you're a vendor of an API, for example, and normally, you give people an add-on that gives them client-side code, and then you say, now here's a tutorial on how to hand-integrate into your server. You can take that whole step away, right? You just give them a one-step instal and follow the conventions, and there's nothing more to do. Or, in a completely open-source thing, you could think about taking a great add-on, say like Ember Power Calendar, which today is obviously, purely you are there 'cause that's all add-ons can do. Well, wouldn't it be cool if it came with the full data storage layer for a calendar? That's really obnoxious to write. I've done that one one too many times, too, and I would like to not do it again, right? Can we share that as a community? I think we absolutely could. So, wouldn't that be great, right? Instal the calendar system, have the fully searchable, storable, indexable calendar ready to plug in to the rest of your components. Compose it all with component composition. So, that's the point, that is the goal, is to make it possible to grow that ecosystem of extremely rich, powerful add-ons. So, the point we're calling it add-ons is really not the right thing anymore. They're really like mini apps, and engines is also kind of a good word in the Ember community for something that's like that. Although, they don't have to be engines. They could just be components with a lot of stuff in the back end, or none, but that's basically the goal. So, let me zoom in on the hub a little more to explain what's in there. The first thing to point out is that the hub doesn't wanna own your data. It's very deliberate that your existing data sources, or whichever data sources you pick, are the things that can canonically own your data. So, the hub doesn't have one official database inside of it. There's no active record of something that is like the first-class way to store stuff in the hub. It's deliberately stateless and doesn't care. It caches a lot of stuff so that it can be faster than your data sources, when you want that, but you can throw it away and start it up again, and you should never lose data, right? That's kind of an important and critical piece of the architecture that's gonna connect us back to my long-distance theme of decentralisation, we'll get there. So, it doesn't wanna own your data, so instead, how does it store and read data? So, you need data store plugins, so those are at the bottom there, data source plugins. Those are just, again, they're like Ember add-ons. They're just Ember add-ons that happen to have code for the server, too, right? They could even be Ember add-ons that have components because when you wanna configure one of these, wouldn't it be nice if it has its own really rich component UI on your admin screen that set up nicely for you so that you can put in the right database credentials and click Go and have it ready, right? So, these are the kind of patterns that become possible when we can bundle up all the great things an Ember add-on can do with server-side code. And here, I drew one in red because I'm basically implying that, I still have my custom server in the bottom-left there. That's why it's got some red-eye, it's custom, so maybe I'll write a custom plugin for it so the hub knows how to talk to it. That's like totally first class way to use the hub, is that would be the expected way to do it. At the top, I have middleware plugins. That's what's gonna share your data out to the world, so json API plugin goes there. You could write a graph code along, you could have a web socket one, and I've drawn a section off on the right here with dockerized services. Now the idea here is, there's a big universe of really powerful open-source server-side stuff you might wanna run, and we want to be able to unlock the very best tool for every job. When you're on the server, you have a lot more flexibility than you have in the client, right? We don't have to compile everything in the JavaScript, so if your plugins just need JavaScript then that's fine, they can just be JavaScript, then run in the hub's own little dark purple box there, but anything else can simply be a plugin that declares a doc or image that it depends on, and the hub will manage making sure that's spun up and discovered and integrated. So, I have for example in there, that's the logo for Elasticsearch, so add one package to your project, have a full search engine. Elasticsearch is written in Java and needs a certain version of Java. Don't worry about any of that, at dev time or deploy time, because there's this massive other community investing heavily in Docker, and all the tools for getting it deployed and keeping it running in production that we get to utilise. So, we get a really, really powerful system, and that's just, by putting metadata and essentially, what looks like, a member add-on, you can spin up a whole micro-service, or a whole fleet of them if you needed them. So, all these plugins, they are well typed in the sense that they're not just like, hey throw some arbitrary code here in one of these few places and do whatever you want. Now, obviously, it's all open-source. You can always add arbitrary code if you want to, but the intention is to give people really clear paths to do one simple thing at a time so that everything actually composes well. The idea is that, any data should be able to be swept out for any other data source, and the rest of the system shouldn't have to care. This is a list of the featured types that are already defined in the system, and there's a basic level of documentation of them in the reading of the repo I'll link you to at the end. This is here more to give you a flavour for the kind of things that are baked into the hub. It definitely cares about your authentication, but it's a plugin, like, you get to make it work with the authentication system you have, or pick the right plugin if you're building a new system. Things like field types, so that you can have really rich, rich interactive kinds of data. A mobile doc document is a great example of that rich media feels, you know, just had a plugin for complete audio file handling, and trans-coding, and stuff like that. Messenger is for pushing messages out to many different kinds of channels. You want a slack messenger, you want an email sender. Those can all just be plugged in, and the rest of the system doesn't even have to know how that message goes out. They just know there's a way to send the message. So anyway, what is all this have to do? It's called Cardstack. What does all this have to do with cards? Does it make any sense? It does, I will try to explain how. So, Card UI, the idea of having things that look like cards and move somewhat physically like cards is already a pretty ubiquitous design pattern, particularly in mobile. This is a screenshot from the newly released IOS app store. If you play with the app store on these screens, you get like a very canonical representation of Card UI. The way they move, the way they scroll, the way they expand and contract, it's a very powerful UI paradigm. It works great on mobile and it works fine on desktop, too, so it's getting popular and it's used in a lot of ways, and it really fits people's mental models. It connects to some of the things I've talked about in the past around animations and things because by making software behave physically, having a physical metaphor of a card really helps people understand it. So, that's Card UI, but Card UI is actually capable of much more than people are using it for today in these situations. What I mean by that is, what Cards give you is they're the perfect design system to marry with component and composition because components are all about isolating the inside from the outside, but letting the two pieces still interact very nicely together, and Cards do that at a design level so that a card is a very rich piece of functionality. It can be a whole application living in there, surfacing as much data as it wants to in the size that it's being rendered. The stuff on the outside doesn't have to know about the stuff on the inside, so you can have very rich implementations that run wild and innovate as fast as possible. As long as the edges of that card, and the ways that it behaves in interaction with other cards, follows some conventions, then it can participate in a whole Card UI ecosystem and feel very natural, and be moved around to the system, even though it's this very rich micro-application. So, the goal is to be able to have coherent experiences where the whole application makes sense and feels like one application, and is organised, but have them being implemented inside in completely, radically different ways, so that different organisations, different people, different teams can be implementing these pieces of functionality and letting them mix together in very organic ways. So, Card UI can do that stuff, but to do that, each of these cards needs to be a really rich piece of functionality, right? They need to be one of these plugins I'm describing, where they've got UI, they've got the server-side pieces they need to back it, they know how to get access to data through agnostic paths that don't know about where the server might live. So, all of these layers that we're talking about, this is all about being able to slice the application stack all the way down, and have a self-contained piece of functionality that you can remix and rematch, and it keeps working as you move in to a new context. And, when you can pass an interactive card to another person in a conversational context in a message, that unlocks a whole lot of, all of the workflow pieces of applications that is hard. So, if you think about transactional workflows, approvals, the kind of stuff that is just like very obnoxious to design out to the Nth degree, and hard coding to an application, and then the users change their mind. Workflow's hard. It's much better to build systems where workflows can grow organically. You can give people cards with a bit of richness, let them share them and remix them and sort them and match them how they need to, and very organically grow more rules where more rules are needed, or new kinds of cards when new kinds of cards are needed. We are actively working on building out more, some actual applications and some demos to convey more of that and show what you can do with Card UI. So, the reason I care about Card UI, and the reason I titled this talk as kind of revolutionary, is that I think it attacks one of the critical problems on the web, which is centralization, walled gardens. The pendulum of the internet has swung back and forth between the open and the centralised, and right now we're at a very centralised point, right? There are giants that control most of the attention on the web, and that gives people fewer choices. It slows down innovation because all the attention is in those places, these platforms that are completely owned by a small number of companies, and it's just hard. Even if they open up some of their capabilities for as platforms for developers to programme on top of, you never have any kind of safety investing in those kind of platforms, they're not open and you could try to build a whole business on top of Facebook, on top of Sales Force, and they could pull the rug out from under you at any day. So, those ecosystems are always a little bit stunted. People are not innovating there as fast. The open web is better at that, so how do we reinvigorate the open web and get people innovating, and leapfrog over the current generation of centralised systems? A statement of the problem is that every outcome has this complete layer at the top of the custom stuff that's in red, and it's sitting between the user and their data, and for the most part, all these systems are built on the same standard stuff underneath, right? It's all, it's open source stuff. It's Facebook friends on PHP and MySQL, and they've got their own compilers for it, but they've open sourced them, and all of these, all of these tech stacks, it's not that deep before you get to the open source again. In fact, the depth there keeps getting shorter and shorter as the open source gets more and more sophisticated. So, it's beginning to be possible to find ways to drill holes for that little layer of custom stuff and begin to give users some of the power that we already have as developers. But maybe, having that layer, of course, means that when you write an app, you have total control of the experience, and that's nice until you realise it's a huge burden as well. It means that to ship an application, that's an important application, an ambitious application, you have an awful lot to build. You have to build all the things. You can't focus on the one thing that's special. You have a great idea for solving one particular problem, but you can't just solve that problem. You have to also write the login system, write the auth system, make sure it sends emails the right way, right? All this stuff, and making all the screens that are just not so interesting. So, the pitch is, there's a trade-off here that's actually good for the developer and good for the user. When everybody is doing the separated off walled custom model, users get the strength in experiences, and they have to kind of pick between making everything work by staying in one walled garden, or kind of having things not work nicely together and being out on the open web. Businesses feel that trade-off really strongly because they are very frequently asking the question, should I build or should I buy some of the important pieces of software I need? And it's a really hard problem for an awful lot of situations because they want a thing that's very custom that is worth a lot to them. It would be worth them building it, but if they go and build their own app, they need to build all the other things. They can't just shop a la carte and say, I wanna build that, but I wanna just use this and this and this and this. Now, of course there's big vendors who will sell them that capability. They'll say, you could customise my thing, but of course, now they're customising at somebody else's walled garden, and they're locked in now, and their investment is sunk into somebody else's platform, and their data's locked in. Now, lock in is clearly bad for users, but maybe it's good for us 'cause we write the software. We get the money off of them. My argument is it's not, unless you happen to be one of the very few, very big vendors, who are so safe and conservative that they will not go out of business because once you're locked in, when the data's locked in and the hosting's all controlled by the same company, it's a high-risk situation. So, if you're one of these start-ups that sends out the Our Incredible Journey email, and says we're gone, goodbye, you could download all your data in the next six weeks as one giant zip file. Good luck with that. Important software can't be trusted to that level of risk, so that's why most of the important software in the world gets built by very boring, big, not very innovative vendors. Not because they're good at it, but because they won't disappear, and that's because of the lock-in. The lock-in is the risk, so lock-in is actually hurting us, the kind of smaller, scrappier, innovative, fast-moving chunk of the software world. We could aim bigger, we can go to take over that enterprise software, if we can give businesses a path that is less risky, make it easy to try you, and have no hard feelings if they don't like it, if there's a problem. Also, have them feel comfortable that the data is really theirs and they can keep running it, even if you flake out. So, this is not about telling people to eat their veggies and just run this decentralised stuff because it's good for the world, and it's not that. I do think it's good for the world, but I don't think that's how you succeed. I think you succeed with a better pitch and a better user experience, and I think that is what the opportunity is here. So, it's not a mistake that the hub sits in the middle of all this stuff, between data sources and card applications. It's deliberately disintermediating those things, so that the data sources can actually move around and keep the app going, right? If you think about all the effort that's already invested into making it easier and easier to deploy and monitor and host applications, massive community investment from all across the open source, right? We've got Ember CLI Deploy is a great example that's focused just on Ember apps, but there's a massive adjustment. Solving this very hard problem of making it easy to deploy software. It's getting easier and easier and easier. Many organisations that would have had to just trust a vendor to run it all for them in the past, it's getting easy enough for them to do it. So the idea is, people can begin controlling their own hosting. Because it's all swappable underneath, that's now starting to be a possible thing, and that's how you take some of the risk off the table. This also ties into Glimmer. By making these things Glimmer apps, they are fast, they are portable. That's what you need, this is all connected. So, it all connects back to all... Everything from the very small to the very large in Ember is all driving us to be able to do this. I am gonna go quick through this last bit. And then, we also live in a time where there's really good distributive systems out there that are mature or maturing. People are really interested in distributed stuff. This is the decentralising the web problem. Git is actually way more decentralised and powerful than people realise. It's good for more than just your source code. Matrix is worth checking out. It's a really powerful decentralised messaging layer for real-time messages. And then, you've got like the Bitcoin and Ethereum here, which are obviously massively popular and bubblicious, but they represent new ways to organise and coordinate people, and I do think that interesting new models fall out of that. So, all of those things can power very decentralised applications. All that stuff is looking for an experienced layer that can make sense of it for regular users that can have a design system, that actually lets people make sense of, how do you actually bring the benefits of this future world to normal people? How do you actually leapfrog over the current user experience and make it worth it for them to adopt this future happy decentralised world? I think that with the power of Ember layered on top of all of this stuff is the decentralised... Is the user experience layer for that decentralised stuff. Last slide. A lot of people think to go decentralised is to defeat the Cloud, the Cloud is the problem. You don't want your data on the Cloud. My bet is that it's actually not that simple. The Cloud is actually fine. You can use the strengths of the cloud and the strengths of the fully distributed stuff, both of them for what they're good for, and when you give users actual real choice in portability, the Cloud is their friend, and particularly when they control their own AWS account. That's a way to think about inverting the Cloud and can you get to the point where the customer can choose to put in their own credentials and just pay their own AWS bill? We've had the opportunity to build new kinds of... New kinds of business relationships, new kinds of organisations, unlocked by the things we're building together. So, keep building higher, that's the overall goal always. Even if these big goals take longer than we think that we will, all the intermediate steps along the way are just great software that lets us all keep shipping better stuff, all the way, so it's just, it's win-win. So, thank you, here's some links. There's cardstack, cardstack repo has all of the open source code I've been talking about, and cardstack.com has a lot more details on this whole grand vision, so thank you very much for your attention.