One of the things that we've been seeing inside ElastiCache is
we're trying to contribute more of our, you know, performance
features, our efficiency features back into open source, because
we think that helps us make the overall system more stable
Welcome to Screaming in the Cloud.
I'm Corey Quinn, and it is a pleasure for me once again to speak with
Madelyn Olson, AWS principal engineer and core maintainer of Valkey.
Madelyn, how have you been?
Oh, I've been delightful.
Thank you so much for having me back.
Well, I, frankly, I'm astounded and grateful that you agreed
to come back on the show because we gave a talk at re:Invent,
and usually that's when the knives come out afterwards.
Like, I can't believe you said that on stage, but apparently people liked it.
One of my favorite things about our talk was that everyone came up afterwards,
and everyone wanted to talk to you, which is just so… It's so nice.
Everyone usually wants to talk to me.
It's okay.
I can be an introvert and just walk away.
It has its advantages and disadvantages.
Sometimes people wanna say something kind.
Other times they want… Like, the thing that drives me nuts is right
after you step off of a stage, and people wanna give you harsh feedback
on the talk, which is helpful as a speaker, don't get me wrong, but give
me 10 minutes first to wind down from the high of having given the talk
or, you know, ask me to sign their chest or get a selfie or smell my hair.
Eh, okay, it gets a little interesting, but we run with it.
Oh, it's true.
I have, you know, have to deal with my small share of fame being
one of the Valkey maintainers, but I'm sure you get much more of it.
Hey, you're the one that got me into the Redis party.
That was fun.
Uh, I think they would have let anyone in.
Entirely pos- That's the beautiful part about being open source,
then not being open source, then barely being open source again.
So I have some questions for you because
so much has changed in the, what is it now?
Six months since re:Invent, give or take, where back then a lot of people
were throwing AI pull requests to open source projects, and it was slop.
I mean, no one would pass up a sl opportunity to wind up
YOLO coding something at, that, that doesn't freaking work.
And at some point in that interim, it feels like something
has shifted, namely the AI-generated code started being good.
What's it like as the maintainer of a project people actually care about
and contribute to, to, to be, I guess, facing that, that rising tide?
So we definitely saw the increase of pull requests
coming a little bit late last year, but by and large they
were, as you said, the PRs were not very good quality.
They had obvious mistakes.
They also often… They were often trying to find issues inside the project.
They'd, like, go and search through the issues and
find something, and they would kind of just send the AI
agent at it with a one-shot being like, "Go fix this."
And the result were what you would expect.
They were low quality.
They didn't make very much sense, so we
kind of quickly were starting to close them.
We definitely noticed about three to four months ago
that the average PR quality was both increasing a lot.
Basically, average engineers were able to point their, you
know, Claude Code or Kira or some other types of harnesses at,
with the foundational, like, Opus models with, from Anthropic.
They were able to point them at these issues, and
they were actually producing semi-decent code.
And that started causing a lot of pain on a lot of open source
maintainers because that took a huge amount of effort to sort of
review and think through, 'cause the AI models still aren't great at,
like, making sure the code is adhering to, like, sort of the ethos
of the project, but it's much better at being technically correct
Which is, of course, the best kind of correct.
Of course, it's the best kind of correct.
So yes, it doesn't crash, but it also is gonna be hard to maintain.
AI models still love generating code, so even if there's
a perfectly good function you could rewrite a little bit,
they're gonna totally just go off and build their own.
My favorite thing with like Claude Code is, so the whole Valkey
project is written in Tcl, a archaic language, but the, the…
Sorry, the infrastructure, the testing is all written in Tcl.
The AI loves to just write its own Tcl frameworks every single time if you don't
like hold it to the fire and you're like, "No, you have to use the framework
we built." It loves writing new Tcl tests, but that's not very maintainable.
So we definitely noticed in the last couple of months that they actually started
doing a really good job of like, you know, kind of getting almost the way there.
And so we've seen about a 50 to 60% increase of actually decent
pull requests getting opened in the last couple of months.
And that's sort of been the big thing we've been trying to deal with,
like how do we as a open source project deal with this, these increases in
contributions that w- take a lot of maintainer time to actually think through?
'Cause they don't have bugs, they just kind
of aren't great, but they're not bad either.
I, I have found that one of the problems with AI-generated code
historically is that people continue to make the same fundamental
error about AI that they have been making for almost four years
now, which is, "Hey, this thing talks like a middle manager.
Therefore, it must be self-aware," instead of the proper
conclusion, which is that middle managers are absolutely not.
Where people hate AI slop, in my experience, from
a, from a narrative perspective, has been when it
presents as mediocre, as milk toast corporate speak.
If you throw whimsy into it, people find it delightful.
Uh, my AI-generated code commits are no better than anyone
else's, but I will say that my commits are the ones that have
conspiracy theories about the code in the commit message.
'Cause if you're gonna put out slop, at least be funny about it.
Oh no, for sure.
People hate the, the, the… There's like that speak that especially I
think, you know, ChatGPT got known for that, you know, every time you're
like, "Hey, that's just wrong," it's like, "Oh, you're absolutely right.
I just didn't do what you told me to do." But if you throw a little
more whimsy in it, it is, it can give much funnier responses.
It's like, "Yes, I am deliberately trying to sabotage you." It's a lot more fun.
Everyone has been talking about Mythos
because it's a brilliant marketing campaign.
We built this amazing model.
Oh, too scary to release.
Special people can have it, but not you.
And it, it's become this weird, uh, I have something super special.
Can I… Can, can other people see it?
No.
Then you had, uh, GPT-55 come out, which apparently is similar, only
other folks get to use that one, and it has definitely re- raised the bar.
I will say that I have the numbers on this, which I'm sure your
friends in AWS PR are gonna love me for, but I've done visualizations
on the number of CVEs that AWS has published on an annual basis for
the last five years, and we are gonna cross a threshold this month.
For the record, we are now at the beginning of May
Yeah.
So AI does have a great ability to go and force multiply in
a way that individuals can't, and I think where I was kind of
talking about, like, the harnesses around the MLs have gotten
a lot better, and, like, I don't have access to Meet Those.
I don't know anything that I can share
publicly about, you know, access to Meet Those.
But inside the Valkey project, we've actually been quite successful at just kind
of, you know, taking, you know, the frontier Opus models and being like, "Hey,
just go read through this code very deeply. Try to come up with hypotheses about
what might be exploitable," and then trying to… Then do- go try to fix it.
We've been actually generating a lot of PRs
and fixes recently inside the Valkey project.
I think the total's up to, like, 25 or 26 in the last month or so of not
CVE caliber bugs, but, like, of real bugs, like memory leaks and unintended
server asserts by just, you know, trying to, you know, use a lot of tokens.
You know, I- it's nice that at Amazon I'm able to burn kind of as many
tokens as I want sort of doing these deep evaluations of the code base,
and we've been able to do… use that to find bugs, and I'm sure Meet
Those is the same, and I, I think AI will really help us harden the code.
Oh, it has.
I mean, my, my code is no great shakes, but my internal system
for writing the newsletter is open to the public, and I finally
decided that I had some spare cycles left in a session, and, all
right, I'm gonna go ahead and do a security audit of this thing.
Uh, so the passcode to get in is a UUID.
It turns out that anything of the appropriate length would suffice.
Like, okay, that, that's not terrific.
Uh, again, the, the blast radius is somewhat
minimal on this, but still not a great failure mode.
And then I found a bunch of other stuff, which, where it
gets into the stupid things I don't really care about.
Like, hey, because I'm the only user that has access
to this, but I could potentially prompt inject myself.
It… Great.
Or not prompt inject, but you know what I'm talking about.
I could effectively… I could do SQL injection against
my own code base where I have admin rights anyway.
That's not the threat.
Randos coming in off the internet, more of a threat.
No, yeah.
And one of the great things about AI is it scales really well.
So you can use it and go and hunt down all of these things at the same time.
Obviously, the ones, th- those threats that you talked about, like, the
false positive rate's still the real problem that we're dealing with.
I mentioned, you know, we were able to find, like, 25 or so bugs inside Valkey.
That's nothing compared to how many false positives it generated.
It generated, like, 150 false positives.
It was like, oh, if, you know, this variable somehow got
modified, then you could, you know, cause a remote code execution.
I'm like, yeah, but that can't…
You can't modify the code that way.
That's not how this, this works.
But, you know, my expectation is they're gonna keep getting
better, and we can keep using these tools to basically
harden the systems that we rely on, which I think is cool
I, I will say it does feel like it's gotten harder to contribute to open
source given the proliferation of AI, which, which is counterintuitive because
it has never been easier for me to ha- find something annoying in a project
in a la- written in a language that I don't know, you know, English, and
then I can basically bully the AI into writing a pull request against it.
But I worry that if I do that, then I'm actually part of the problem because
no matter how much I work on that and tweak it and, and get it to do the thing
and add tests and do all, and jump through all the hoops you're supposed to,
there's very little signal, you know, other than the conspiracy theories,
to differentiate this from any other slopportunity people are jumping on.
Yeah, and that's, that's a very fair and valid concern, and I don't know
if we've really figured this out in Valkey yet, but one of the things that
I know I've seen a lot with other maintainers is they've been a relatively
slow embrace of AI 'cause they've seen these, you know, waves of slop.
They, they don't like dealing with them.
They often just close them.
But I have seen more of a shift recently.
The various maintainers in Valkey, I work
with a maintainer from Google named Jacob.
He started using AI to do a lot more reviewing of the code.
We also have an engineer from Erickson who's been using
Kiro, uh, along with Claude to do more reviews of the code.
And so I think right now it definitely feels like there's this
tension, but I think that we're kind of all trying to figure out
what the future of open source development looks like with AI.
And I still appreciate when someone is trying to fix a bug.
You don't, you're not required to submit a p- PR.
You can also just open an issue, and one of the nice things
about generative code is, you know, I can also just go try to fix
your bug with my own GenAI, so you don't have to deal with it.
But I still appreciate when people try to open PRs.
So I definitely don't want people to start feeling like that's
Like they're contributing to the problem by trying to help.
Most people are good intentioned.
The people I really don't like are the people who like use
like OpenClaw and like they just point at the Valkey project
and they're like, "Yeah, just go try to fix all the issues."
Like generally those issues are there 'cause we'd like
people to learn about the project, get involved in the
project, or maybe they're issues that aren't very important.
So the people that just use AI to, you know, brute force and try to solve
lots of problems are the people that are really causing the problems, not
the, not the average individual who's trying to make the project better.
So I wanna talk a bit about it.
It's now two years since the launch of Valkey, and in
some ways it has succeeded from the customer perspective,
uh, the biggest concerns that folks had with Redis.
One was the attempted rug pull.
Great.
Awesome.
The, the community made a definitive decision to fork, which is
great, and that in turn unblocked a lot of features that, not to sound
uncharitable, it felt like Redis was intentionally holding back as a form
of business model protection, and now the open source version is awesome.
How has it been from the other side of it?
Because I'm, I'm just the customer, and to be direct, I'll
use whatever, uh, whatever version of this that my AI agent
picks most of the time, but you see it very differently.
Yeah.
So the first year after the fork, there was definitely
this big open question of, "Hey, will Valkey survive?"
Right?
Most forks don't work out.
Most forks fizzle out.
And one of the great things we did see about Valkey is it did end up
surviving, in part because it was sponsored by a large number of organizations.
We had a very diverse community that was helping build it.
And we even s- did see some validation when Redis
ended up moving back to AGPL so quickly, right?
They moved from a very permissive license
to, to proprietary license back to AGPL.
And the users from our project that saw that kind of saw that as
validation that, hey, like, the Valkey project is… It's real.
People are thinking about using it.
And over the last year, we've seen basically more and more
adoption of the project, 'cause people are seeing it stick around.
They're seeing it build functionality
that, you know, wasn't showing up in Redis.
The things you mentioned, you know, like we built LDAP support, which was
a long time a proprietary feature of Redis, and, you know, that helps build
a lot of confidence that we're willing to build stuff that end users want.
I was even talking with a, a financial company this
morning, and they're like, "Hey, we're now all in on Valkey.
We'd like to talk about it.
We have some v- very esoteric features that
we were never able to get merged into Redis.
Like, can you help us merge it?" They're doing some… They
basically want, like, a chaos testing, like API and Valkey,
so that they can better verify their availability guarantees
of the pro- uh, of their service when the cache goes down.
And those are really cool things.
And so, like, you know, the power of Valkey right now is still its community.
And as I said, we're seeing more and more adoption.
We're still seeing… We recently cro- crossed 100
million container pulls of the product overall.
If you kinda look at the graph, it's been, like, a nice upward
exponential graph as, you know, we see more and more adoption.
Oh, yeah.
And as I mentioned in our talk that we gave, which I'll throw
a link to in the show notes, uh, that there was a… They were
pulling a number of, of upstream commits from Valkey into Redis.
It has become the new… Uh, actually, Valkey has become the
new Redis upstream, which is a terrific example of success.
So for those who are not able to look at the show notes,
this is OPN 309, titled appropriately, Disagree in Commits.
And we'll throw a link to that into the show notes because of course we will.
And yeah.
And, you know, Redis is still taking commits from us, uh, which is great.
We love to see it.
You know, it's, it is definitely affirmation that what we're building is
valuable to the end users, and we kind of believe in our long-term ability
to continue to, you know, build things that our end users find valuable
And that's important.
It, it comes down to the customer obsession approach.
So I, I guess the, the counterpoint that I, uh, that I want to bring
up here, the sort of the elephant in the room, such as it is, when
everyone can have the AI service wind up writing and submitting
code with less and less human effort, uh, several things happen.
One of them is GitHub falls down more often than grandma.
I get it, scale is hard, and yet the other piece of it is that you wind
up with a tidal wave of, I'm going to be uncharitable for a second, crap.
How do you, how do you fight that?
How do you push back against that upswell of massive nonsense?
You know, one of the things that's great about AI is its non-determinism, right?
If you ask it to build a thing, it'll build it 10 different ways,
which is counter to what we want in what you just described, right?
We want determinism.
We want things that stay up, stay available, and, like, don't break, right?
Which is basically things like writing tests, writing automation.
Like, one of the things that's important that, you know, I was really
internalized while I've worked at AWS is, like, we have huge suites
of automated testing that does chaos testing, that does, you know,
regression testing and, like, that's something that we need to be
using AI to both write tests for, to do ver- verification against.
Like, one of the things I mentioned is Redis is able to pull commits from
us, but we're not able to pull commits from them for licensing reasons.
And one of the things we built is some tooling around basically every commit
that gets opened to Valkey, we check to see if there's any chance that that
commit might have originated from Redis by comparing it against hashes of the
code base And that's important for us 'cause, like, we really d- wanna make sure
we don't accidentally pull a commit 'cause it's very painful to unwind that.
And then also stuff, you know, like we've been using
AI to, you know, write a lot of regression testing.
We built… We used AI tooling to build fuzzing against the Valkey
system to basically test how, how it behaves when various nodes fails.
And so, yes, on one side there is this rise of just non-deterministic generative
code, but we can also use that ability to generate deterministic code that
we can verify that our systems are working the way they're supposed to.
You know, that's where I'm spending a lot of time thinking about right
now is how do we use these tools that we were given to basically harden
all of our production systems, both through the security stuff I was
talking about earlier, as well as availability and, you know, testing.
Well, well here's the question too, where I can take a look at any
open source project now, or even any, any closed source product, and
with enough time and poking of Claude Code and the tokens to back
that up, it can spit out effectively a quote-unquote clean room build
where, all right, I just rewrote your closed source thing as an open
source implementation, or I have taken your open technically or source
available technically code and now I have built a version that I
can do whatever I want with because it is not a one-to-one copying.
There's no code reuse here.
It is a re-implementation from first principles.
That has always been theoretically possible, but a massive amount of work.
Now it's just a medium amount of tokens.
How is that changing things?
The differentiation that I still see, right?
So you can make kind of the same case about Elastichash, the managed
service I work on, and the differentiation that we really see is
that we've been running the service at scale for well over a decade.
And you don't get that by just pointing Claude at
the API endpoints and say, "Hey, reproduce this.
Reproduce what this is working on, how this, you know, behaves behind the
scenes." Like, one of the things that we've been seeing inside Elastichash
is we're trying to contribute more of our, you know, performance features,
our efficiency features back into open source, 'cause we think that helps
us make the overall system more stable, 'cause we get more eyes on the code.
The value proposition of open source, that you having a collective group
of people trying to make code better, is still true in the age of AI.
Like, more people are reviewing it, more people are thinking about it,
more people are trying to hypothesize and come up with improvements.
So yes, the cost to write code has gone down a lot,
but to be fair, my job has never been writing code.
Like, I haven't been writing code for seven or eight years, right?
Like I, back when I was, like, a college grad, I wrote
a lot of code myself, and the fact that that's gone down
significantly doesn't mean I'm, like, producing 10 times more.
I like to make the joke that I can write code 10 times
faster, but I'm about 20% more efficient, 'cause most of my
job is just showing up to meetings and arguing with people.
Me too.
What ma- but the weird part is I'm not invited to
those meetings, which is neither here nor there.
Ah, but you're still appreciated.
We're happy you're there.
You bring some levity to it.
Oh, exactly.
I try.
Um, I have seen a massive proliferation on, in various online
fora of people vibe coding some SaaS thing, uh, where it's
clear that they do not know the first thing about the deep
scale problems of this space, and throwing it over the wall.
And, and I wanna be clear here, I'm as guilty as anyone.
In fact, if you go to deploybar.app, you can see something
I built where my platypus hangs out in the macOS deploy
bar and just has a persistent notification whenever GitHub,
Vercel, or GitLab, uh, are doing a CI/CD run, and it's free.
Now, if you wanna pay five bucks a month for it, Billy will stop
making fun of you, or alternately, for the masochists out there,
he'll really care and go much deeper into making fun of you.
But the utility remains free.
It's the snark and the cynicism, and I think the innovative business
model of pay me or I won't be nice to you is, is kind of a good approach.
But, but that's a bit of an edge case exception here, because
so much of it is just I, I vibe coded this thing last night.
Who knows if I'll maintain it or not?
Pay me money, please.
Yeah.
I, I'm not very optimistic that those are gonna stick around.
I mean, I'm sure some of them are, you know, finding unique
markets and, you know, part of, you know, the whole startup world
is trying to find product market fit while you still have cash.
And so, you know, I, I do believe AI will help find…
help companies find that product market fit faster.
But I'm sure a lot of them are just gonna go nowhere, right?
If your goal is to try to just be a, a shallow copy
of AWS or GCP, it's gonna be very difficult, right?
AWS has so much institutional knowledge about how this stuff works that it's
gonna be, you know, 'cause the years we've run all this stuff in production,
it's gonna be hard to try to copy it just by pointing Claude at it, right?
Claude wasn't trained on, you know, a lot of this information,
so it's trained on just kind of open source stuff.
And a lot of that stuff is, you know, just
random stuff that people wrote on GitHub.
And
I think that that's not terrible.
I'm giving a talk somewhat soon, and a key thesis behind
it is the idea that the AI bots are terrible at writing
Terraform because there's no good Terraform out in the wild.
Uh, I… To be clear, I've seen a lot of great Terraform,
but it's always for companies that have learned what
bad Terraform does and spent the time to explore it.
I'm sorry, I should say OpenTofu now, but still, it's, it's the same
principle where it, it struggles to do things correctly in that space.
And when it comes to infrastructure at least, there's a blast
radius here that there isn't as much in other disciplines.
That's true.
And I mean, the… I know the big trend these days is to build skills to
help with that type of stuff, build MCCP servers that can provide these
skills sort of on demand, and they help shape the LLM so that they do the
right thing instead of relying too much on their, their training data.
And, you know, we've seen some good adoption of that.
Uh, for example, we have an engineer working on building a Valkey skill.
So it's one of the problems that the LLMs have is knowing
what's a Redis feature and what's a Valkey feature.
It very quickly thinks they're… It like, you know, sometimes thinks
Valkey features are in Redis and vice versa, uh, 'cause it doesn't…
A lot of this information is in the foundational model, so it's in
all the training data, um, and it struggles to differentiate them.
And so skills help be like, "Hey, this is a Valkey feature. This is a
Redis feature." And that stuff also would, you know, will hopefully solve
a lot of these problems we have around stuff like Terraform and OpenTofu
There is a future here where a lot of this stuff
slips below the surface level of awareness.
Now, that has been the case for a long time.
Uh, we go back to the late '90s, and building and running a web server took
an in-depth knowledge of GCC compiler flags and the better part of a week.
Then RPM and Dpkg came out.
Then Yum and Apt came out on top of them.
Then things like Puppet and Chef and whatnot came out, and it was simply
just, you know, ensure installed, and then it became a checkbox on S3.
And so things that were hard today become easier yesterday.
That has been an ongoing trend.
I guess I didn't think that I would necessarily live to
see a world where an entire app fit into that bucket.
I don't know how much you were ever using, like, the early GPT models,
but I used to use GPT-2 and GPT, uh, the early versions of GPT-3
that OpenAI produced, uh, to help do, like, D&D tabletop campaigns,
and, like, that's about a decade ago when this came out, and the rate
at which they've kind of been evolving is faster than I expected.
But I imagine we'll continue seeing that type of
progress, and yeah, as you said, I think those types of
workloads will become commodities in not too much time.
What do you think is next?
Because I, and I wanna be clear here, five years ago, if you had accurately
predicted what the current state of the world is in terms of open source,
in terms of software development, you would have sounded like a lunatic.
With that in mind, what do you think the next five years looks like?
I do hate making predictions, but I'll, I'll do my best.
I definitely see an increasing trend of the, you know, like, the
cost of writing code continues to come down, and by cost, I mean
both, you know, in terms of token, how much time engineers are being
spent, but, like, the high-context individuals who are driving a lot
of this stuff still are driving it like they were a few years ago.
So I kind of do expect to see just more and more, like,
high-velocity Individuals sort of making a lot of stuff happen.
So like the people that are able to, you know… Like
the Alaska service I imagine will have fewer people, but
they're able to drive more stuff, build more features.
And I imagine more of that will happen both
like in the startup world and individuals.
I haven't used like OpenClaw or those types of tools too much for
my personal life, but I imagine that will become more ubiquitous.
Like, I think we'll see a lot of just the same, of just, you know, being
able to force multiply through AI, having it be easier to do, have them
all… Like, one of the big innovations that happened recently was just
like you could basically prompt the Claude code and it will figure it out.
I imagine that'll continue to happen sort of in all aspects of life.
But like that's kind of what I see happening kind of across the next five years.
Like this is the first time I think I would ever say that I
don't really know what's gonna happen five years from now.
Yeah.
I'm, I'm hoping it sorts itself out before the time my elementary
school kids have to enter the workforce, but we'll find out.
Uh, I, I will say you can probably make some better predictions because,
again, Valkey is open source and it is not AWS controlled or restrained.
What's coming in Valkey?
That is much easier to make predictions about.
So the Valkey project, the main things we're
working on are basically improving durability.
So Valkey has, Valkey and Redis have historically had a durable
version called append-only files, which was pretty much self-instance.
We're trying to make it a durable multi-node distributed
system, and this will allow people to actually run stuff.
Like we kind of want to replace Kafka workloads.
We would love to replace stuff like some very
simple key value primary data store workloads.
There's some interesting use cases and stuff like vector similarity
search where you actually do want the indexes durably committed.
So those are the type of things that we're building out.
We're trying to also… You know, the DRAM
shortage is, you know, on everybody's mind.
One of the big things that's been on the Valkey project's
roadmap for a long time is figuring out how to natively store
data onto SSDs without impacting latency and performance.
There's been a lot of innovations in the last couple of years that have made
SSD read latencies like Very competitive with RAM, like sub 10 mil- microsecond
reads, um, which is still 100 times slower than DRAM, but as long as you
carefully orchestrate how you're fetching the data, it's can almost be free.
So those are the two big things we're working on as a project.
But yeah, we're al- always hopeful to get more things.
Those are features that are probably gonna
come out in the next six to 12 months.
And of course, there's a lot of other stuff.
We're releasing Valkey 9.1.
It should be out by the time this pod comes, podcast comes out.
That adds performance improvements, memory efficiency stuff.
Those are the bread and butter that-
Well, that's putting an awful lot of faith in
GitHub, uh, staying up long enough to ship a release.
I'm sorry, that's unkind.
Fair, 'cause it's very expensive, but unkind.
I, I sh- I wasn't gonna complain about GitHub,
but I'm still not gonna complain about GitHub.
Uh, all the current problems we're having are our own problems.
We're trying to release when… As, as of recording of this podcast, we're
trying to do a, a, a patch release of Valkey and it is taking forever.
I'll be direct.
My problem with GitHub right now is they are simultaneously
saying that it is not their fault because they are being slammed
by a deluge of AI stuff, which I believe and it's sincere.
However, they're also shoving Copilot at anything that
holds still long enough, and many things that don't.
So it's, it feels like you, you don't get to
sell the problem and then complain about it.
I mean, that's capitalism, right?
Oh, it is.
I just… It's, I, I sit here and I shake my fist and it makes me angry.
If, if people wanna learn more about what you're up to and what's next in the
exciting world of Valkey, where's the best place for them to go to find you?
Best place to find me is probably on Bluesky.
I'm reconditerose, uh, bluesky.social.
You following the Valkey project, valkey.io, there's
a blog section which we publish relatively frequently.
We've almost gotten enough content that we have a weekly blog release
cadence about everything new and exciting on the Valkey project.
Uh, LinkedIn is also a great place to follow both Valkey and me.
I mostly just repost stuff, but it's kind of what's going on in the project.
We're, we're planning to ho- uh, host a Valkey
event, uh, at the Open Source Summit in May.
That will probably not… Maybe we'll be in time, but more
likely we're hosting a, an event called Unlocked this week, but
there's also gonna be another one in Prague, hopefully in Q3.
So we're trying to organize that.
So if you're interested in coming and learning a lot more about
Valkey, we're planning on hosting an event there later this year.
Wonderful, and we will of course put links to that in the show notes.
Madeline, thank you so much for taking the time to speak with me.
As always, it is a pleasure and I'm looking forward to the next time.
Excellent.
Hope I, hope I wasn't too AI-pilled for you.
Not yet.
That's okay though, 'cause I'm gonna write conspiracy theories about it myself.
Madeline Olson, AWS Principal Engineer and core maintainer of Valkey.
I'm cloud economist Corey Quinn, and this is Screaming in the Cloud.
If you've enjoyed this podcast, please leave a
five-star review on your podcast platform of choice.
Whereas if you hated this podcast, please leave a five-star
review on your podcast platform of choice, along with
an angry comment that no doubt will present as AI slop.