You're safe. There's also no musical notation, which is 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 when 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 HashiCorp. We're going to get into that, but this talk starts with space. 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 predate all modern computing. They also are still sending and receiving data. At 45 years, plus the years before the mission, where everyone is coming together, the entire

careers have 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. And 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. Like, 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 long in advance. But 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. I like nothing against it. I like the name, Stalewell Revalidate. We've been calling it background loading in Ember data, but it's cool that React people get to 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 Voyagers had launched, but it would take another 10 years before this proof of concept

became the standard we know today. No, they used this. Your laptop has a network interface card and the Voyagers have a network interface complex. The dish there on the right, this is in Madrid, so shout out to Imperfest. This dish is 70 meters tall.

This talk isn't about the Voyagers. 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.

I'm going to leave that lid off. In 2008, this was 31 years after the Voyagers 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 it was the correct thing to do. Plus, I had already taught myself how to code. I wrote an 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 1995 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 RuffleRS, which is a tech project to re-implement the ActionScript 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. So 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 Embedded C for some reason, played with C++, learned data structures, did art things and processing, even explored functional paradigms in 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, Flash, .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, and 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 photography. 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 Blazor project, it takes C Sharp, 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 governed 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 mega-billionaire behind Oracle, owns 98 percent 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 MVC 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 MVC 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, Inbert 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 on their way out next or there's models and schemas.

I'm looking forward to it, but things change and Inbert makes 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, which is 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 amcharts 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 amcharts, 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. That continuity. I ended up sticking with JavaScript at this job. It seemed like a better career move than sticking with Perl, 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. Two stars, but it's there.

Eventually I left that job also to work at a startup, just kind of ride the wave even more. They were using Golang on the backend and Ember and Less on the frontend, 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 there are 21-year-olds again, making sure that there's 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.

No. Now it's awkward. All right. All right. 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, i.e. 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. Unfortunately, Paul Irish came to my rescue, and he reopened the issue with the comment

reopened dot 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 you here, as they say.

You'll only embarrass yourself. All right. So we have 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 added AmberConf. Sorry for not the stage. I initially worked at Nomad when I was here. It was 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. 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, the 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 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 range 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 tests. 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 a seat 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. Armand is still our CTO, by the way. Our immediate focus continues to be the seven tent pole 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.

Around this time, I also went to AWS Reinvent. 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 it's not quite six. And 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 Hafthor, also known as The Mountain from Game of Thrones. He was just standing there, and you can get your photo, and they said, how are you going to handle your mountain of data? And it's like, 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. And I don't mean one and then the other. I mean 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. Now, 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 all together?

Hashicorp also has conferences, significantly smaller conferences. This photo is from the Hashicorp 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 badass 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 were interested in Nomad for the first time because the web UI made it more approachable. But in the back of my head, there was 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 at a startup and I had things to do. Hashicorp 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 9, 2021, we achieved the startup dream, which is to not be a startup anymore. We went public. This is a really busy photo, but somewhere in there is my forehead. 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 our 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 a 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 going public. But they were acquired for $1.8 billion, and 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. Everything 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 HashiCorp also part of this problem? How much of our value came from capturing value other projects had 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 an early going shop. Was that 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 part of, yeah, woo. Surely ember is also part of our success story, but it was HashiCorp that got to be the unit

in accordance 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? 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?

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.

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 Embroider 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 projects sustain themselves through their own revenue channels. Terraform has Terraform Cloud, a SaaS model, Vault has Vault Enterprise, an OpenCore model,

and so forth. So let's consider a thought experiment here. There's 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 funding an external project like Ember, they fund 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 Leah 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 discuss. 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, like 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. Babbel once had the noble ambition of being a transpiler, transpiling ES Next to browser-compatible JavaScript. Now today, there's a whole section on their official plugin list dedicated to React things.

Last I checked, React is not actually an equescript standard. This isn't even the weird stuff. I was going to memorize the name of the Babbel transform deep inside of Ember 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 Babbel is people started 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. And at first, React is the core, but 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. 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 out great, and then it's just good, and then it's only good enough, and the next thing you know, it's legacy. Of course, I'm talking about Ohm. Talking about Ohm here. Ohm was a fascinating React-like library for ClojureScript. It had an emphasis on immutable data structures and Clojure-inspired data polling and state

management patterns. Unfortunately, it proved to 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. We look 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.

To help me rationalize all of this, I found a model outside of tech that I'm quite fond of. I say I found. I don't know. I don't like saying that. I'm not some sort of discoverer. I'm not Meriwether. People are doing work that isn't in tech, and I'm on the internet too much, and I saw it. It'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 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 Goldilocks 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 this is actually good that it's owned by a company that has

some sort of way to make money. And if we look at the HashiCorp 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 meant users, and users are a prerequisite

to revenue, but their objective wasn't to analyze the results of the experiment and do science. No, 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 Foundation's 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 graduates to become this industry-grade, semi-standard solution to a problem. And that can be good, it's just different. And 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'd think I've lost my mind, but it did so much for our community, it was mentioned yesterday that Angular CLI was initially

a fork of Ember CLI, and that's true, Ember CLI also predated Create React App, and 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, like 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 dated 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 had 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 Ember's convention-based approach

to authoring. Okay, at this point, you're probably expecting some sort of grand reveal, and I'm not gonna do that. You don't get one. I'm not about to debut a sustainability model, but I do think the question's worth asking. Can we come up with something similar for how to evaluate open source communities?

And if we did, how would Ember score? Too low in some places, maybe, too high in others, I'm sure, but how will you help? Thank you.