Building Community in Open Source with Floor Drees

• Aiven: https://aiven.io
• floor.dev: https://floor.dev
• Mastodon: https://mastodon.lol/@floord
• Twitter: https://twitter.com/floordrees
• dev.to: https://dev.to/floord

Transcript

Announcer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.

Corey: Welcome to Screaming in the Cloud. I’m Corey Quinn. My guest today is a Staff Developer Advocate at a company called Aiven. No, for those who have been following the adventures of this show for a while, I am not talking about Matty Stratton. I’m instead talking about Floor Drees. Floor, thank you for joining me today.

Floor: Thank you for having me. And Matty is my manager, so he’s sort of here, you know, like, by proxy anyway.

Corey: But he’s not actually here, which means there is absolutely nothing that should preclude us from talking smack about him as he oh so richly deserves. Hi, Matty.

Floor: I had this thing not too long ago where we were going to the same conference and he was speaking just before me. And his talk was accepted when he was still at Pulumi and my talk was accepted when I was already at Aiven. But then we turned out to both be working at Aiven at the time of the conference, and I was speaking after my manager. That was scary, yo.

Corey: Part of the challenge as well, when I found that I’m doing speaking on stage in conjunction or associated with someone else is, on some level, you start wondering, okay, well, what was their talk going to be like? And this becomes more challenging when you start speaking at corporate events where, okay, great. So, I’m going to be introduced by a CEO at a keynote, and then they’re going to pass off to me because you want to definitely make sure that your sparkling and scintillating—it’s the reason you were presumably invited to speak—but also, you don’t necessarily want to upstage the person that brought you in, you don’t want to have the energy mismatch, like, “And that’s why kiddies are starving.” “And now our next talk is by Bozo the Clown.” It doesn’t work that way, there has to be some level of making it work.

As well as if you’re both working at the same company, maybe we don’t just give two versions of the same talk hitting on the same themes. Which is not usually a problem, but it’s the stuff that you’re terrified of right before you go on stage and it’s too late to change anything in your talk. And all you can do is sit there and fret. At least for me.

Floor: Yeah. I think we ever really great practice at Aiven though, where we have a speaker’s corner so we can rehearse our talks before, and many of us, we’ve been public speakers for a while, right? We’ve done dozens of talks. But then still, rehearsing it in front of an audience, you get challenged on all of the things that you totally take for granted or you think that your audience will definitely know, and it’s been so useful. And so, I had seen Matty’s talk already, and he had seen mine, so we knew going in that we weren’t all talking about the same thing.

But it does happen, even if you’re not working for the same company. I’m a DevOpsDays organizer and sometimes people don’t show up for the entire conference and they end up [laugh] introducing a product that has already been introduced by someone else, but they didn’t bother to show up in the morning, and that’s painful, I feel like.

Corey: The shortest notice I’ve ever had to give a conference talk on was ten minutes before the talk, the speaker hadn’t shown up. We later found out that the organizer of the conference in question hadn’t bothered to confirm that they received the acceptance email. So, “Yeah, great. Yeah, we’ll accept your talk,” and just assumed that they would know about this. So, can you give a talk about, I think, enterprise DevOps or something like that on ten minutes' notice?

It’s like, so in other words, you want me to stand there in front of everyone, pretend I know what the hell I’m talking about, completely unprepared with no context into what’s going on? That is enterprise DevOps. Of course.

Floor: [laugh].

Corey: And it sort of snowballed from there.

Floor: Love it. Origin story.

Corey: It was entertaining at least. There were no slides, but people somehow think that when you’re speaking without slides, oh my God, they must be an amazing speaker, rather than a horrible procrastinator and woefully underprepared.

Floor: [laugh]. I wonder though, did you give that explanation that this is something you were asked to do on the spot or did you just wing it?

Corey: Oh, I’m always a big fan of, “So, I found out I was giving this talk ten minutes ago because the actual person mentioned on the program is not here.” Because that was the ethical way to do it. The unethical thing to do would have been to go up, pretend I was the person listed on the program and pick fights with people and destroy their career. So, you know, it seemed like that was not really the right way to go. I also think I’d given the morning keynote, so it was kind of hard to hide.

Floor: I mean, so giving talks without a lot of notice is sort of become a more common thing now with the, you know, pandemic and all kinds of crises and, like, stuff happens and people need backup speakers. And I feel like in my profession at least, in developer relations, we should be able to pick that up pretty quickly and have stuff on the shelf if we’re attending a conference, even if we’re not on the lineup if we didn’t make it to the lineup because always be ready to give that talk. Yeah, but I’ve never been given a subject and then be like, “Oh, go.” [laugh]. That’s a different beast.

Corey: I think there’s also a—because this is the stuff that people talk about, it’s certainly one of most visible aspects of it, but it feels, on some level, like, DevRel is perceived as oh, you go on stage and give a whole bunch of conference talks. And in fact, during the early days of the pandemic, there was a bit of a bloodletting of DevRel folks because it feels like they didn’t correct that assumption, even within their companies on some level, where it’s, “Well, we just have these expensive developer-looking people who don’t write production code and go around and speak at conferences all the time. And there are no conferences, so what do we do?” That felt like a misunderstanding of how it works. I mean, people know me for the stuff that I say on stage, but I spend way more time writing than I do speaking. But it turns out that a public writer is not the same thing as a public speaker.

Floor: It’s a good role description, though. Yeah, you do a lot more listening than you do speaking as well, but that’s all not very visible. Yeah, I do think also there are some people in developer relations that just love to travel and being on stage, and they were definitely sort of disgruntled by budgets being cut for travel or travel policies changing. Yeah. Definitely, it was some of that, too.

Corey: Yeah, on some level, it becomes unsustainable, not just in a climate sense but in a lifestyle and company sense. Like, “Yeah, I make $200,000 a year and spend eight times that in travel costs every year.” It’s, “Okay, you get that Zoom is a thing, right?” You can talk to people remotely. Not that it’s great for every conversation, but maybe you don’t need to look at the DevOpsDays events like they’re Pokémon and try to catch them all globally.

Floor: [laugh]. No, I agree with you. And I also think-, and I love that you say DevOpsDays in that context, too, because we have city events, right? And for our city events, also, when we’re looking at the talk submissions, you want to have a good mix of people that are, you know, local to the region and people that are not necessarily from the region. But otherwise, there’s no sense in organizing something like DevOpsDays Amsterdam, if everyone is from far outside Amsterdam and far outside of the Netherlands. Like, that doesn’t make a lot of sense; you want to have some of the local talent as well.

I also feel like especially for a company to send a developer relations person to the other end of the world where they give a talk and they meet with a customer and then they leave again for their end of the world, that sort of like sense of community or that sort of budding flower, there’s no oxygen anymore. And I don’t understand that. You probably do you have some people that are more local or regional that can be mentored into giving more of those kinds of talks, or there must be other times and so we don’t have to fly people around the world because you’re right the planet is [BLEEP] and so we don’t want to be doing that. Yeah, I’ve never really understood that. I’m trying to do a lot of events now that are either online or local to where I’m based.

And if they’re local than if I can travel there by train, then I try and do that. It’s also fun. I don’t know, it can work better on a train than I can do on a plane where you have, I don’t know, even less space, and there’s so much waiting and walk into that corner in that corner and—like, I don’t know. I’m not a big fan of flights in general.

Corey: No, I don’t miss a lot of the constant traveling that I was more or less forced into doing back in the before times, when speaking it was the way that everything seemed to wind up being done. We learned new ways of doing stuff. I don’t go on-site for client engagements anymore in almost any circumstance, just because even now it’s well, there team is in a whole bunch of different places, so what’s the value of flying them all in and flying me in? And in some cases, half the team doesn’t show up so you’re presenting to Zoom anyway. It just always seemed like such a ridiculous rigamarole, on some level.

Floor: Yeah, I was a hundred percent hoping that we would use a lot of the things that we learned during the pandemic time and make sure that our events are more accessible for remote participants once we can go back to in-person events. And in fact, I’ve done a little study for DevOpsDays in my position as a DevOpsDays core organizer to figure out how the different organizing teams in different cities responded to 2020-2021 when they couldn’t meet in person anymore, if they went for a virtual event or if they went for a hybrid event if some of the restrictions in their area loosened, and if, in 2022, or, depending on the region, 2023, will go back in person again and if they will still have that sort of online component. And it’s been super interesting reading the response. For the Netherlands, we teamed up with another chapter that was going on in the Netherlands and then offered a combined online experience. But then going back in person this last year, we didn’t really put a lot of thought into also offering a live stream.

I mean, we’ve been doing that. Like, it’s almost like a no-brainer, but still, it seems to be really hard to get the whole team on the same page and try and offer that for people that participate remote. I heard a response from one of them because I ran a survey with all the organizers of DevOpsDays events, and one of the organizers said that they were afraid that they would not get as many people to their in-person event if they offered it in a hybrid format. So, if they would also offer an online element to their conference, they were afraid that people would just sit on their couch and follow the conference from the comforts of their own home and not join at the conference location. And I think that’s the people that would join from their couch are maybe—and I always think is weird thing because maybe they’re [laugh] [training 00:11:27] from their home office, like, from not necessarily sitting on their couch—

Corey: Home office. There is a couch in my home office.

Floor: [laugh].

Corey: I tend to wind up having both of those boxes checked.

Floor: [laugh]. Perfect. Well, that’s A-plus for setup. But I think that’s probably a very different audience. Like, that’s maybe people that wouldn’t come to your in-person event in the first place, maybe because they can’t do the whole travel, or in-person events are too much for them, or any other reason. But I don’t think that offering an online component is what’s keeping people from coming to your in-person event.

Corey: You’ve been involved in the open-source and community worlds. I don’t want to conflate the two, though it seems that they are inextricably linked in a bunch of ways. You’re a DevOpsDays core organizer, but you also have a sustained and, we’ll call it enduring focus, on the idea of open-source sustainability. What does that mean? It sounds like a bunch of words that someone picked off of a slide somewhere and threw together because it seems that suddenly everyone has their own view of what that means. It feels like a college entrance essay. “But what does open-source sustainability mean to you?”

Floor: [laugh]. I put them on a slide in the first place [laugh].

Corey: Exactly. That’s the true meaning of DevOps as you build the slides rather than just reading them.

Floor: I mean, the acronym is so good, too, because it says SOS, and aren’t we in a crisis?

Corey: Exactly.

Floor: All right. So, I got involved in open-source in the first place when I figured out that—I was just learning to program because I do go and get a CS degree or anything. I studied art, actually, something entirely different. And then fell in love with the internet and then wanting to know how the internet works and built for the internet.

Corey: Poorly, at the best of times.

Floor: [laugh].

Corey: I hear you. It was the original question of, “How does this stuff work?” So, I started learning about networking, and once you go down that rabbit hole, you’re amazed it works at all. So, you just basically used this to—so all that, you rise above all those levels, so then you just use this to basically, like, send text messages back and forth, like, “Oh, no, no. We do our banking here.” Okay. This is definitely something that takes some adjusting period to get used to.

Floor: I love that you’re saying that. I’m actually writing a talk about how I tried to explain to my son—who is eight years old—very poorly about how I even make a living, how the company that I work for makes [laugh] a living, what open-source is. I didn’t know where to start. It was a half an hour of rambling and him rolling his eyes at me. And so, now for a talk, I’m trying to summarize it in five minutes and make it something that actually people would understand. So yeah, fingers crossed on that one.

No, but I entered in open-source, just figuring out that I could make changes to instructions on how to install something and making sure that no one else would get stuck on that issue again, for the setup that I had, if they had the same kind of setup. And that was just such a revelation for me. Like, it was wonderful. People that I don’t know, I could unblock them. What a wonderful thing this is.

And I started looking at more open-source projects to contribute to, to look at. I started working for a lot of companies that had open-source, at least as part of their product offering, and as such started talking to a lot of maintainers. Much later, when I was working at Microsoft, I started a meetup with a couple of friends who were similarly interested in open-source topics. And we had a regular meetup where we’d talk about—with maintainers—about some of the issues that they were facing. So, creating a safe space or how to get more contributors or how to get funding or how to deal with mental health issues in open-source and community.

And from talking to a lot of maintainers, I felt like there were a lot of these topics that maybe maintainers, between themselves were discussing, but wasn’t really apparent to the larger community. And so, there was a little bit of a disconnect of why maybe choices were made for different projects, or why maintainers try to go down a certain route. And it was difficult for them to then navigate that new reality with contributors because they hadn’t taken them on the same journey. And so, I always felt that there’s a lot of things in the tech world that we all take for granted, we always think that everybody understands why we’re doing a certain thing, but we’re not doing a lot of explaining. And if we’re doing explaining, we’re not doing it in a really accessible way.

So, that’s always been sort of my pet peeve and the reason why I do a lot of meetups and facilitate a lot of panels just to get people talking to each other and exchange expectations.

Corey: This episode is sponsored in part by Honeycomb. I’m not going to dance around the problem. Your. Engineers. Are. Burned. Out. They’re tired from pagers waking them up at 2 am for something that could have waited until after their morning coffee. Ring Ring, Who’s There? It’s Nagios, the original call of duty! They’re fed up with relying on two or three different “monitoring tools” that still require them to manually trudge through logs to decipher what might be wrong. Simply put, there’s a better way. Observability tools like Honeycomb (and very little else becau se they do admittedly set the bar) show you the patterns and outliers of how users experience your code in complex and unpredictable environments so you can spend less time firefighting and more time innovating. It’s great for your business, great for your engineers, and, most importantly, great for your customers. Try FREE today at honeycomb.io/screaminginthecloud. That’s honeycomb.io/screaminginthecloud.

Corey: What I have found across the board with I guess community, as events with open-source—and this is going to get me letters, I can already tell in advance—it feels almost like a PTA meeting or something similar, where—like, local town council style politics, where everyone is extraordinarily passionate about what’s going on, but the stakes are relatively small in the grand scheme of things, in many cases. So, you wind up with folks just screaming at each other and it really becomes a thankless job, to some extent. In my time is an open-source maintainer and being deeply active in a bunch of different open-source communities, one of the things that I have found has been very often, the worst customers in the world are the ones who are not actually customers; they’re users. They aren’t paying you anything. And I’ve talked to companies across the board and they see the same thing. The free trial users tend to be far more work than the paying customers.

I mean, I see that on an annual basis as well. We do an annual charity t-shirt drive and I have more customer service challenges during that week that we do that than I do with the delivery of very highly priced consulting engagements. Because, yeah, you’re spending a large amount of money on a consulting project and there’s a challenge, you’re going to pick up the phone and talk to someone like a human being, as opposed to, “This $35 t-shirt for charity is having slow shipping. I’m going to give that person a piece of my mind via email.” And it just—

Floor: Outrageous.

Corey: —it doesn’t go well.

Floor: Yeah.

Corey: Yeah. I used to work at a large web hosting company before GoDaddy bought them and proceeded to ruin them like everything GoDaddy ever touches, Media Temple. And it was never the people spending thousands a month that were the problem. It was the folks at the lowest tier offering we had—10 or 20 bucks a month—calling in and expecting 80 hours a month of engineering work and support and the rest. And, on some level, you really have to let the customers who you clearly cannot satisfy go. Everyone is better off for it.

The problem is, when we’re talking about open-source communities, it’s much harder to do because booting someone from a community leads to drama, everyone picks sides, it ends horribly. But if you don’t do that, you watch everything devolve into the worst display of humanity.

Floor: Oh, a hundred percent, yeah. The project is only as healthy as its community, so if you have very problematic people in there, then you need [laugh] to get rid of them. A hundred percent agree. But I also think, like, some of that is a maintainer starting—or group of maintainers starting with a project where they pour their heart and soul in it and they will respond to everything. But then as a project starts to grow and evolve, they can’t actually put as much time into every single contribution or every single issue or PR filed.

But they have set that sort of expectation that they could, but they can’t. It’s not a sustainable situation, right? Especially when they start when the project matures and maintenance just costs more in terms of resources, money, whatever, and they need to maybe start thinking of a way to monetize [laugh] that thing that they’re working on, either by adding some enterprise plan for it, or a cloud plan, where they offer some support or some differentiating features for it. And then suddenly, they’re spending time on another—almost like another product and are not entirely focused on the open-source product anymore. And that’s sometimes a very difficult pill for less frequent contributors or community members to swallow because they have seen something else and now they have to get used to… their maintainer sold out. They need to pay a mortgage.

Corey: Well, that’s the problem, too, is I think that there is a malaise—and I’ve talked about it in a few episodes of this show over the years—where companies want the benefits of open-source. They want the easy adoption approach, they want to be able to externalize the cost of development in some cases, where everyone who winds up having a challenge with the product like, “Oh, great. Pull requests welcome.” Which is the polite way of saying, “No, you fix it.”

And, on some level, it’s okay, great. So, we’ve had a bunch of people participate in this and now we’ve built something super awesome and valuable. How do we cash out? How do we make money out of this? And we’re seeing that with license changes.

And I have little tolerance for companies that change their license to prevent Amazon from building an equivalent thing. It’s like, first, Amazon does nothing wrong when they wind up taking some of this open-source and operating within the confines of that license. Just because you don’t like it does not mean they’re being a bad actor, first off. Let’s be clear, Amazon does many things that are wrong, that just doesn’t happen to be one. The next thing to think about from that perspective is Amazon does things that hyperscale.

I promise you, they are not grabbing the open-source version of whatever slapping it on some EC2 instances, and here you go; this is a running managed service. In most cases. They are having to tweak it for their own storage substrate, they’re having to work around the constraints within their environment, the fact that a lot of these things are designed to run on 15 different operating systems is probably largely irrelevant to them; they need it to work really well on one. And they can strip out a lot of the optional functionality, dial in on the features that they’re offering, and in some cases, it feels like they’re doing a complete rewrite and just offering API compatibility at most. So, this idea that they’re just going to take your code, do a make build and then start selling it to people is a little misguided as well.

Floor: Yeah. It’s an oversimplification for sure.

Corey: It just seems that companies get lost and wrapped around their own axle on these things. And I do have some sympathy for folks. Like, take Docker as a great canonical example of this. The technology was transformative and great, and there was no real clear path for Docker the company to wind up building an offering around this stuff in a way that was easily and reasonably able to be monetized. And they wound up changing their licensing and their pricing for large companies because their stated goal was they didn’t want to wind up monetizing onesies and twosies here of individuals playing around with stuff. But then suddenly, these large companies get told, “So, you know those 5000 developers you have doing all kinds of stuff throughout the company? Here’s a bill looks like a telephone number, but it’s not. Pay it now.” And it turns out that is not a super compelling sales pitch. I know having tried it myself once or twice.

Floor: Yeah, and I mean, we see different ways of open-source projects also trying to make sure that they can afford continuing spending time on the projects. And sometimes it’s in the form of donations or applying for any of those fuzz funds that are out there. But then also some of the—that takes a lot of time, right? Like, it’s almost like fundraising, and fundraising is an entire job. And you’ll see maintainers being able to spend less time on the project just because they need to make sure that there is a constant stream of money coming in.

Because also if you have money coming in one month and then nothing the next month, that’s a problem. And if I’ve spoken to a lot of maintainers who feel like they need to still continue to write code while they’re also trying to make sure that the [laugh] project is being able to continue in the long run and continues to attract contributors and continues to attract adoption. And it’s like, all the basic things that our company needs to do as well. And we’ve think it’s completely normal that these are roles that people and companies need to fulfill, but then when we see this in open-source projects, no, no, no, no, the maintainers need to continue writing code because otherwise, they’re not maintaining the projects. And it’s hurtful. That’s not a way for projects to grow.

And so yeah, they try other things. They maybe try supporting end-of-life versions for a fee or offer bug fixes or extra features for a fee, or we’ve seen a lot of companies try all these different methods, right, and there is no silver bullet, but it’s important to have the discussion.

Corey: Yeah, because it’s not sustainable to ask people to work for free. I mean, there’s also been an evolution that I’m not sure many individual hobbyists really understand that back in the ’90s and 2000s when a lot of us got started with these things, open-source was very much something that was done by hobbyists. Now, there are very large companies who employ developers to have as their full-time job working on open-source software. Red Hat is the easiest example pick out of the list, but Microsoft, Google, even Amazon has a number of folks whose that is their sole job.

That is a very different thing because, on some level, when a company gets into a space of cool, we’re basically going to be doing this giant open-source project, like, take when Amazon open-sourced all of its documentation. It really felt, on some level, like you’re trying to make your users responsible for keeping documentation updated. I’m sorry, I’m not here to volunteer for what was at the time a trillion-dollar company. Now, their stocks not doing so well, so oops-a-doozy, but they’re still not small enough for me to view them as a scrawny underdog, and want to do volunteer work on their behalf.

Floor: Yeah. I think the response to Microsoft open-sourcing.NET was very similar, like, “Oh, well, it’s the community’s problem now.” [laugh]. “Good luck.”

Corey: Send the postcard if you ever get there. Yeah.

Floor: [laugh]. So, at Aiven, we actually also employ a couple of people that work on the upstream projects that are in our portfolio, like Postgres or OpenSearch. And they work entirely for these projects, they don’t have to relay anything to our product team whatsoever, but it’s still an interesting—I say interesting, where I should really say challenging—position to be in as a developer working on these upstream projects because your timelines are so different from a business timeline, right? Like we work with fiscal years and OKRs and that kind of stuff. How do you set an OKR for submitting to a big project like Postgres?

You have absolutely no way of knowing when someone will actually look at your pull request, or merge your pull requests. So, you can’t say, “Oh, well, so many merged pull requests in this quarter.” [laugh]. The maintainers don’t work on your timelines. And so, it’s still an interesting conversation to have at a business that employs people that work on open-source full time, how to make sure that they continue to pay these people to work on open-source, even if it’s, yeah, it’s on a different timeline. And it’s difficult to explain that to stakeholders.

Corey: One of the dawning realizations that I think that a number of enterprises have had over the last ten years has been, “Well, do we want to use open-source software or don’t we?” Has been met with, “That’s adorable that you think you’re already not in a thousand different places in a thousand different ways. Welcome to reality.” And everyone talks about, “Oh, well no, our developers would never go online and just copy and paste things out of Stack Overflow or grab something off of GitHub.” It’s, “Really you found that the only developers the world who don’t know those things exist? Because as soon as they do, I promise they’re doing that. We all do that.” That’s how this industry works.

That was just met by oh my God, and the company’s trying desperately to do the draconian crackdown thing where any line of code must be originally sourced, at cetera, et cetera. And good luck reinventing those wheels because you’re absolutely going to need it. And I think most companies have evolved past that, but it becomes a very uneasy balance. I always find corporate attorneys breakout in sweats when you start talking to them about it in any real depth.

Floor: Yeah. Or yeah, when you start talking about SBOM and why you should have a software bill of materials, or open-source supply chain security stuff. I had a really interesting conversation, and that’s again talking to the—almost me being in a—definitely being in a filter bubble, where I’m just like, “Oh, well, everybody understands this.” But there was an event and there were some open spaces. And I suggested a discussion round DevSecOps being a Band-Aid [laugh] on a bullet wound because while we should certainly check our codebases for vulnerabilities, we should also figure out where those vulnerabilities come from in the first place.

And I was talking about, you know, license changes and maintainer drain and dependency management and all that kind of stuff. And then suddenly, one of the people in the room says, “Well, but then we could just have a mirror of all the components that we’re using [laugh] in our codebase.” And I was like, “But no. Now, you’re a maintainer of all of these codebases. And also, it’s not like pinning those components at a certain release; make sure that there’s no vulnerabilities creeping in. Sometimes we discover vulnerabilities after they’ve been in a component for a years, sometimes.”

Corey: Sometimes we discover vulnerabilities when reading that morning’s edition of The New York Times I mean, “Oh, oops-a-doozy did I do that?”

Floor: That was fun.

Corey: Yeah. “Log4j? I’d never seen an invoice for that. We must not be using it anywhere.”

Floor: Exactly. So, for me, it’s like baffling whenever I get a response like that. It’s almost like they’re not—yeah, they’re not aware of everything, of all the components that they’re using, all the libraries that they’re using, and that’s a thing that they should monitor and track. And you can automate that. Developers love automation. Why are they not [laugh]—like, I don’t understands. Why do they leave this to sort of the wild, wild west, and we’ll figure it out if something comes along and breaks our stuff? It’s just something that I can’t wrap my head around.

Corey: I really want to thank you for taking so much time out of your day to talk to me about what you’re up to. If people want to learn more, where’s the best place for them to find you?

Floor: They should probably go to my website, which is floor.dev. Floor is spelled F-L-O-O-R, like the floor because in the Netherlands, we don’t think about names that are international. And you’ll find links to my Mastodon, Twitter, dev.to where I write stuff. I try and write a lot of event write-ups—which is a lost art, I feel like, the last couple of years—because I enjoy explaining to other people what I’ve just learned.

Corey: And we will, of course, put links to that in the [show notes 00:30:59]. Thank you so much for your time. I appreciate it.

Floor: Thank you.

Corey: Floor Drees, Staff Developer Advocate at Aiven. 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’ve hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry comment that you will no doubt turn into an odious, badly positioned conference talk.

Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

Announcer: This has been a HumblePod production. Stay humble.