 All right, I don't see anybody straggling in. So I'm Josh McKenzie, for those of you that don't know me. I'm the one that writes way too many emails in the dev list that are usually way too long. Currently, PMC Chair, Committer, February will be 10 years on Cassandra. Let's just, it's a long time. Went from zero children to two children in that timeframe. So it's a good time, it's good to grow. I'm gonna be talking about the state of the community and a variety of different metrics that I pulled out from both the Git repo and looking at a lot of different things in terms of engagement, in terms of, for folks that are connecting with the project, what does it look like for them? And how are we all doing? Like what's our history look like together? There's a TLDR, which is that the state of things is good. I like to think of this as, you know, the quotation here is, it resonates with me. I was just joking with some folks like last week about training a model to spot the amount of gray and white in our hair and beards to kind of get an idea where we're all heading. But there's the question of whether you get better with age or whether you become brittle. And I was actually thinking about this last night. My neighbor, who's in his late 30s, took a dive out of his shower last month and like face planted on his sink. And he sends me a text message with his face all battered up. And he's like, I look like somebody from a video game now. This is great. I'm like, dude, no, you need to go get stitches. So that's the whole like, as you get older, you got to be careful, right? You got to be delicate with what you do and with the risks you take. And you got to be smart about it. And I think all that actually applies to our project and how we work with things, but you can't atrophy, obviously, as we all know. So the Apache way is community over code. So we're going to talk about the community first and then we're going to talk about code second. You're all very literate. So you can see what's up there, but we're going to kind of funnel our scope in terms of whether we're, you know, talking about the big picture, the small picture and kind of have a flow to it, hopefully. So for the community itself, this is the lifeblood of an open source project. And you all know that and we can all say that and that's like the great little, we put it on a mug. But the reality is like, unless we have robust diversity across a bunch of different stakeholders, we're at real, real risk, right? Like something can change, all it takes is a change in the market, a change in the company, a change in one space. If you got a single point of failure, your project's going to be dead in the water. So that is a thing that we crucially have to avoid. And that's kind of the backbone of a lot of the philosophy on the Apache side is how do we make sure we have a lot of different, you know, egalitarian, meritocratic, balanced contribution from people? So let's talk about it. All right, so you need contributions by year. This is a breakdown from our illustrious repo, Removing Merge Commits. I don't like them, but that's fine. We can all talk about that later. There's a pattern that we see here that you're gonna see again and again, which is an uptick through 2016, a downward trend, and then a climbing back up. And there was a broader thing happening in the Apache Foundation and a lot of the projects through this timeframe, where in many ways the projects, the participants, vendors, the foundation, we're all kind of trying to figure out how do we all play nice? How do we all work together? How do we make sure that folks that are being funded to work full-time on a project aren't completely skewing it or there's too much concentration in one place, et cetera? And so there was something of a kind of broad, I would say correction in 2015, 2016, across far more than just the Cassandra project where a lot of us had some things to learn in terms of how we were structured. So what we do see is the trend going on from probably about 2019 onward, where we are at a healthy place steadily climbing upward. And if you look at our commits, which is a terrible metric because TCM just merged and it was one commit with 88,000 lines. So anyway, we all know this is a terrible metric, but if you look at enough terrible metrics together, maybe you'll find a fit line that you can tell a story about. But basically we see the same kind of trend where the velocity of the commits coming into the project, there was a back off, but then we're climbing back up. Now, we'll talk about this when we get to the releases. There's also the 4.0 timeframe that took place in here that we will discuss in the effect that had. So another one I thought was interesting was per email address. How many times are people committing? I'm guilty of having, I think, three email addresses in the history before I settled on the Jay McKinsey and Apache.org one. So there's that kind of an issue that would pollute the data. But there's a question of do we have individuals that are pushing a huge number of commits? And I always joke about Dave Brogius. Those of you that don't know, he would just ninja tons of spell corrections and comment fixes in there. So I always showed up with all these commits and we're like, Dave's never talking anybody, what's going on here? But we have a cleaner code base for it. There really doesn't seem to be a big change in terms of for each individual that's actually working on the project, on average, how many commits are they actually putting into the system? This is an interesting one. I wonder what it means or what it entails. Like Cassandra is not the most accessible code base in the world. So if somebody coming along and on average we say most contributors have like four or five different commits, what does that mean? I just don't know if there's four or five big commits or they four or five small ones. And then they're like, oh my God, my brain hurts. I don't know. But we can chart the whole, how many contributors do we have? And on average, how many commits is each contributor pulling in? And as it turns out, like we're actually fairly steady. So the number of people that are participating in the project is growing and the amount people are engaging seems to be staying relatively steady. I take that as a sign of health, but also there's an opportunity to grow here. There's an opportunity to encourage folks. There's also an opportunity to look at all the tickets that are stuck waiting for review that all of us have and figure out how we unstick them and stop the rebase hell. So conversation-wise on Devat, looking since about 2020, how much are we talking? I probably should have removed myself from this graph because I'm sure I've skewed the thing. My role in many ways is often, like if I hear something from three different people, from three different places, I'm like, okay, this has got to be a pattern. Let's all talk about it. Let's all chat about it on the mailing list and then we'll end up where we end up. But we've been getting more and more engaged over the last few years as a project, communicating with each other and kind of hashing out. Like I know bringing the CPs onto the DevList had a big impact on this as well, where we're actually talking about what we wanna build before we just build it and drop it on each other, which is a plus. So that's a good sign. The user at mailing list has been getting quieter and quieter over time. This is an interesting one. I wondered about this. I talk about it a little bit more in some of the subsequent slides, but one of the things that has set Apache projects apart to me is that holding to the whole, if it didn't happen on the mailing list, it didn't happen mentality. And I get it, right? Like if somebody has a conversation in a slack thread, not everybody sees that. And there's an accessibility problem. There's a archival problem. There's a, you know, if it didn't happen on the mailing list, like there's no way to know everybody in the ecosystem had a chance to actually engage. That's not as true for the user list. Like a lot of governance and voting and discussions of that sort aren't taking place in this domain. So the question for me would be, are the users not feeling served by the user list or are they congregating somewhere else? Not that I'm bearing the lead there. The Cassandra channel on ASF Slack, and I sampled these numbers a few months ago, pretty healthy. It's got some decent velocity on it, just short of 2,000 people then. And then when you look at Planet Cassandra, I had Patrick actually eliminate all the idle accounts from there. We had not quite an order of magnitude more people on the Planet Cassandra Discord server than the Cassandra Slack. Now a spot check of these two systems showed about the same level of conversation. So there's that whole argument of, well, getting onto the Apache Slack, you gotta actually get invited and there's a challenge there and people bounce off that. But the people that end up going through all that may be more motivated to actually engage. Either way, for all of us that are working on the project, we are well served to engage with our users wherever they are, whether that be Planet Cassandra or the ASF Slack and help them as we can. One of the things that's been very enlightening and humbling for me is working with users and hearing their feedback about code that I've written. And I'm sure all of us have had that same sensation where you're like, well, why would anybody ever use it this way? And it turns out most of them do and you were wrong. So anyway, my bid here would be if you're not on the Planet Cassandra Discord server actually get on there. If you're not on the ASF Slack channels for sure get on there, please. And let's just make sure that when users come forward with questions, if there isn't an obvious place in documentation to point them to, there's something we can learn from that. If there is an obvious place, we should help them navigate towards that. Like we need to kind of work on these on-ramps for our users just over and over. This has been our white whale for years. So a vanity metric. A lot of people love DB Engine rankings. This is why column stores Cassandra Steady. Like we've got a niche, we've got a place that we excel better than anybody else. There's trade-offs that come with a primarily Paxos-based Dynamo-based system. But the things that we do well, we do like nobody else, right? Like the availability characteristics, the scalability characteristics are pretty rock solid. Like that need is not going anywhere. And I've been making this argument for, I don't know, probably five or six years now. There's kind of a race between how much dataset sizes are growing and how databases are accommodating that growth. And a lot of people start budding up against architectural problems when you get into really big multi-terabyte, petabyte dataset sizes. And we're just, I mean, we're just moving to more and more and more data. This entire conference, there's half of it. That's like, hey, here's JNAI generating a bunch more data. So I don't see this really going anywhere or changing anytime soon. So yeah, we're in a decently healthy spot in terms of the place where we exist and the places that we serve. Now the introduction of, and we'll talk about it a little bit later, Accord, multi-partition atomicity, the introduction to vector search, we're starting to kind of elbow out of our niche a little bit. But we'll look at those vanity metrics when the time comes. So ecosystem-wise, we've had quite a lot of change this year in terms of how we as a project are kind of positioned and how we relate to different sub-projects. We didn't really have any rules to work with sub-projects before. We didn't really know, like, okay, how do we vote on things? How do we release things? If somebody's working on something, like the driver, for instance, like who would be committers? How would we bring them in? We didn't really have a map for that. So in the last year, we've actually ratified some rules to know here's how we bring new projects on, here's the number of PMC members that have to represent those projects, here's how you become committers on them, here's the social contract. And since that time, I've come to realize there's a bunch of Apache projects that deal with this exact same thing and already have prior art in this space. And there's just this constant turning of the wheel of the old timers with the wisdom that say, well, here's what you'll run into and here's the problems and here's how you should do it. And we're like, hey, we just rediscovered fire. This is great, guys. So it's heartening to see that what we're doing is it rhymes with what a lot of the other Apache projects are doing. And there's a tension between bringing on these sub-projects and not becoming a foundation or an umbrella yourself. I don't think we're at any risk of that, right? Like, nobody's gonna run the Cassandra sidecar without Cassandra? That's just not, that's not a thing you do. So this has been really good to see. We've had a lot of committers come in recently on these side projects. Since I originally pulled this presentation together for Town Hall, the driver donations came through. And that's a huge amount of code, of work, of history. There's a bunch of contributors that are gonna get pulled forward as committers on that because they wrote a bunch of code and that's how we recognize those contributions. Yeah, and it's gonna be interesting to see how this evolves and where we go now that we've got an easier on-rant for folks who are like, hey, I worked on ThingX. You know, I've talked about there's a planet Cassandra website and there's a question of, okay, why isn't this under the foundation? Why isn't this a sub-project? And immediately the response from the folks that are maintaining that was like, that would be awesome, please, I need more help maintaining it. So we kind of need to start thinking about beyond just the core database itself, how do we grow our ecosystem? How do we grow this umbrella and have more people underneath it that are part of this ecosystem that contribute to docs, that contribute to the website, all these other things. It's getting a lot better, for sure. Integration-wise, we've got a bunch of integrations. These are some of the more robust, well-known, mature ones, but you can find stuff all over the place. There's a boatload of different integrations out in the wild for Cassandra. So just had that in here so you can. All right, so the committee itself. As of 2023, we have 73 committers in the project and 36 PMC members. The, to me at least, it's surprising how many PMC members are active out of that 36. And I say active from like, we do a roll call periodically, so we know, okay, when we vote, what does a majority even mean? Like how many of us are following the mailing list? How many of us are staying involved? And it's a good number. So there's a lot of folks that care a lot about this project and that have stayed connected. Some of us have floated away from the project briefly or for longer times and then ended up coming back in to the ecosystem and just kind of can't get away. And it's heartening to see that what we're doing is keeping people engaged and it's keeping them caring and, you know, fighting a good fight. So community-wise, I think we're doing pretty well. We're doing better than we have in the past in terms of bringing on new people and in terms of encouraging, connecting. And part of the, I guess, question to me, proof is in the pudding, like what does that lead to in terms of outcomes? If your community is healthy and strong, then what? Well, it turns out the thing we build, we build it. It's amazing how that stuff all works together. Fun fact, when I was digging into all this stuff in the presentation, there's letters between Ada Lovelace and Charles Babbage where she's like, you need to stop trying to correct my math. Like, let's focus on like what I'm saying, not you trying to nitpick me. It turns out she was right and he was wrong, which I found delightful because that reminds me of our mailing list. But, well, all right, so release is wise. This is a fun one. I like this one. There's Mount 4.0 in the middle. So this is a chart of how long it took us between the previous major to the next major release. And one of these things is not like the other. So as many of you may know, for those of you that don't, you'll get a little history lesson here. Cassandra first started out as basically a schema-less thrift-based database. And the storage engine was not really a storage engine. It was kind of like YOLO, do whatever you want. And it turns out a lot of people had a really hard time with a proliferation of effectively schemas and structures and like micro storage. I mean, the storage engine was its own thing, Erin. It had its own code, I see her face. But, you know what I mean? Like thrift didn't have strong opinion. You could do whatever you want. And a lot of people found it got out of control really quickly and they had a really hard time figuring out, okay, what is in here? How do I pull stuff back out? How do I introspect? This was actually before my time. So long time ago. But that's baked into the bones of the system, or at least it was. And we moved from thrift to CQL, but there was kind of this kluge-painful translation process that took place. And then the storage engine we moved from kind of a thrift-first structure logically to a CQL-first structure logically. And that's where we kind of discovered a lot of dragons and demons and skeletons and all the things that come along with doing a major change in flight, right? Like that's the reassemble the engine as you're going on the highway at 100 miles an hour. What we ended up doing for that three out of four O period was investing a huge amount of energy and resources into testing the system and sussing out what's going on with the storage engine, where are the edge cases? Where are things falling apart that should not be? How do we get to the point to where we have the confidence in this system that we had prior but now the confidence is actually backed by empirical evidence as opposed to hubris? So that's where we went there. Part of that theory was go slow to go fast. And this is a thing that if you're following the dev list and participating, as many of us are, there's a tension with every discussion we have about do we hold to a release every 12 months or do we release when we have specific features or specific functionality we know that are gonna be hugely impacting to our users? There's zero right answer. And this is something that I often say it took my wife Melissa about 10 years to drill into me. Nothing's black and white. Like there's zero right answers. It's all in the middle and like compromise and like disappointing gray space and like great things. I want a clear answer that I'm like, oh, there's the right one. Let's go. That's not how it works. So each time we come up to a release, much like we did with 50, much like we looked at with transactional cluster metadata and Accord, there's this unknowable question of, we had a big gap with 4.0. How much does the world care? How much do our users care? Would they wanna wait six months or another 12 months for a release that had features? Or do they look at it and say, ah, you guys did all right with 4.0 and 4.1 or with 4.1 rather, before one is one release and before that it was like four years. So I don't know. I don't know what the answer is and none of us do. So we've gone back and forth and we've kind of tried to figure out the right compromise for this. And in practice, this is where we reached the point where we said, look, if we cut 5.0 right now and then these features are available in early 2024, we can cut a 5.1 and it's not that big of a deal. It's not the end of the world. The pain comes in with certifying releases. So certifying Cassandra is a big, big lift for places that are running a non-trivial amount of infrastructure. And for folks that are looking at the ecosystem, they're gonna have to make this decision about do we validate and certify 5.0 or do we wait because we know we're gonna be needing the features that are in 5.1 and build based on that. Again, no right answers. So this is something that the release cycle of our database has really kind of baked in and shows this tension and this struggle that we've had kind of collectively as a group. If we look at number of JIRA Resolve per year, again, this is just like the TCM commit where not all JIRAs are the same. But interesting metric, same pattern, spike up, drop down, growing back up. Everything looks like it's healthy. Looks like we're bouncing back. Looks like we're recovering. The new feature JIRAs, I put this one in here because I was curious about whether or not from a new feature perspective we're starting to bounce forward. We are. We have a lot of stuff coming in. There's a lot of things happening in the Cassandra world. It's interesting how that happens. All right, so numbers don't tell the whole story either. 4.0 to 4.1 was a pretty modest change. And there's a bunch of changes in guardrails and denialist thing. And I promise I didn't just put those two because I worked on them. I really was looking at 4.1 and I'm like, what did we do in 4.1 in that year? There's a lot of stuff in there but in terms of new feature tickets inside the system, there really wasn't that much. Whereas 5.0, we've got a ton of stuff that came in, right? We've got the CIDR filtering, we've got the tri-base data structures that Brandemere put in there. SAI, a little thing that we've talked about in Vector Search, UCS, the Unified Compaction Strategy, MTLS. 5.0 is a pretty freaking huge release in its own right independent of the revolutionary monolithic elephants in the room that are us going away from gossip and moving to a new novel state-of-the-art Paxos implementation. So it's kind of like we went from famine to feast in terms of the features in Cassandra. And that pendulum swing, we're incentivized I think right now to make sure that we are careful about what we do, that we are deliberate about validating the correctness of these features, about making sure that the characteristics and the properties that the database proposes that it has, we actually adhere to. Kind of an important detail when you're the backbone of a huge amount of the world's infrastructure. So the transactional cluster metadata in Accord I have here as fast follows for 5.0. That was the whole debate of do we just push 5.0 until they're ready or not? When do we do this? There's that kind of float that we need to figure out. And honestly, it's been a decade and this is the same tension we face with every release. Which is, but we're so close to this thing should we wait for it and we have no idea and we don't know what the right answer is. So the CEP process, we used to have this structure where oftentimes you would get kind of a bomb dropped on you where like as a community, you'd be going along and then all of a sudden the Jiro would open and somebody'd be like, hey, here's this .patch file. And it's like 47,000 lines of code and it does this thing and everybody's like, wait, what? Hold on now, I am uncomfortable with this. In the early days of the project, that worked fine but as more and more people like adopted it and the stakes got higher and higher, more and more you're like, well, hold on, like my whole job is based on Cassandra doing well. And if this destabilizes my workplace, I'm gonna have a bad time. So how do we move away from all of these surprises and also move away from people doing things in isolation, people duplicating each other's work, people having four or five different sidecars existing all across your ecosystem that nobody's talked about. The CEPs have actually, I think, proven themselves. They're accelerating, people are engaging with them. We've seen names that we have not seen before. We've seen new contributors coming forward and proposing CEPs for things. That to me is the real mark of health, right? If it's somebody that has been, you know, putting tens of thousands of lines of code into the database over the last decade, it is not surprising to see a CEP from them. But if it's a new name where they're like, here's a thing that I really have an itch to scratch and I wanna work on this and I understand it, that says something different to me. And we're seeing that. So I consider that a good sign. I've gotta give like at least two, there we go, two clicks. So CI, my personal, emotional and psychological burden. The CI in our system is complex and it is growing and it moves in one direction, it just gets bigger. Nobody ever trims it down, nobody removes things from it. And this is something that I have a personal belief is becoming more and more of a burden that we're all carrying and slowing down our work. Now, all that being said, we're making an immense amount of progress. Mac has done a ton of really, really incredible work on this space to try to get us to where we have a like turnkey, repeatable CI system that anybody can run. I've been working in this space as well myself to try to move us towards a declarative structure where anybody that wants to build something out, they can just kind of socket together the puzzle pieces and just run it. Back in 2021, we introduced this thing called Butler, which lets us look and say like over time for a given test suite. How does it look? Is it flaky? Does it feel consistently? What do we look like for each branch? We got a single pane of glass where we can look at all of our different branches and basically say, are we trending in the right direction? Are we trending in a bad way? The build lead role we introduced in 2022, we've had kind of mixed success with that. For the first, probably six months or so, it was definitely very focused. We have a person signed up, we're doing it. Then there was a bit of a lull and now it kind of feels like there's multiple people in the community that are kind of carrying this burden. So that makes me a little uncomfortable just because I want them to be happy doing things, not necessarily feeling obligated. But anyway, that's neither here nor there. I wanna make sure that we find a sustainable way for us to continue to kind of tie A to B in terms of if we have regressions, if we have failures, are we triaging them? Do we know that they're taking place? Are we figuring out whether the actual product defects and how are we closing that loop? So the repeatable CI is in progress. There's a JIRA you guys can take a look at if you're so disposed. And we've moved the CI scripts in tree. This is something I think is a lesson we've all learned over the course of the last few years. Things that are not in tree with Cassandra may as well not exist for a lot of people on the project because you're like, I'm not really sure where to go. I'm not sure how this links up to that. I don't know what pulls it down. So I'm just gonna keep doing my thing and hope that me not knowing that is gonna be a big problem. So I think we're gonna move away from that. I think we're gonna, we're not gonna like monorepo the massive, I don't know if it's Google that has that, but anyway, our ecosystem is not big enough that this is gonna kill us. But I do think it's gonna be good for us to get a lot more stuff like Harry, for instance, into the tree proper. So all of us, it's like right next door, it's in your IDE, you stumble across it when you're looking up symbols. You know all the ways we enjoy discovering things in our system. So if our community is doing well and it is gradually and gently growing, if the code is going all right and we're getting back into a release cycle, another question is, are we behind the rest of the world? As a database, are features just making up room for things other people have already done or are they unique and novel? So as it turns out, we have a lot of novel stuff like that's the spoiler. I'm gonna keep clicking my button. Is it worth it to have the clicker if it doesn't always work? All right, so TCM, I'm obviously not gonna go into deep technical detail, but Gossip has been an albatross for us for years. And it isn't necessarily Gossip's fault or anybody's fault, it's just the whole like, at the time it was the right choice and it worked well and it has worked well for years and there's better ways to do it, right? Like the trade-offs that come with that implementation in that system have proven to be untenable, unmaintainable trade-offs for us all. So TCM really moves us towards a much better posture when it comes to our ability to, like as Alex said during his talk, move towards a much more elastic system, move towards being able to be much more deliberate about what is housed where, why we put it there, on what scale we actually do that addressability and at what times. Whereas we're not there right now, obviously. The, at the end of the day, like what people care about, bootstrapping more than one note at a time. Some people actually wanna do that, turns out. Expanding and shrinking, anybody that's run a cluster and has done a shrink, you know what I'm talking about. There's some pain there. Like there's a lot that you gotta babysit. There's a lot of hand-holding you gotta do and Gossip plays its part. You know, if you're on on-call shift, it's probably like at least a 50-50 roll of the dice if something bubbles up if it's Gossip related. Like it's, yeah, yeah, it's fun. So TCM, like just that piece of it, super exciting. SAI, secondary indexes for a long time have been the thing where when someone's like, what should I do with it? The answer is disable it. And people are like, wait a minute, what? It's the same thing, like what should I do with the triggers in Cassandra? Don't use them, right? So that we have a lot of things that are in there because they were useful at a point for a use case, but unless you've got a lot of people turning the crank over the years, they don't get the TLC over time. Secondary indexes aren't really that. It's more of like this architecture only goes so far and it's not as far as anybody needs it to go. So SAI fixes a lot of those issues. The, to me, one of the most telling things is kind of right here, the graph of size on disk of indices. For those of you that were around for the launch of materialized views, for all the railing about whether or not the data was correct and whether we've orphaned data and how we rebuild it and the fact that we just couldn't answer a lot of those questions, the real killer was users would add materialized views and not realize it was gonna exhaust the disk space and it started killing nodes and they had no way to know. So disk space utilization that's under user purview with no way to predict it, like that's just a recipe for pain. So SAI is very nice to your disks. This matters and it's good performance and we need indexing and all the other things it does. Like all that stuff is super, super important too. But at least for looking at some of our previous struggles as a system when you're working with data at scale, like you can back yourself into a corner when you have terabytes and terabytes or petabytes of data where you're saying crap, I got an ETL within the own system because of what has happened and how it has transformed over time. So I think SAI is in a really, really good place and functionally like the amount of different indexing that it adds is really, really nice. It's really good. So ANN vector search, for those of you that know anything about the ML space and JNAI, a big piece of what people are looking at doing is how do we move away from just trusting what these models have baked in and instead have it feed me back information that is relevant to my interests, right? Like if I take my own dataset for my business or if you take your own code base and you wanna know where things are, you don't wanna just ask like the sum of all human knowledge they have baked into this cloud, you wanna ask it for your use case and that's kind of the whole point. So the disk ANN algorithm that we're using in Cassandra and ANN search is fast as it turns out. And at least as far as I know, there isn't really anybody that has a credible story about a horizontally scalable, elastic, always available data store that can hold as many vectors as you wanna throw at it. So that puts Cassandra in a fairly unique place at a time when there is more than a little bit of interest in a certain space. This builds on top of SAI and this, at least in my opinion, fits pretty well with our architecture. It's not the kind of thing where we're like, are we just adding something because it's the, it's in vogue, that's not what this is shaped like, right? Like vectorized data is useful and has been useful and there's an immense amount of interest right now. But even if that interest wanes, which most people don't think it will, this is still a valuable thing to have in Cassandra worth maintaining and state-of-the-art. So accord, I am not going to do a disservice by trying to get deep into the explanation on the technical side because this is one of those where it's like, you read the white paper and you're like, I understand some of those words, this is great. It is, there's a lineage in Cassandra, there's a tying of our wagon where we've hitched ourselves with Paxos, where we basically say, look, there's raft, it's out there, it's a great algorithm, but that's not the algorithm for us. Here we play Paxos. And then you look at the lineage of Paxos as it's evolved over time, as it's gone through E-Paxos, which Blake was playing with years and years ago and much like his refactor out the static singletons or it is like, Blake, your patch is very large and very exciting and I'm scared of it. So this has been kind of his white whale in the crank he's been turning for many, many years. Accord is a novel extension beyond where kind of the state of the art and published research was and moves us towards a place where we can effectively have one round trip on strongly consistent activity on our database across the whole system, right? And so that's kind of an unheard of like opening up of multi-partition flexibility. And for those of you that have worked on Cassandra for a long time, maybe you're like me, where your first thought is, oh no, how are people gonna use this at scale in a way we never expected that will be very painful and blow up when they have like terabytes of data and they managed to make everything collide. So we're gonna have to figure out like what's the right way to get this to scale? What's the right way to set up guardrails? We have all these things in place and we'll learn as we go and work with our users. As far as we can tell from our testing and from the proof of the algorithm itself, this is very, very good as it turns out. Structurally, there's a few insights with Accord that make it novel, make it unique and make it smart enough to basically for multiple things that are in flight, figure out what collides, what doesn't, what is it safe to do and what do I have to wait for to do? And I'm just gonna leave it at that kind of high level hand waving woo. But the reality is there is an immense amount of work that has gone into this. There's an immense amount of proof work in terms of a single threaded simulator that confirms and makes sure that the order things are executing actually holds to and adheres to the different commitments and the invariance of the algorithm itself from the proof that we're doing. And if you look historically at all the work that's gone into Cassandra in the past, a CEP with a mathematical proof of an algorithm is not exactly our status quo approach to the things that we do. So it's been really, really cool and really, really good to see how this has worked out and how it continues to evolve. So with all that said, what do we take away from, for those of us that have hitched our wagon to Cassandra or that love to contribute or thinking of building out things on top of it or whatever your posture and your position and relationship may be, users are moving around. They're gathering in different places and we need to meet them where they are, wherever that may be. And I was joking a little earlier today how it's like in the ML space, it's like emojis everywhere. Like every read me you look at is like a wall of emojis and I'm like, well, I guess this is what they're doing now. Like I'm good with it. Let's meet them where they are. So I don't expect Cassandra to be covered with emojis. No, we can be wrong. But again, like the, where are the users gathering? How do we connect with them where they are? How do we, in the space of enlightened self-interest learn from that so we can better make our software serve their needs? We really should do that. Turns out working together is a good thing. Who would have thought? The models that we're using for collaboration on the project are actually being noticed outside of our project. So the Cassandra Catalyst program is something that a bunch of other projects are kind of looking at and trying to figure out, hey, this might actually be something we want to do. The way that we're working with sub-projects and governance is part of that broader discussion of other projects who have sub-projects and they're saying, well, how do we do this? Well, here's the way the Cassandra team is doing it. And that seems like it's gone pretty well. And it's great to have Mick on the project who knows a lot of these folks and can kind of grease a lot of the skids behind the scenes to kind of talk through like what our thinking is and what we're doing. There's an immense amount of work with other projects that happens behind the scenes so we can all kind of learn together and figure out as the industry changes, as these different governance regimes and political regimes change, where do we fit in with that and how do we make sure our project remains relevant? But yeah, collaboration works. Yeah, it turns out testing is useful. Testing is worth it. The shift towards property-based testing and fuzz-based testing has had a massive impact in our confidence with the system. And there's, I think, definitely a lot more work to be done. There's a lot that we need to figure out in terms of the signal-to-noise ratio with what we currently have as our corpus of tests because we don't want to contribute to burning down the earth by running thousands of machines every time we validate one commit, which is kind of our current MO and my axe to grind. But yeah, we're actually in a really good spot. There's nothing I look at and say I am deeply worried. Here's the thing we need to focus on and I think we're doing all right. So that is what I have for you about the state of the Dev community and the project. Does anybody have any questions? No questions. I'm hearing that I am too long-winded and we don't get questions. So thank you everybody. Appreciate you coming out and appreciate everything you do.