 Hi everyone, I'm very aware I'm the last talk of the day at the end of the conference so I just wanted to say in advance there's no code in any of my slides. You're safe. There's also no musical notation which is like syntactically close enough. So I just want to take advantage of the mushy and vulnerable state all of our brains are in and return to some themes, ask some unanswerable questions. The whole thing also ended up kind of being personal and I was writing it so I hope you like me and if you don't keep that to yourself. That's all. I mean Ember knows its way around conventions so I'm sure you'll all be nice. All right as Matthew said, I'm Michael, I'm at Hashtagorp, we're going to get into that but this talk starts with space. So NASA launched the Voyager spacecrafts in 1977 and today they now hold the record for the longest continuously running computers over 45 years. At this time frame they pre-date all modern computing, they also are still sending and receiving data at 45 years plus the years before the mission where everyone was coming together. The entire careers had started and ended with the Voyager program. In February of 1990 Voyager 1 snapped this photo of Earth from its position out near Neptune. It's the famous pale blue dot, that's Earth. This was 13 years after the launch date and I'm sure this was a wild time if you were working at NASA but the Voyagers didn't have a wild ride necessarily. They went faster than probably any other spacecraft but it was all math. We knew it was going to be there, it ended up there, we knew longer advance. And once this had happened the Voyagers were prepared for the next phase in their travels. Again this wasn't a reaction to some sort of unforeseen scenario of the satellites being far away. This was all known in advance, calculated and prepared for. Since there's not a lot of stuff past Neptune and since Neptune's pretty far away the satellites received a software overhaul. The flight software was more or less entirely rewritten to be more autonomous and more energy efficient. And then this new software package so to speak was deployed to production 2.7 billion miles away. This is a room of engineers so I'm sure you're wondering how in the world, slash all the worlds in the solar system, did they do that? Well they didn't use SWR. This came out in 2019, it's much too new. It's a cool library, like nothing against it. I like the names, Stale Wall Revalidate, we've been calling it background loading and Ember data but it's cool that Ember or React people could do use this now also. Doesn't use fetch either, this came out around 2013. The timelines are a little fuzzy and it's not documented very well. Also didn't use XML HTTP request which came out in 2006. In fact XML and HTTP are both too new. HTTP was first released in 1991. Underneath HTTP is TCP IP and technically the first draft of TCP did come out before the voiders had launched but it would take another 10 years before this proof of concept became the standard we know it's a day. No, they used this. Your laptop has a network interface card and the voiders have a network interface complex. The dish there on the right, this is in Madrid, shout out to Ember Fest. This dish is 70 meters tall. This talk isn't about the voiders. I have a really awesome PDF here if you're interested in interstellar telecom but it's not that. I'm returning to a theme that we've been talking about. This is about longevity. It's about stability and uncertain times. It's about sustainability. In 2008 this was 31 years after the voiders were launched. I graduated from high school. Also the economy collapsed. As an 18-year-old I didn't fully understand the situation. Sure it seemed bad but I felt protected. I was going to college which if you grew up in that time you knew was the correct thing to do. Plus I'd already taught myself how to code. I wrote action script and made Flash games, paid for lunch money this way or got my lunch money this way. I had skills for the new century so who cares if the economy is doing things. Two years after that Steve Jobs wrote this letter thoughts on Flash. Somehow it was simultaneously the spiritual eulogy of Flash and also the murder weapon. Steve Jobs did have a way with words. Flash lived from 95 to 2010. At 15 years careers didn't quite come and go with Flash. Instead people who had been professionals scrambled to find something else to do. Some ended up making iOS apps. Others found platforms like Unity. Some wrote the CSS3 and HTML5 wave and still yet some stubbornly held onto Flash. Someone had to. Whole ecosystems aren't actually gone in an instant. If we look at this timeline we can think of the internet as more on this voyager scale where Flash was a fleeting technology choice. I also can't talk about Flash in 2023 without mentioning these two projects. Flashpoint Archive which came out in 2017 is a community effort to archive all of the amazing Flash cartoons, videos, games that were on the old web that no longer play in a browser. And then on the left there is Ruffle RS which is a tech project to reimplement the action script VMs in Rust to compile down to Wasm. So the same Swift file that was made in 2006 can be recompiled and played using Canvas and HTML audio. Pretty neat. It's okay though. I was in college. College is a time to learn new stuff. If Flash was going to go away that's fine. I'd pick up something new. While I was in college I played with .NET, played with Python, did some unbedded C for some reason, played with C++ to learn data structures, did art things and processing, even explored functional paradigms and racket. But mostly I worked in C sharp. I own this book. I took this photo. I want to read the cover of this because I think it really grounds what was happening at that moment. Link, Silverlight, ASP.NET, Ajax, WPF, XAML, WCF. It's a whole can of alphabet soup on the cover of this book. But it was really exciting. This was during a time when Java was in a bit of a lull. And because of all the momentum that was behind .NET, I was led to believe that this was the Java killer. Of course, neither died. Java and C sharp .NET, they both have widespread use, growing ecosystems and thousands upon thousands of developers. They also have their own vibes. It's quite curious. This is Jakarta EE. The site makes me so sad. It's an A plus Java pun, Jakarta. I mean, it's great. But then the site is entirely humorless. It's got stock metography. And then .NET, they have this weird consistent way of looking like knockoff websites. Every single time. I don't know how they do it. Which is in itself a tragedy because this blazer project, it takes C sharp and compiles it to WASM so you're using a single language but still making client-side experiences. It's really neat. We can laugh at Microsoft all we want, but we should also take a moment to note that in addition to .NET, Microsoft owns TypeScript and VS code and GitHub and NPM. So we should be careful who we mock. The good news is, they don't own JavaScript. That's covering through the independent CC39. Well, technically, ECMAScript is because JavaScript is a trademark owned by Oracle and Oracle owns Java because they acquired Sun. Did you also know that Larry Ellison, the billionaire, the mega-billionaire behind Oracle, owns 98% of Lanai? Lanai isn't a huge Hawaiian island, but one dude owns a whole Hawaiian island. That's just weird. And the talk also isn't about capitalism, but tech is so awash with capital that it just ends up being interesting to observe where it pulls up. All right, back to me. In 2009, I was working at a job where I was doing web forms in ASP.NET, which is a peculiar way of making websites. There are lots of genius things in here and also lots of horrendous hacks, which was customary at the time. Eventually, Microsoft released ASP.NET NVC to compete with emerging projects like Rails and Django. Unfortunately, they didn't offer a good path for migration, so it created a bit of a schism in the ecosystem where people weren't sure if they should migrate to NVC or if it was only for new projects or what they were supposed to do. It's also funny looking back at this because once upon a time, Ember used to be in a VC framework. I wouldn't call it that anymore, but I guarantee you that there are apps still in development today that once had many more views than components. It's also strange to think that there was a time before services. And according to the keynote this morning, maybe models are underway out next or there's models and schemas. I'm looking forward to it, but things change and Ember keeps making sure you come along with. After that job, I got my first big kid job I like to call it. I was 21 when I got this job. I was pretty young for a software engineer, but I was qualified, so who cares. But when people found out I was born in 1990, they vomit. It's not too dissimilar from when I think about how some of my peers now were born after the year 2000. That makes me want to vomit. It's weird. They'll never get to remember that day we're meant to never forget. But it's okay. It's actually more than okay. It just is. There's no alternative, so you've got to get okay with it. And if I attempt empathy here for a second, I graduated into a recession, they graduated into a pandemic. A recession doesn't seem so bad in comparison. When I was at this job, people knew I was the flash guy, so one of the products I had was to migrate our flash AM charge to some sort of non-flash solution to replace these dashboardy lines and bars we had. After doing some research, the best alternative we ended up finding was AM charts, but the JavaScript version. The developers made sure to port flash version to JavaScript, preserving as much of the API as possible to create a migration path. And that's continuity. I ended up sticking with JavaScript at this job. It seemed like a better career move than sticking with Pearl, and being in the scene of JavaScript in 2012, there was a lot going on. There was a whirlwind of activity, new and exciting ideas and projects being thrown around. I used to say that you could Google any animal followed by JS, and you'd find a GitHub repo. Just to verify this is still true, I Googled chinchilla JS? Sure enough. It's got like two stars, but it's there. Eventually, I left that job also to work on a startup, just kind of ride the wave even more. They were using Golang on the back end and Ember and less on the front end, and the whole thing felt very new. It felt like the future. It felt next-gen in the classical sense. And when I say next-gen in the classical sense, I think next-gen really should mean what I was talking about earlier, about me being 21, and now they're 21-year-olds again, making sure that just continuity for 10 years, for 20 years, for 30 years, that's much more next-gen in my mind than just breaking stuff and saying it's disruptive. Thank you. You can clap. You also don't have to. That's fine. Now it's awkward. All right. This is also when I got my first taste of open source. It wasn't the first time I participated in open source, though. The honor of that goes to this issue I opened in 2011, IE conditional comments triggering compatibility view. Apologies to anyone who understands what that means. It was not a good time. I felt like I handled myself pretty well, though, until I accidentally closed the issue while trying to comment on it. In my defense, the UI was a lot worse back then. It's still bad. I heard that. Fortunately, Paul Irish came to my rescue, and he reopened the issue with the comment reopened.dot. Now, again, I don't want to talk about syntax too much, but one dot, that finishes the sentence. Three dots, that's a pause. Two dots, that's an awkward silence. Never meet your heroes. They say you'll only embarrass yourself. All right. So we had been using open source here. We believed in open source at this company, but we were still mostly a consumer of it. We had some projects that were technically open, but they weren't popular. It's not where our business interests were. We use open source in a way that a lot of companies do as a recruiting tool. It was a way to signal the qualifications of our engineering team. In 2017, I switched jobs again, and I went to HashiCorp, and that's where I still am. I actually applied for HashiCorp accidentally at an Invercon. Story forward, not the stage. I initially worked at Nomad when I was here. It was a real open source. I was on the production side. Everything was open. You can still read my code and my comments and my issues from six years ago. It's all in the public. I mean, who doesn't want that? And moving from the consumer side to the producer side, it got me thinking a lot about open source as a concept. The participants, patterns, the purpose, and I'm not sure if anyone has thought about all this stuff in a metaphysical way more than Christopher Alexander, who's written several large tomes of this type of wisdom, opinionated wisdom, but a lot of people agree with him. If you've heard of him before, it probably means you either have a background in architecture or in design systems. I shouldn't use memes in a closing keynote. It's a serious time. Fortunately, this meme is actually just a Venn diagram, so fixed it. He has this quote that I think really applies to what I've had been thinking about. The total pattern, space and events together, is an element of people's culture. It is invented by culture, transmitted by culture, and merely anchored in space. But there is a fundamental interconnection between each pattern of events and the pattern of space in which it happens. And I find this rings true. There's also consensus within our industry that at the very least our digital spaces resemble our physical spaces. That's why we call it information architecture after all. So if this connection among culture, space, and events is true, what does this space say about our culture? I think it's quite telling that the first tab is code and the second tab is issues. We also don't teach people the relationship between these two numbers. Should one be bigger than the other? And if the numbers are big, should I believe the project is poorly maintained? If the numbers are small, should I believe the project isn't being used? There's a relationship between these three numbers. Between commits, issues, and pull requests, there's something going on here, except it's never really communicated. You're kind of on your own to figure it out. And between commits and contributors, there's something going on here. And if contributors is derived from the Git log, aren't we missing major contributions in the form of community support? And then there are all these numbers on the screen, but there's no sense of what the project has been through or even when it was started. It's only the latest release here that gets us seated at the table. And when our space is so uninterested in history, why should we be surprised when a recurring event is the pursuit of new? On a larger scale, it was just exciting to be a part of HashiCorp. When I started, we were at around 100 employees. The last round of funding we had secured was a $24 million series B round, bringing our total funding to $34 million. This quote sums up the state of the company. Armon still our CTO, by the way. Our immediate focus continues to be the seven tentpole projects we have and the corresponding enterprise applications we're building. Looking back at this, what kind of tent has seven poles? It underscores the experimental mode we were in. The core thesis was, could we make open source also be sustainable? I also learned quickly that infrastructure OSS is built different, pun absolutely intended. I think this really encapsulates how different it is. IBM acquired Red Hat for $34 billion, which was $1,000x what HashiCorp had been funded when I joined. IBM didn't do that because Red Hat was open source and open source is cool. It is. Those things are true. But they did it strategically. They figured that the open source community within infrastructure is the future and they needed to catch up and also Red Hat happened to be profitable. They figured this out already. To merge together was good for IBM. The scale, excuse me, around this time I also went to AWS re-invent. This was in 2018 I had this pleasure. There were over 50,000 attendees. It was a campus of six hotels. I should note this is in Vegas, so a Vegas-sized hotel is not a normal-sized hotel. So, you know, it's not quite six. In a premier booth on the floor of the expo hall cost a million dollars. This is just an unfathomable scale to me at the time. One of the vendors had hired Hofthor, also known as the mountain, from Game of Thrones. He was just standing there and you can get your photo. They said, how are you going to handle your mountain of data? That's a human you just paid for to come out here as a prop. It was weird. During the closing party, they also had skrillex and future islands headlining. Both of them at the same time on two different stages just because they could. The point I'm trying to make here is this wasn't funded by a Patreon account. That's for sure. This was business. This was territory carving. This was capitalism. This was markets. People who were running booths, they'd be happy on the first day and then dejected on the last because somewhere in the middle AWS announced a new service that would compete head-to-head with their startup. To Amazon's credit, they never said this was about open source to them, but it sure didn't feel like community either. Why couldn't we be doing this altogether? This photo is from the Hashikon in 2017 in Austin, Texas. This was the first time that the work I had been doing over the summer was shown. It was just a really satisfying experience. Not just because seeing your work displayed on the 30-foot widescreen is bad ass in itself, but also because you can just feel the energy of people who are eager to have this UI to complement the existing Nomad CLI experience. And also people who are interested in Nomad for the first time because the web UI made it more approachable. But in the back of my head, there's this inescapable thought. I'm working on Nomad, the underdog workload orchestrator fighting Kubernetes, the incumbent container orchestrator, but I'm also using Ember, the underdog JS framework fighting React, the incumbent JavaScript library. Except Nomad is corporate backed and Ember is community backed, while Kubernetes is community backed and React is corporate backed. So how did this all come together? I enjoyed philosophizing about this, but I was also still working on a startup and I had things to do. Hashingorp grew and grew. We secured funding in amounts I felt were absurd and unnecessary, including our series E, which was $175 million. I've since learned to appreciate this as a strategy even if I can't stomach the thought of numbers that big. And then on December 9th, 2021, we achieved a startup dream, which just did not be a startup anymore. We went public. This is a really busy photo, but somewhere in there is my forehead. Yeah, when we rung that bell, we had a $16 billion market cap. It was a surreal feeling, being in Manhattan in a suit, never worn a suit before, ringing Nasdaq's opening bell and seeing the far faces on towering billboards of Times Square next to Bizarro NFT billboards talking about the moon. If you've been to New York, you know exactly what I'm talking about. In the back of my mind though, I still couldn't escape the reality that Wall Street didn't like us because we were successful open source experiment that had created value in the world. They liked us because we had found a repeatable way to capture that value. To underscore what I mean by this, this is the clearest example of the difference between value creation and value capture. Stack overflow was also acquired, or excuse me, they had an exit through acquisition, not through public, but they were required for $1.8 billion. That's not a small amount of money. I'm happy for them, but when you compare it to the wealth of knowledge hosted on that site and how directly applicable it is to the tech industry as a whole, which is in turn one of the most profitable industries in the world, you have to wonder how it ended up that way, just $1.8 billion. Of course, Stack Overflow is also a platform. You could easily argue that the real value came from user-generated content and they weren't paid at all. This is where I have to talk about the elephant in the room. Nothing captures the value of user-generated content much like this new generation of value capture monsters, large language models, GANs, diffusion models and all the like. They've enabled companies to slurp up the entire internet and then put up toll booths. Again, not talking about capitalism, but I think everything is kind of intertwined. At the time, I was thinking this instead. Was Hashtagorp also part of this problem? How much of our value came from capturing value other projects that generated or to use this in a more standard expression? We were standing on the shoulders of giants. Didn't they deserve some of this credit? We were famously in an early go length shop without our success. Surely some of it was. We're also maybe not quite as famously a long time Ember shop, nine years going. Surely Ember is also part of our success story, but it was Hashtagorp that got to be the unicorn with the good exit. What does this mean for open source? Do we have to sell our souls to get here? Were we doing open source wrong? And if we apply purity tests like this to open source, what prevents AWS from eating up competition, white labeling successful projects as Amazon elastic widget? And what does it mean for community participation when the project is governed by an organization that has to answer to shareholders? A more radical question that's still worth asking? Who cares? Let's not forget about the financial crisis at the epicenter of all that institutional failure was Wall Street. And from that came Occupy Wall Street, which wasn't just anti-Wall Street. It was largely anti-institution, mutual aid, direct democracy, and consensus-based decision making came from this core belief that we can't trust institutions, but maybe we can trust each other. Another artifact of the financial crisis was Bitcoin. The central belief here was not only that we can't trust institutions, we can't trust anyone. Only cryptography and algorithms, specifically in a vacuum, can be trusted. There are echoes of all of this in our open source communities. But on the flip side, HashiCorp's commercial success had put us in a position to give back. We can employ core team members. We can allocate more engineering time to projects that don't directly impact revenue. And we can fund initiatives like EmberConf and Main Matters and Broader Fund. You should do the same. Just go public with a $16 billion market cap, maybe you can afford it. But was this sustainable? Is this sustainability or is this charity? HashiCorp's own open source products sustained themselves through their own revenue channels. Terraform has Terraform Cloud, a SaaS model, Vault has Vault Enterprise, an open core model, and so forth. So let's consider a thought experiment here. No need to call anyone out. So let's just consider a hypothetical company that's also interested in open source. Let's call it Beta. And instead of finding an external project like Ember, they find an internal project that's still open source. Let's call that Redact. Would this still be charity? I mean, Redact doesn't have a revenue model, and it's not going to. So this is a successful company giving money to an initiative that has no intent on being profitable. So it sounds like charity. Isn't this kind of the same? I asked this like a rhetorical question, but there is a correct answer. And that's no. They are not the same. A corporation funding an external project is not the same as a corporation funding an internal project. There's more to sustainability than simply having funding. In this example, a corporation ceasing funding to an internal project is likely an extinction event. We heard Lea talk about this in the documentary yesterday. A corporation doing the same for an external project, it can really hurt. If a project is too dependent on a single source or a funding shaky, it can really cause a product to fall behind, but it still gets a chance to live on. Sustainability in open source is just much more complex than we ever discussed. We don't really have language for it. We can talk about GitHub stars, open and closed issues, time to first response, activity on Discord, the vibe of a Discord server or Twitter or whatever people are using these days. These are all meaningful signals, but none of them tell the whole picture. An open source project can be too successful and also collapse under its own ecosystem. Babel once had the noble ambition of being a transpiler, a transpiling ESNX to browser compatible JavaScript. Today, there's a whole section on the official plugin list dedicated to ReactThings. Last I checked, React is not actually an Equiskrip standard. This isn't even the weird stuff. I was going to memorize the name of the Babel transform deep inside of Invert that makes global still work, but then I forgot. But if you know it, you know it. Anyway, one of the things that came out of Babel is people sort of eagerly giving talks on AST transformations, and that's just not a normal relationship to have with your programming language. It's just not. I'm thankful in a way because code mods are awesome, but other languages do not expect you to understand their ASTs and transform them. If we talk about React for a second, it in turn is being cannibalized by frameworks like Next and Gatsby that bring sorely missing conventions around how to architect a React site. At first, React is the core. Eventually, React may just be the implementation detail. Projects can also make curious decisions in the pursuit of growth and stability. I love to see an open source dev get paid. Don't get me wrong. I'm not opposed to remakes being acquired, but you've got to admit a web framework being bought by an e-commerce company raises some eyebrows. And when an open source project doesn't grow, that can have its own set of bad things. It can fade into obscurity. It can start up great. And then it's just good. And then it's only good enough. And the next thing you know is legacy. Of course, I'm talking about OM. Talking about OM here. OM was a fascinating React like library for ClosureScript. It had an emphasis on immutable data structures and closure-inspired data polling and state management patterns. Unfortunately, it proved to you just be a little bit too niche on niche on niche. Even though it had nearly 7,000 stars, it only attracted 17 contributors over six years with the majority of that work being done by the original author, David Nolan, who eventually walked away to do other things. We also need something a little more nuanced than a marketing forward annual survey. We need to evaluate open source projects. We do. This is just not the way to do it. Both for our own due diligence as engineers, we want to make good decisions on behalf of our company. And also as individuals, we want to contribute to something bigger than we can ever do alone. So to help me sort of rationalize all of this, I found a model outside of tech that I'm quite fond of. I say I found, like, I don't know. I don't like saying that. I'm not some sort of discoverer. I'm not Mary Weather. People are doing work that isn't in tech, and I'm on the internet too much, and I saw it. That's a better way to say it than I'm some sort of discoverer. Anyway, this is a model I'm quite fond of. It's called donut economics. I'm not an economist either, so I'm not qualified to actually critique this model, but there are a couple of properties of it that stand out to me. First, that there's a sweet spot. It isn't about growth at all costs. It's about doing enough to provide a social foundation, but not overshooting and piercing the ecological ceiling. Or in other words, finding something sustainable. Second, it unapologetically has many dimensions. As mathematically aesthetic as a unifying metric like GDP is, context is important. And as I've been saying, we need nuance and nuance needs to be reasoned with. So with these Goldilock metrics in mind, I'd like to revisit some previous slides. First, let's look at Microsoft. If we take a closer look here, these aren't all the same. Different products have different licenses, policies, and governing bodies. In the case of TypeScript, the spec itself is made available under an OWFA license, and .NET itself is governed under a foundation. And then in the case of NPM and GitHub, these are platforms, and platforms have associated platform costs. So maybe it's not, maybe this is actually, it's good that it's owned by a company that has some sort of way to make money. And if we, sorry, that was just a circle. If we look at the HasherCorp slide here, yes, we did raise a lot of money. But VC firms that gave us all that money, they didn't do it because they too saw us as an open source experiment like we did. In a tangential way, they did because open source users and users are a prerequisite to revenue. But their objective wasn't to analyze the results of the experiment and do science. Now, their objective was a return on investment, like it always is. The mission you have to have when you accept VC is fundamentally different than the missions you can have when you get by on sponsorships or consulting or when you take it slow and get bootstrapped. And this Kubernetes equals Ember comparison is also deeply lacking nuance. Just generally, whenever you see something split into a binary, you should be skeptical. And in this case, this is a false dichotomy. Yes, they're both open source. But Kubernetes belongs to a foundation. And foundations aren't corporations, nor are they quite community effort. They're their own thing. To put it simply, core team members in Ember, when you go to the website, you see faces. When you go to the cloud native computing foundations website, the members look like this. Don't get me wrong, foundations also have their place. CNCF projects are often things that worked at one company. They were spun out and iterated on until there was some consensus and then it graduated to become this industry grade semi-standard solution to a problem. And that can be good. It's just different. These dimensions that we're looking at to evaluate projects, they don't all have to be cultural and financial. The way we build can also impact sustainability. A joke I like to make is that Ember CLI was too good. If you've only been using Ember for a couple years, you think I've lost my mind. But it did so much for our community. I think it was mentioned yesterday that Angular CLI was initially a fork of Ember CLI. And that's true. Ember CLI also predated to create React app. And the create React app made no sense when it came out to me, because I was already familiar with Ember. I was like, this is just copy paste, but I do it for my CLI. Where's the value in this is kind of what I was thinking. But it was so good that it meant our community didn't have to build an ecosystem of tools. And we didn't have to have the knowledge that allowed us to stay current. So now we have this data build system, and now Preston has to go around and patiently sprinkle embroider macros in every single repo. In this way, I would say we undershot. We did not actually make it to that social foundation. We created such a sealed abstraction that there wasn't space or a need for teams to independently tinker with build tools. But I'd also say that the broader JavaScript community overshot here, they pierced the ecological ceiling. Sometimes I think about the collective human hours that have gone into configuring and tweaking webpack, and I just shudder. So this is something I'm really excited about with Polaris. Ed yesterday talked about implementation versus interface, making sure you get the interface correct so the implementations can change without the whole world having to change around it. And I think that's just really good and also very true to Inverse Convention-based approach to authoring. Okay. At this point, you're probably expecting some sort of grand reveal, and I'm not going to do that. You don't get one. I'm not about to debut as a sustainability model, but I do think the question is worth asking. Can we come up with something similar for how to evaluate open source communities? And if we did, how would Inverse score? Too low in some places, maybe. Too high in others, I'm sure. But how will you help?