Kate: Hello, welcome to PodRocket. I'm Kate, the producer of PodRocket. And with new me today is Ash Jeffs. Hi, Ash. How are you doing? Ash Jeffs: I'm good. Thanks. Thanks for having me on your show. Kate: Yeah, thanks for being here. And Ash is the creator of Benthos. Thanks so much for coming on. With me also as Brendan, our engineer at LogRocket. Hi, Brendan. How are you doing? Brendan: Hey, Kate. I'm doing great. Kate: Awesome. Yeah. So Ash, you just want to kind of tell us a little about yourself and what you're working on and we can start there. Ash Jeffs: Yeah. So, I am working on an open source stream processor called Benthos and that's pretty much what I've been doing for the last five years or so. And that's been a full-time effort for about two, maybe a bit more than that. And it's pretty much all I'm working on at this stage. Brendan: So, I think it probably makes sense for us to start by maybe taking a small step back and talking about what a system like Benthos is at a high level. What is stream processing? What does Benthos do? What are some of the problems it solves and who is that for? Ash Jeffs: Right. So, the term stream processing can be used to fit in a few different types of system. But generally it means you're writing some software that reads a continuous feed of data in the form of discrete events or messages, whatever you want to call it. Logs, some people call them. And that will be from some queue system is usually involved, so something like Kafka, if that rings any bells for people or NATS, RabbitMQ, things like that. Ash Jeffs: And normally what you're doing with that data varies greatly depending on what the data is and what kind of business you are, but usually it will involve transformations and enrichments. So maybe based on the context of a message, you want to acquire more information from somewhere else, which means you're kind of integrating all these different services and things. And then you either want to put that data somewhere else. So, you're kind of a streaming pipeline with streaming coming in and stream coming out. Or maybe you want to perform some sort of calculation on that data that you use to update some other systems. So, it could be some metric that you are measuring or maybe you want to produce alerts or something like that from it. Ash Jeffs: But the general outcomes of systems vary quite a lot, but there are a lot of commonalities between them. So enrichments often look very, very similar with minor differences. And transformations also the same. They often look, the outcome will be different each time, but the process by which you do it, there's a lot of commonalities between these different systems. So, what I kind of work on is general tooling that tries to find an abstraction around these common themes and just gives you a nicer bundled way of doing all that stuff. Brendan: I'd love to hear a little bit more about the origin story of Benthos. You said you've been working on it for five years in total, full time for two. Could you tell us a little bit about your career and how that led you to work on Benthos and maybe talk about where the project started and where it is today? Ash Jeffs: Yeah, so I was working in stream processing for, I'd probably been doing it for about four years up until that point. This was nine years ago now. And that was mostly working in social media data where we're bringing in the Twitter files and stuff at a company called . Shout out to my DataSift friends. And there was a lot of systems that were kind of just these streaming plugged components in this massive architecture of streaming things. And my job was basically playing whack-a-mole with those services and adding features and adding new items and things. Ash Jeffs: And it ended up getting to the point where, as an engineer, you kind of see the common patterns and you have your own opinions as to what a good service in that space looks like and how it behaves. And it got to the point where I was kind of itching to build a sort of generic tool to solve a lot of the problems that we were spending a lot of time on, as engineers, reinventing over and over again. And unfortunately we just didn't really have the capacity to do that at the company. So, I ended up just kind of doing it as sort of a hobby project for, I think it was about two years that I was just working on it as a side thing and it wasn't running anywhere. It was just me playing around. Ash Jeffs: And this was also about the time that I was kind of experimenting with the program language Golang. And I had a lot of fun with it, but then about two years in was when it was kind of ready to use in production, as far as I was concerned. So, that's when I started having conversations with the company again. We maybe tested it in a few places and once it got to the point where the company was using it, it just sort of spread because obviously it's a generic tool. So once we got use of it somewhere and we kind of proved the concept out, it suddenly solved all these other problems and it just kind of snowboarded from there. Ash Jeffs: And then for about three years from that point... I'm getting all my times mixed up now, but for a while anyway, we were kind of gradually rolling it out across this company and it sort of gobbled up more of these services. And it got to the point then where other companies started using it. And that's when I started getting a bit of an online community. And obviously because it was open source, it sort of encouraged other people to come in and contribute their own stuff. And that's where it's kind of gotten now to the point where it's multiple organizations, multiple teams sharing their use cases and stuff around it. Brendan: So, if one of my friends told me that they were building a stream processor from scratch, I feel like I would say, "That's cool, but aren't there four CNCF projects that already do this?" I'm curious what you see as unique about Benthos compared to other stream processing tools that are out there. And maybe what you needed to be able to do that you couldn't with another tool. Ash Jeffs: The main frustration I had back when I started it was delivery guarantees. And that's because we had quite strict rules about data retention and creating good citizen services. And there were a lot of tools specifically around the sort of observability and logging space that kind of did the sort of stuff that we wanted that we could have potentially adapted. But they were architected in a way where delivery guarantees weren't really a priority at all. So, not really suitable for our use cases. So, they were kind of immediately written off as don't touch, can't use. Ash Jeffs: And then the other end of the spectrum, so this was back when stream processing was just taking off. So, you had a lot of systems, like Spark, gradually translating people from these batch systems to streaming systems. And they were on the other end of the spectrum where they had some stronger delivery guarantees and a sense of resiliency, but they were special towards big distributed processing. And were therefore quite complex to set up. And these big architectural hazards essentially for people to work with. Ash Jeffs: And what we were doing was what you call single message transfers right now, where we're just taking messages as they come and just doing basic stuff. It's just mapping and a few enrichments and maybe stream joins, but not in such a way that you need a distributed system. So, what I wanted was something that was as stateless as these logging tools with proper delivery guarantees. Ash Jeffs: And then things like metrics and logging the sort of general standards on how observability should work were kind of forming at that point as well and changing a lot. And that was a big thing as well. This is like I wanted a service that was going to be easy to monitor. You can just deploy this one binary somewhere. It doesn't need to be distributed. It's stateless. And if you want to scale it, you can just deploy more. And you immediately have dashboards ready because the metrics are all there out the box and things like that. Ash Jeffs: So, it was mostly consideration around usability and just making it operationally simple for people. I was not the person deploying it at the company that I was at. But I was definitely getting my ears shouted at by those people directly. So, it was painful for me, if it was a painful experience for them. I didn't have empathy for them as people, but they made it a problem for me. Brendan: You hinted there that a lot of these tools sort of required you to buy into a whole ecosystem of data formats and ancillary tools and patterns and that Benthos was sort of more pluggable. Was that thing that when you made those decisions, you were thinking of how that would scale to a community of people adopting Benthos in the future? Or were you just thinking about sort of solving that initial problem that you had? Ash Jeffs: It was not really to be honest. It was more I was building it for me really. The priority for me when building this tool was that you're kind of building a garden. It's like a nice, pretty little thing that you can come and spend your evenings working on, as like a Zen space. And my worry when doing that sort of stuff is soon as my problem space changes, if I'm working on some other type of system, I'm going to have to leave my garden behind because it no longer applies. So, I wanted to have a garden that I can take with me wherever I go, if you see what I mean, if that makes any sense. Ash Jeffs: So, having a system that is generic and adaptable and pluggable, it just fit nicely, both to the problem that we had at the time, which is all these disparate systems that needed to be reigned in into some sort of generic solution. But then also as something that, yeah, if I went to a company where they had half the problems that I have now and then some new stuff, I could potentially continue working on this thing maybe. Ash Jeffs: And obviously that does mean that other people can come in and put their own stuff in. But in the early days, I didn't expect that to ever happen because I figured this is just going to be... Because I had loads of open source projects at the time that I just kind of threw over the wall. And you get a bit of feedback, but it's not as if it takes off. And then this one did, but not because I was expecting it to, which it was a pleasant surprise. Brendan: Currently Benthos's homepage says that it's fancy stream processing made operationally mundane. And I think in the past, I remember your headline being something along the lines of a boring stream processor. Aside from that sort of humorous contrast with the really grandiose headlines you get on major open source projects, how did you latch onto this idea of boring software? And how do you define that term? Ash Jeffs: So, I think the people that I'm kind of empathizing with when I come up with this jargon is operations people, which traditionally used to be a kind of separate role at a company. Whereas now we've got the DevOps philosophy where you write the stuff, you deploy the stuff, and you're responsible for the whole thing. And I feel the pain of people deploying and maintaining Kafka, for example. That's almost a full-time job. Just keeping this thing running, all the components, all the moving parts, setting up your own custom monitoring for these things, and alerting and dashboards around that stuff. It's a headache. And I don't like that. Even if I'm not directly the person responsible for it, I don't like the fact that it's there because it's a distraction. It's a frustration for an engineering organization, even if you're not the specific engineer doing it. Ash Jeffs: And I like the idea of... There's loads of new tooling that kind of follows the same philosophy of just being super simple. It's configurable, but it's got sensible defaults. And what I mean by sensible defaults, isn't just it makes a best guess at what you want it to do. What I mean is it's defaults that don't wake you up at 3:00 AM because you forgot to tell it to not explode, that kind of thing. And I suppose it's just a frustration with tooling that is designed to solve things in a way where it's just more complex than it needs to be because that's the more fun problem space. It's the more exciting thing. Ash Jeffs: I just wanted to build a tool that was pretty simple. Didn't really do anything massively complicated. It's stateless, so it can't do anything super complicated. But the point is that solves the vast majority of problems for a lot of people in a way where now you don't have to worry about distributed state and persistence and things. It just works. You just deploy it and you can forget about it and it's not going to wake people up unnecessarily. Brendan: Yeah. And I think anytime I read a page of documentation about a data tool that doesn't start with set up a ZooKeeper cluster, I get a little like spike of joy. Maybe I don't want to dive too far into sort of technical details, but maybe there are a couple interesting things around the software itself that we could talk about. One of the things that really stood out to me as I was reading through your documentation and more information about Benthos was you've added a DSL called Bloblang to the platform where you can essentially script more complex operation and data transforms than you might be able to just with sort of a standard configuration. I'm always curious what's the thought process and maybe sort of engineering process that goes into designing a scripting language inside a tool like that. And were there any interesting trade-offs or challenges you came across when you were working on it? Ash Jeffs: So the biggest challenge, I guess, with making a new language is that people don't want to learn a new language. They've already got JavaScript. They've already got SQL. They've already got jq. Almost everybody who's looking at this tool already has a language that they want to work with. And I actually, I refrained from having any kind of custom language for a long time because I wanted to focus on adding languages that people already knew. So, I'd already had a JMESPath and a jq processor and an Orc processor. And I figured that's good enough for now to do mappings and things. But I knew that for this particular use case, they're not ideal. Ash Jeffs: And one of the technologies that we had at DataSift was a language called IDML and that's open source as well. I think the implementations in Scholar. And it was just really good specifically for data transformations. And the purpose of that language was you've got a payload, probably adjacent object or something. It's structured maybe. And you need to create some new shape. It needs to look slightly differently. So, you've got to be able to do array transformations and things like that. And their focus was on making it user friendly for those transformations, which ended up being a language that looks, it looks kind of like JavaScript, but it's very functional. So, the assignments are very pure and it looks like the kind of language that you would want for data transformations, if you're in a space where... Ash Jeffs: Jq's great. Jq's probably the other favorite for this kind of work. But the problem with the syntax it's better for CLI situations. So when you've got a 200 to 300 line mapping because it's big x data, it doesn't scale as well. And you end up with these fairly difficult to follow things. Whereas IDML was kind of like assignments based. Ash Jeffs: So I always kind of had in my head this idea, wouldn't it be great if I could do it a Go implementation of IDML and just try it out because the advantage of the position I was in was people were already using the service. So if I just stick some scripting language in there and it's optional, it's opt in. You don't have to use Bloblang or anything like that. You could choose what kind of processes you use. It gives people an opportunity to, you're not aggressively forcing it on people. So, you're not going to alienate anybody from this thing existing. You'll alienate some people. Some people just don't like stuff to exist. But most people can just avoid it if they don't want to touch it. So then you can kind of like test the waters a bit. Ash Jeffs: I did deviate from IDML while I was implementing it. That's why it's kind of like, its own thing. But my mentality when I was doing it was the time was right because I had a lot of free time. And I was looking for something to try out. And the project just ended up being easier than I thought it was going to be. So, I just kept on going and then you get the feedback. People start liking it and that kind of drove me to finish it and carry on from there. So, it was kind of like an organic process, I guess, because it was feedback that got me to carry on. I didn't try and force it on anybody. Maybe I did indirectly force it on people, but not by intention. Brendan: Another thing that I think is really cool is that you can deploy Benthos as a serverless product. And there's obviously a lot of really appealing things that a serverless deployment brings for data streaming, not paying for idle, horizontal scalability, easy deployment. But it's not something I associate with data streaming as a space or a set of tools. How did you sort of get the idea to make serverless deployment part of Benthos? And were there any interesting challenges in getting that to work? Ash Jeffs: Yeah, that was actually a really interesting process because the jump from this thing is a streaming service to, oh, actually we could just have this as a serverless function was probably only a couple days of consideration. And it was more just because... So there were two things that kind of enabled it. The first one was the it's stateless. So, you can just spin it up and it's immediately ready to go. So, it's already in a position where it's not complicated to translate that into serverless land. The other thing was the idea of what I call synchronous responses in Benthos world, which is basically you can respond to the input stream. So, normally in streaming it's one way. But obviously you can use HTTP to instantiate streaming. So, you can have an HTTP server input to Benthos and that means you can give a response back. Ash Jeffs: There's also some queue systems where you have request response. So, what I ended up doing for that use case was adding in this mechanism where in the configuration you can express how to return messages after transformations and things. And then somebody just came along and I can't really remember how it started, but I think it was basically just somebody asking, "Can we get this?" I think it was... I can't remember how long it was after, but AWS had announced Go support for Lambda functions. And I think basically somebody just came along and went, "Hey, can we do this?" And the basis of all that stuff was already there. So, I was like, "Okay, well, yeah. We can just try it and go." And it wasn't a lot of work to be fair. The AWS Go APIs are pretty good, apparently because it was fairly low effort. Ash Jeffs: But yeah, it was another one of those kind of organic interactions where somebody came along and said, "Hey, can we have?" And the answer was, "Well, actually, yeah, we can get that for not a lot of effort. So yeah, let's just do it." And all the pieces were in the right place. It just kind of fit. But it's not what you would think. It's definitely not what I intended when I started building this service. I didn't have this vision of and we'll also be able to support Lambda functions. But it fits, so we did it. Brendan: Another thing that's always stood out to me about Benthos is the documentation. It's really clear, it's comprehensive, but it also has a really consistent voice and kind of a rye sense of humor that makes it pleasant to get to grips with, especially after reading some of these other enterprise products' documentation, where it's just sort of pages and pages of configuration. Is that something that you're doing deliberately or comes naturally to you? Do you have a specific vision for Benthos's documentation or is that just kind of what comes out when you sit down to write? Ash Jeffs: It's kind of a coping mechanism, I guess, because I think with stuff like open source, your biggest enemy is burnout. And if you're working on something and it's not fun, that can only last so long before you just stop doing it. So, doing the documentation was obviously a massive necessity for a configuration based service and I wanted the documentation to be really good. So, the way to do that in my mind was to just have fun doing it. And I think early on I had the opinion of, if I plastered humor all around, it's actually going to be a detriment. It's fun for me. And it's fun for some people, but maybe it's not going to be great for people just trying to understand it. I was a little bit worried as well about language barriers. So, people who don't have English as the first language might get a bit confused by stuff. Ash Jeffs: But I figured, well, if I don't make it fun, it's not going to get done, which is obviously a lot, lot worse for people in that situation. So, I'll just do it. And then if people want it to be different, I can look at doing that. And nobody's complained about it. So, I just put sarcasm and dumb humor all over the place. And I will continue to do so until somebody asks me not to, politely of course. Ash Jeffs: But yeah, it's just a, I don't know, there's lots of stuff around having an open source project and as it grows there are things that you end up having to do, similar to a business I guess. That if you don't find joy in doing that thing, then you just end up with a hole. It's just not going to get done because, unless some friendly stranger is going to come and do it for you, which does sometimes happen, you're just not going to do it because you just don't have the energy for it. Whereas enterprise can pay somebody, this is your job. In which case it's just a job. They're writing something to hopefully be concise and specific. So, there's not all the goofy humor and stuff in there. Brendan: That's a great segue to talk a little bit about your experience with Benthos as an open source project and as an open source maintainer. I'm curious when did you decide that Benthos was something that you wanted to work on full-time? And what was your process from sort of having that realization to getting there and preparing to make that happen and actually taking the leap? Ash Jeffs: Yeah, that's interesting because early days, as you said, the marketing was very much about it solves the boring stuff and it's a boring piece of software. And I did feel that I was kind of defensively building this thing so that I wouldn't have to keep solving the same boring problems over and over again. And obviously in doing so that's what I spent a lot of my time doing. And yeah, so at some point I went from I'm just building this thing kind of defensively and having a bit of fun with making a nice clean service with delivery guarantees, that kind of stuff. But then you're still building out this boring. It's not particularly interesting. It's not like distributed computing and all that fun stuff. Ash Jeffs: So yeah, at some point I guess I did make the transition from... I quite enjoyed just making stuff that's nice. So, I do get satisfaction out of that similarly to how I get satisfaction out of working on complex problems. So, I think basically I just kind of, yeah, I just became more and more content with focusing on that stuff. And when you get the feedback, if I have an engagement with somebody where they say, "Oh my God, that thing you did was so useful and I love the way it works. Or it really helped me in a tough spot." I get more satisfaction from that than solving a complex problem and not getting any feedback. So, I think it was just kind of like a sort of organic process of me seeking out that validation and an enjoying it. And it fit. So, I assumed the persona of the guy that does all that boring stuff. And if you've got some ugly problem that you just need a boring solution for, you just go to that guy because he's already done all that stuff. Ash Jeffs: To transition to doing it full time, again, that was pretty organic because I had responsibility for a lot of stuff at this company. And I wanted to make all that stuff redundant by bringing this thing in. And then my life is simpler because I'm supporting this one thing and it also benefits me because it's open source. So, it's kind of like now it gets developed out in the open. And again with the whole garden thing, it means that if I'm putting my efforts into this thing, then it's a garden. I can take it with me wherever I go. And yeah, as it slowly became more adopted at this place, it just ended up becoming my full-time gig. Ash Jeffs: And once it got to that point, it was just a question of what's the best way of continuing this long term? And yeah, the idea of working on open source full-time is definitely not a well established one. There's no clear roadmap for becoming an open source developer and there's lots of different ways of organizing that. For me, it's just a very complex mess of sponsorships and bounties and contracts, so just consulting contracts for organizations adopting it. But yeah, and I've got no idea where it goes. I have no idea how long I can ride this train for. But yeah, it's working out right now. So, that's all I really care about at this point. Brendan: Now that you've been doing it for a while, what is a typical day for you? What do you wake up and do? And how do you spend your time beyond just hands on keyboard, writing new features? Ash Jeffs: It really depends. So, there's obviously the stuff that I have to do, contractually obligated. That stuff gets done. And then as far as everything else kind of assembles, it's pretty much where my head is at at the time. So if I'm not in a mindset to be thrashing on a keyboard, implementing the next thing, then I won't because again it's like burnout is the enemy. So if I'm not enjoying what I'm doing, then it's going to send me down a pathway and it ends basically. This whole thing shuts down. So, I don't mess about with doing stuff unless I'm enjoying it. And luckily with open source, there is a wide variety of things you can get done if you're not coding and that's community buildings, answering questions and stuff like that, drawing goofy pictures, obviously writing documentation, stuff like that. And videos, I do tutorial videos and things. Ash Jeffs: Just in those things, there's a wide variety of skill sets that you can just have fun messing around with. And because it's open source, you don't have to do a perfect job at any of it. And people still are accepting of whatever effort you put in. So yeah, that's typically what will happen is if I'm in a mindset where I want to get some stuff done, never force myself to. It's only if I feel like I want to do it. Then I will just get a feel for what kind I want to be doing. Usually it is code, usually it's writing stuff. But if not, then I'll just think about, well, what would be fun at this time? And there's always something that needs to get done. So even if it's just drawing goofy pictures, there's a goofy picture that needs to be drawn for every page in the documentation site. And I'm not there yet. Brendan: You've mentioned burnout a couple times now and I think at least two or three times a year on the front page of Hacker News there's a story about an open source maintainer dealing with burnout and just the sort of demands of supporting a community in your software. Is that something that you have sort of developed as specific toolkit to deal with? Or how do you keep yourself from getting burned out? Ash Jeffs: So, I'm definitely well versed in burnout. And the way... I guess I got kind of like an addictive personality where if I'm enjoying something, I find it very difficult to stop doing it. And I don't think I've solved it. I've definitely got ways of avoiding it for myself. I'm not necessarily sure they would translate well for others because I just think it's such a personal thing. Ash Jeffs: But basically you've got a hobby that you enjoy doing and there is nothing stopping you from just doing it 24/7. If I was super into electronic engineering, there's only so many components I can store in a house. And if I run out of components, I've got to order some. There's a physical limitation there and my fingers will get sore if I'm messing up around with stuff. So it's like you can't do it as much as you can software. You can still get burnt out from it. But not to the same extent. Ash Jeffs: With software, I'm only limited by how quickly I can smash a keyboard and sleep. So, I think you basically spend the first few years of your engineering life cycle not thinking there is a burnout limit and probably thinking that this doesn't apply to you. And I don't think it does apply to everybody. But I think the problem with it is you don't you've hit that burnout spot until you're already there. At which point, what do you do now? Because this thing is your job as well. Ash Jeffs: So, the way that I prevent it is different to what I did to kind of recover from it. But to prevent it you just have to rotate and force yourself to do other things. You have to have other hobbies. You have to have things that force you way from the computer. And obviously, families, adventure, holidays and stuff are a good way of doing that. But also just rotate so you're not always working on the same thing. You're not always doing the same kind of problems. Ash Jeffs: Some people do that by messing around with different languages and stuff. Others never work on a project more than just a few days or something. But then when you failed and you have burnt out, just get away. If you can not work, then don't, if you can take a holiday for a week or two weeks or something. It's not something I would say you do yearly, but obviously if it's an emergency and you've burnt yourself out, the best way I've found to deal with it is just get away completely. Entirely remove yourself from the equation. Ash Jeffs: In open source that does not work because you have people using it. So, you've got issues, poll requests, questions, things like that. And I just think that's probably just the reality of open source. The bigger your open source project is, the more you have to be preventative or you just go cold turkey for two weeks and just tell people. I think Benthos is at the point now where I have tested this already. There are some great members of the community willing to answer questions and things while I'm not present. Shout out Mihi. And I know that if I needed to get away for a week, I could rely on those people. But to be honest, even if nobody was answering questions for a week, I think most people would get on fine. Brendan: Okay. Speaking of that community, when I last on GitHub, I think Benthos had 106 contributors. How have you approached building a community of developers around the project? Is that something that's kind of happened organically or do you actively work on growing that community? Ash Jeffs: I don't. Other than making the content, I don't really do an awful lot to try and entice people or draw people in. Historically, I've always just relied on word of mouth. I'll make the occasional outreach posts. So, a lot of the attention that I've driven into the project has been my videos, which is sort of like digging into the code base kind of things. But yeah, most of it's just been organic. Ash Jeffs: And I think that the trick really has been making the developer experience just as frictionless as you can. So if somebody come along and they have to ask 10 questions before they're at a point where they're able to contribute, they're blocked. And most of the time they're going to be blocked. Any time there's some sort of exchange that needs to happen between some member of the community and somebody who wants to contribute, that's another opportunity for it to fizzle out before they've reached some point where they can actually add something to the project. Ash Jeffs: So making the code base super accessible so people can just come in and know pretty easily where they need to go. The code base isn't perfect. I like to think that it's moving towards simplicity and ease of contribution rather than the other way. But most people seem to think it's fairly easy to contribute. Ash Jeffs: And then when somebody's got a poll request, if it's sat there and it's ready to go, then I'll try and merge it as quickly as possible before things fizzle out. Because that's the main enemy of getting contributions is either party, me or them, losing steam and just figuring, eh, I haven't heard anything for a month. So, I'll just forget about that poll request. Sometimes that means me getting it over the finish line, if there's just one or two little bits that need to happen before something can get merged. But yeah, I think it's basically a challenge in trying to be as responsive as you can without burnout. Brendan: And a final question. I don't think we can let you go without talking about Benthos's mascot, the Blobfish. For my money, probably the best open source mascot anywhere on the internet. Ash Jeffs: Thank you. Appreciate it. Brendan: I can't do it justice in audio format, but it's this just dour, pink blob that perfectly represents the kind of vibe of the project. Is there a story behind it? Is that something you already had lying around that you were looking for a use for? Or did you come up with it for Benthos specifically? Ash Jeffs: It's not a self portrait. I'm just going to start with that. I didn't have it lying around. So, the way that I do... I love mascots for open source projects. That's one of my... Some people really like naming. I'm not that first about names. I'll just use Wikipedia and just go on a journey clicking links until I find a word that is Googleable and doesn't get you some other piece of software. But the mascot, I love them. Ash Jeffs: But the way that I do it is I will just pick a random object or animal and then just make it look goofy. So, sometimes that's getting something really ugly and trying my hardest to jazz it up, often with big eyelashes and cutesy eyes. Or in the case of Benthos, I just loved the idea of having a mascot that just looked really sad just by default. And just looked really, I don't know, just really down, like a proper downer. You bring up the GitHub page and you're immediately met with something that just doesn't want to exist. Ash Jeffs: And the brilliance of open source is I don't have a marketing team that is screaming at me, "Don't do this, please. This is going to ruin us." And I don't have investors or anything who are like, "We don't think that works well. We don't think that plays well." And I don't think software is particularly plagued by those things anyway. I think most companies get away with pretty goofy graphics and things. In fact, they're almost definitely encouraged to do it nowadays, especially. Ash Jeffs: But yeah, the brilliance of open source is you just put something out. And if it's terrible, you just change it. If it's great, people will say. I think with the first I did change it once. So, it started off... The mascot's always been a blobfish that's just kind of squishy and sad. But it was different. And then basically it got to the point where it was like, okay, I'm keeping this now. I'd established that people in enjoyed the look of it generally. And I figured I'm going to try and spruce this up, just so it looks a little bit more graphic designy, a little bit more professional. And that's what we've got now. I think it's been that way for four years now. Ash Jeffs: My wife is a graphic designer. She has assisted me in making some of the variants. She's not a fan. And I think she finds it a mockery of her profession and there's rumors out there that she's the one that made the original blobfish. And that is absolutely incorrect, unsubstantiated claim. And I will fight that in court if I need to. Kate: Awesome. Well, thanks so much for joining us. And if there's anything you want to point our listeners to or plug, we definitely want to give you the chance to do that. Ash Jeffs: If you've got a stream processing problem, then maybe check out Benthos.dev. But yeah, I don't really have anything to plug other than that. That's the only thing going on in my life. Kate: Where can people find you on Twitter or... Ash Jeffs: Twitter, I'm Jeffail. GitHub, I'm Jeffail. And YouTube, I think my YouTube channel is Jeffail. But either of those places will take you to all the others as well. For people interested, you can find me. I'm on the internet. Kate: Awesome. Well, this has been great. Thank you so much for joining us and we'll see you around. Ash Jeffs: Thank you for having me. Brian: Thanks for listening to PodRocket. Find us at PodRocketpod on Twitter. Or you could always email me, even though that's not a popular option. It's Brian@LogRocket.