Screaming in the Cloud - Episode 49: Open Source Software: Slipping Beneath the Surface of Awareness

Episode Date: February 20, 2019

Does operating system (OS) choice even matter anymore to most people? Especially with the emergence of serverless and containers? Debian may not see its name up in lights much these days, but it’s still very much front, center, and relevant to what people are doing in Cloud environments. Today, we’re talking to Elana Hashman, a Python packager and Debian developer. Everything inside a base operating system may not be interesting to end users, but such a collection of components is necessary to create a functioning Linux system. Some of the highlights of the show include: Alternative Linux operating systems, including Amazon Linux 2 Level of awareness about free software when choosing and distributing an OS What is a Python packager? How do you become one? Python is the new default language due to growth and adoption of its ecosystem Packaging community off-putting to beginners; find someone who understands the system to guide you Links: Elana Hashman Elana Hashman on Twitter Elana Hashman on Mastodon A tale of three Debian build tools Python Python Packaging Authority PyCon Debian The Debian Women Project Docker Red Hat Fortran Amazon Linux 2 Go Perl SaltStack OpenHatch SCALE Jordan Sissel on Twitter DigitalOcean .

Hello, and welcome to Screaming in the Cloud, with your host, cloud economist 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. This week's episode of Screaming in the Cloud is generously sponsored by DigitalOcean. From where I sit, every cloud platform out there biases for something. Some bias for offering a managed service around every possible need a customer could have.

Others bias for, hey, we hear there's money to be made in the cloud. Maybe give some of that to us. Digital Ocean, from where I sit, biases for simplicity. I've spoken to a number of Digital Ocean customers, and they all say the same thing, which distills down to they can get up and running in less than a minute and not have to spend weeks going to cloud school first. Making things simple and accessible has tremendous value in speeding up your time to market. There's also value in DigitalOcean offering things for a fixed price. You know what this month's bill is going to be. You're not going to have a minor

heart issue when the bill comes due. And that winds up carrying forward in a number of different ways. Their services are understandable without spending three months of study first. You don't really have to go stupendously deep just to understand what you're getting into. It's click a button or make an API call and receive a cloud resource. They also offer very understandable monitoring and alerting. They have a managed database offering, they have an object store, and as of late last year, they offer a managed Kubernetes offering that doesn't require a deep understanding of Greek mythology for you to wrap your head around it. For those wondering what I'm talking about, Kubernetes is of course named after the Greek god of spending money on cloud services. Lastly, DigitalOcean isn't what I would call small time. There are over 150,000 businesses using them

today. Go ahead and give them a try or visit do.co slash screaming and they'll give you a free $100 credit to try it out. That's do.co slash screaming. Thanks again to DigitalOcean for their support of Screaming in the Cloud. Hello and welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined today by Alana Hashman, who's a Python packager and a Debian developer. We're going for alliteration today. Welcome to the show. Great. Alliteration, my favorite thing. So you've been doing a fair number of interesting things that are, we'll call it cloud adjacent for the moment, just because if I call it

anything else, I'll get yelled at by people writing in to, well, actually me to death. Great. Let's start at the beginning. Well, a little over a year ago, you became a Debian developer, which is first, awesome. For those who are unaware, that's not exactly an easy thing to become. A lot of open source projects tend to have a certain hierarchy of how they're structured, how things wind up getting into production, especially when you're a large, well-known baseline operating system that extends into the underpinnings of a good portion of the internet. It turns out that you don't want someone like, say, me, writing arbitrary code and submitting that into the thing that runs banking software. So that's no small joke. Can you tell us how you got there? Oh, that's, it was a terrible journey. I spent like

a long time being very resistant. Many folks were like, Alana, you're smart. Like we need more women in Debian. You should join Debian. And I said, well, that sounds like a lot of free unpaid labor. Why would I want to do that? But then the technical challenges sort of piqued my interest. And so I guess at the beginning of like January 2017, I started working on packaging some Clojure software. And like fast forward, I don't know, almost two years at this point, and I maintain almost every piece of Clojure software in Debian. It was very interesting because I actually became a DD in a pretty short, as far as things go,

period of time. Normally, you have to wait at least six months to become a DM or a Debian maintainer who has limited upload rights. And then you can wait another six months and become a Debian developer with upload access. And I sort of tried to bypass that process and said, but I'm only uploading new packages, because I'm trying to get this like new thing, the closure package manager called line again into Debian. So I don't want DM permissions, because I'm not maintaining existing things, I'm adding all these new things to the archive. So somehow I managed to convince folks of this. And so it was almost exactly six months from my first package upload with the help of a sponsor up to actually getting upload rights into the archive. The process, like there's no hierarchy

in Deviant. That's the problem with Deviant. It's this massive anarchist collective with a lot of rules. So convincing that you too should be one of the thousand or so folks that's considered a member of the project can be challenging and full of rules mongering mostly. One thing that I wanted to ask you about is for those who are unaware or don't have a deep history of operating systems and Linux backgrounding. Debian is an operating system that underlies a lot of existing things in the cloud today. For example, Ubuntu is built on top of Debian as its upstream package. So although it's not generally seeing its name up

in lights much these days, it very much is front, center, and relevant in 2018 to what people are doing in cloud environments. So my question for you is, in 2018, as it draws to a close and we look into 2019, does the distribution matter? In fact, even taking a step beyond that, does the operating system matter as people's environments and managed services start to move up the stack into things that are very aligned with, oh, I just write some code and it runs serverlessly, or here's a container, I don't care what you run it on. Does the operating

system choice even matter to most people at this point? Well, I mean, I suspect to most people, no, it doesn't matter because it's underneath the surface. It's not something that they're going to be consciously interacting with. But I mean, I've heard, you know, container Linux, it's going to take over everything. No one's ever going to have to run an operating system anymore. We've got immutable infrastructure, right? We've got like atomic OS, and we've got Khoros and all this wonderful stuff. But you're running Docker containers on those. And what are your Docker containers built on? Well, it turns out that the vast majority of Docker containers that are not Alpine-based are actually based on Debian.

So you get that base operating system, whether or not you think you do or you want it. A lot of the stuff inside the base OS is not necessarily super interesting to an end user, but this collection of all these terrible CABIs or application binary interfaces, them working together, them being distributed such that they can all be like compatibly dynamically linked with applications, you don't get a functioning Linux system without that these days. And I guess until we sort of replace C as the lingua franca, we won't. So I mean, but whether it's Debian or a Red Hat based system, or one of many other Linuxes, it's kind of hard to avoid somewhere deep down in the stack. And I don't think that we have any good alternatives at this point for such things.

There is an argument to be made over in AWS land where, oh, just use Amazon Linux, or I'm sorry, updating myself now, use Amazon Linux 2. For those who aren't aware, first, I envy you. Secondly, that effectively takes upstream Red Hat slash CentOS and then winds up layering a whole bunch of nonsense on top of it into a Frankenstein style of distribution and spitting something out that supposedly is highly optimized for the Amazonian environments in which it runs. To my understanding, they're starting to build a lot of other services on top of that operating system and those images. And now that you can download it and run it in other environments, great! Except no one in their right mind does that.

So you've effectively built an entire distribution of Linux that only exists in one particular cloud environment, with the caveat that it is effectively the largest cloud environment by a landslide. So it's not quite as silly as it would be if Ted's Bar and Grill and cloud hosting service were to do the same type of thing. That is the only real competitor that I've seen these days at large scale cloud to Ubuntu, which of course is Debian derived itself. Yeah, it's funny, because like the concept of a proprietary Linux distribution is just like, it's almost like a mock oxymoron, right? Like, the concept boggles my

mind, why would you want such a thing? And so it's weird, because like, I don't really think that Debian is not a commercial product. Debian is a bunch of people who care about free software working together to build a free operating system. The core of Debian is all 100% free software. Anything that you can install in the Debian world, you can build it from source. Even if that requires some level of bootstrapping process, you can do such a thing. Amazon Linux sounds like probably not the case. I mean, who knows? The user space certainly doesn't have to be free software, they can stick whatever they want in there. But I don't know that like,

Debian doesn't really care about commercial competitors, or I think commercialization at all. There was a big controversy a few years back about even getting folks paid for like very core work that they needed to do on the OS. So it's almost like an irrelevant question, I guess. But I mean, I work on Debian because I use Debian, I care about free software. And like if packages that I want to install don't exist, I would like them to be in Debian. Now I have the ability to go and upload those things. But yeah, I don't know. Like I mean, in terms of the commercial applications, it's not really something that I think most DDs are thinking about. I think that it's one of those areas that, as so many things in computing seem to do, it's slipping beneath the surface of awareness for

most people. And it's easy to say that that's a bad thing. It's easy to say that it shouldn't be that way. I disagree. I think that the fact that I don't have to sit here and spend two days and a lot of work figuring out what compiler flags to set to get a particular web server software up and running is a good thing, by and large, for technology, by society. But we also, some ways as a byproduct of that have lost sight of the incredible amount of work by huge teams of people on an ongoing daily basis that underlie the systems that we have all built business solutions on top of. Yeah, it's I mean, I think it's a good thing. Like, I don't want to have to every time I run a new application be like oh yeah look at my compiler flags dash oh five dash fun roll loops yeah like I don't want to have to think about that stuff and as a developer I especially do not want to have to fight with you know oh I have this simple version

error because like I don't have the right ABI's available and I need to go and recompile everything like that is just a massive pain in the butt And so there's me as the OS developer who says, I want all of these things to work compatibly together. And I want to do some like terrible gross yak shaving in order to make sure that like my base OS works. But then there's me as a developer who says, you know, I just don't want that to be a problem that I have to think about.

And if folks don't have to think about Debian, because it is so seamless and magical that it just works. I mean, I think that's amazing. I think it's a big win. I don't really care about like, you know, do we have the right name recognition? There's definitely some reasons that one might want name recognition. But I don't know, I don't know what advantage it would convey. Certainly as like a woman on the internet, I don't actually want name recognition personally. So as far as my software that I write and or maintain goes, maybe it's similar there. But I think it's like a great thing that like, and it's almost even a testament to Debian's stability and quality of software that people don't have to think about any of those details.

They just work and you don't have to care. Except when they don't, of course, then maybe you have to care. Everyone loves having caring inflicted upon them. The best kind. So one of the fun things that I find is as we start going down this path to figuring out the operating system that you wind up running, the distribution of that operating system, if it's not Windows, for example. That's one area of, I guess, choice that's slipping beneath the sea. The one that very much isn't is the other half of what you wind up doing, which is you are a Python packager. I know almost nothing about what it takes to become a Python packager. So let's start at the beginning. What is that?

Oh, sure. So I'm a member of the Python Packaging Authority. And what that means is that I have commit access to certain projects that enable folks to be able to distribute Python. And the history of Python packaging is very long and colorful. And I think my first talk I gave, like as a professional out of university, was at PyCon. And I was talking about some workshops that I had done teaching folks Python. And I said at some point that, you know, like, for students who didn't have a lot of experience with like programming in general, the concept of putting together a Python package and distributing it, that was very, very challenging. And so like, maybe consider that in your curriculum. And a bunch of folks from like, Python packaging, they sort of came after me,

one of them came up to me and said afterwards, you know, I subtweeted you about saying mean things about us. I'm like, I'm not, it's not mean, it's broken. Like, it's just bad. So I guess curses to me that I would end up working on some of that core tooling a few years later. So the stuff that I do right now is mostly focused on Linux and focused on binary distribution of Python extensions. So for example, something like NumPy, a very important library for scientific Python, and it has a bunch of binary components that it needs to call out to. Python is not necessarily super fast. You're doing all these numerical computations. What would be more appropriate for such a thing than Fortran,

right? So how do you distribute Fortran dependencies as part of a Python package? Well, you need to like compile it and you need to like dynamically link to those Fortran things. And that story becomes very, very messy. And it's the kind of thing that like, you know, most people really, really don't want to have to think about this. And so for many, many years, you know, you like shouldn't have even considered trying to like pip install NumPy, because it would be a disaster as you try to compile all this stuff inside the Python package, and it wouldn't work. But one of the projects that I work on is called the many Linux project tool that I'm currently the maintainer of called AuditWheel.

And these two things work together in order for people to be able to compile these super compatible, relatively portable Python binaries and these ancient Docker images, and then audit them and like vendor any dependencies they need, and then be able to distribute those and they run on almost any operating system or almost any modern operating system, hence the name many Linux. So I don't really I mean, I guess I package the Python packages that I maintain, I package audit wheel, but I don't tend to do a lot of like, it's not like with Debian, where there's this, like this upstream package that I am now the downstream of, and I'm adding some stuff and making it work in an

operating system context. In the world of Python packaging, I actually write the tools to enable people to do that packaging themselves. Something that I find fascinating is, for better or worse, Python has become something of a lingua franca for almost everything done in cloud. It's been one of the approved languages on Google's side for a long time. They're pushing Go a fair bit lately, but for most of what people tend to be doing in cloud-based environments, Go tends to be a little low level for a lot of the outcomes they're looking for. Whenever I need to write something, I find myself in 2018 reaching for Python. The only other language I've ever felt that way about was almost

10 years ago, and it was Perl. Turns out that was the wrong pony upon which to bet. But it seems now that we're really in a place where Python is the default language. Yes, there's an argument to be made that some cloud providers focus on other things. But right now, every time I look, and that might be selection bias, it seems to be Python. Is that what you're seeing? Yeah, I mean, it's sort of incredible how much adoption there's been and how much growth there's been in the Python ecosystem, especially with some of the like bumps and tumbles from the Python two to Python three transition. And I really like the Python community. And I think that's one of its strengths. Python as a language has, I think, like a lot better governance than average.

And it was sort of super interesting to watch Guido rage quit recently as BDFL and things for the most part, just continue along as normal. It's funny you mentioned Perl, because I feel like Amazon internally is still like run on like, you know, silly string and Perl scripts or so I've heard. And I feel like this is true in a lot of cloud contexts. But in most contexts, I've worked, yeah, Python. It is the go-to language. So all the more important that the tools that make it work, work well. I don't present myself as a software developer because first off, my code is terrible. And secondly, I find that that doesn't tend to capture what I do these days. But I still find that one day I woke up and people said,

do you know Python? No, I don't. But you did this wrong, this wrong, and you fix that, you'll find it works. But oh my God, I know Python. And it turned into a sort of a shocking awareness for me in that that is, it's not quite hit the point where when I have a problem, the first thing I look at is Python. Again, I'm an old, grumpy systems administrator. I go for Bash first and foremost. And when that runs out of steam, then I step out to Python. I mean, you have a somewhat similar background yourself, to my understanding.

Yeah, I mean, I guess, like, I mean, long, long ago, my first programming language of all time was like MercScript when I was a teenager and chilling on IRC a bunch. But my Python experience was really weird because I picked it up in order to work on this open source project that's now winded down called OpenHatch, which was this meta open source project that was dedicated to getting more folks involved in free software. And I started working on the website, which was written in free software. And I started working on like the website, which was written in Django, some of their they would scrape various like bug databases for projects and try to aggregate all of these what we call bite size, or like, you know, good first issues, that kind of thing. So I worked on that for a bit. And then I did some interview in Python for some company. And I came out of that,

like, you know, an initial phone screen or something like that. And I came out of that thinking, you know, Python, like almost reads like pseudocode. But man, I guess I really don't know Python, because that that interview sort of like crushed myself a seam. Like, I don't really understand how to do object oriented code in Python. I've been in this soft, comfortable world of playing around with Django. And then again, like a year later, you know, folks would see this Python code that I wrote, and they would, they're like, this is very good code. So they'd expect me to know all of this, like, sort of deep Python language stuff that I didn't know at all. Things like, you know, how to put a package together, and like, what libraries were good in what context,

you know, sort of like the arcane stuff you learn as you become more of an expert in a programming language. And it was just so wild to me that I could appear to be so fluent in a language that people would expect me to know these things. And so like, there's definitely something to be said about how easy I think Python syntax is to pick up compared to other programming languages. The fact that you could like, I mean, that's like the ultimate imposter syndrome, right? Like I apparently wrote code so good that people think I know things that

I really don't. Right. Normally to pull that off, you have to be something like an economist or whatnot where it's like, so, so you're just giant fraud messing with people. How long, how long do you think you can carry that out for? It's like, well, I have four books published so far, so we're still waiting. And it turns into this whole, people don't catch on to some extent. On the other side of the coin, there's also the story of going in for job interviews, by which I mean the terrible form of job interviews, where instead of tell me what you're good at and we'll talk about that, it's, I'm going to pick apart random code you write under stress on a whiteboard because that's how most of us write code day to day, on a whiteboard with a marker while people judging the future of our career look on condescendingly. It becomes a very surreal experience. I've

shortcut my way out of taking jobs that require me to do that just because it's, no, I don't feel like performing like a dancing bear on command, you can go ahead and find someone else for this role. I used to think there was something wrong with me. And no, no, those interviews are actually terrible and stressful. Yeah, I mean, it was, it continues to be challenging for me, because I've never written code in such a way. And I mean, Python is frequently a good choice for some of these questions, but also not like it doesn't lend itself very well to like questions that want you to recurse a bunch. And like, I mean, then I go and reach for some sort

of lisp in my toolkit. And they say, you can't write this. That's not a real thing. I say, well, I wrote production lisp for two and a half years. And they say, No, that is nonsense. Closure is not real. And I say, Okay. But yeah, the whiteboard coding, I mean, certainly Python, there's so many more details you don't have to take care of when you're writing your various answers for interviewing questions in Python. It really does read like pseudocode in a lot of cases. And so I don't know if that really forced me into like figuring that stuff out more. Certainly, I still feel like I'm a terrible whiteboard interviewer, but it is handy in that context. Absolutely. To tie together the two areas that you've focused on, specifically Python packaging and Debian development, I dabbled early in my career, for those who've had the special joy

of working with SaltStack, I was the first Ubuntu packager for this. And the reason that that happened is back in those days, I was one of the first dozen or so developers to work on the number 15, and no one else was there. So, all right, I need to run this on a Ubuntu-based environment. I guess I'll build a package for this. And then I sort of started dipping my toe into the murky world of how that worked.

And I spent about half a year doing that. And then the project got large enough at the time to start attracting the notice of other people. And some Debian developers came in and, oh, let's see what you've done. Oh my God. And they very politely told me to let them handle it and never, ever touch it again. And it turned out that, yeah, there's a lot of challenging minutiae to getting a package like that up and running. And everyone has an opinion on it. And it turns out that's not really a great starter package. To be very direct, I found

that in many ways that despite people attempt to be polite, the experience is fairly off-putting. So what advice would you have for someone who wants to get into doing stuff like that so that they have a better experience with it than I did? Yeah, that is a great question. A lot of the packaging communities have, like not just Debian, not just Ubuntu, there are these reputations of being very off-putting, unfriendly to beginners, and I don't think they're totally undeserved. The policy can be almost impenetrable. You have to have some level of background in understanding Linux for these things to make sense and like historical context around certain decisions. And then there's all these social rules,

which are like also somewhat impenetrable. My advice would be to find someone who understands the system and has your back. I frequently get questions from folks now who know that I know the Debian and, you know, Ubuntu systems, so to speak. And they'll be like, can you help me with this thing? Like, I filed this bug, and Ubuntu isn't listening to me, and they don't understand. And this is really frustrating. So you know, I'll go and reach out to them on IRC and have a chat about it and

then comment on the issue or test the patch or whatever, making everybody happy. And having somebody to like watch out for you to like to help you avoid the social faux pas and to guide you in the right direction and to show you the various parts of policy that you need to care about like that, honestly, I think is your best bet. And that was to a large extent, like how I figured out a lot of this stuff. Some of it was certainly just dredging through policy and trying to figure it out. But a lot of it was like, you know, hey, so and so, can you help me with this package? Or I tried to build this thing, but it didn't work. And policy says this, and the man page says this, and they contradict each other. Can you please help me

with this? And folks tend to actually be pretty welcoming and understanding when you go ahead with that sort of approach. And it is unfortunate that there has historically been sort of a almost hostility towards newcomers making mistakes, not knowing. I mean, it's so much to know. Of course, people are going to make mistakes. But I think that as a community, we're working on that. A lot of the documentation around this stuff is awful, too. One of the things I noticed pretty early on. I mean, it doesn't exist. It doesn't exist at all. Yeah. Or worse, I found there are four different ways to build Debian packages, and the documentation I found kept shifting between them without saying, oh, but if you're going this way, no, no, it's just one sentence

to the next would change perspective on different tooling, different approaches. And I read this five times. And at that point, I'd been working in technology for almost a decade. I wasn't babe in the woods when it came to this stuff. But it was very clearly a, there's something wrong here with either my reading comprehension suddenly, or these documentation pieces are terrible because they assume this giant body of knowledge that was never explicitly explained. I wrote a blog post called a tale of three Debbie and build tools in order to, because a bunch of folks were bugging me. They're like, how do you build packages, Alana? And I'm like, ah, I guess I build packages a lot of different ways. Huh? Didn't really think about

that. And I like pick these things up. Like, you know, initially, I started with get build package, because it doesn't require root, and it has reasonably good documentation. And it's relatively friendly. Then people were like, well, you can't use that to build, you know, a package to upload, you should use p builder. Like, okay, what is p builder that, you know, sort of figure that out, like, okay, this thing's pretty cool. And why the hell does it put the output through? What? Where does that go? That should not go there.

So it like dumps a bunch of stuff in varlib, who knows what. And that was very confusing. And then some folks were like, why do you use Pbuilder? It's like so slow. You should use Sbuild and then yada, yada, yada. So I ended up writing a blog post about this. I wrote packaging tutorials for like closure packages, not even to help other

people, but just so I could document my process. So if I spent six months away from it, I would remember what the heck I was working on. So yeah, it's not the best. I really wish there was much better documentation. Like I frequently have had to go and dig into code in order to understand how various build tools worked, only to discover that the tools were like, you know, massive blobs of pearl, which I mean, I could understand them because I've written some pearl in my past, but it's like, what house of cards was this thing built on? So you don't want to touch anything because there's no tests, of course. Exactly. And it turns out not just that it's a technically challenging area, and there is a lot of adducion. This stuff is hard, and yes, mistakes will show and matter. I mean, the entire lesson I took from it was not

how to really focus on being a awesome packager or terrific developer member of the community, but rather that if you want something done, screw it up to the point where people take it away from you. Yeah, that's just, I don't want people coming into the community and that being the lesson they take away. It's sort of depressing to look at it that way. One of the things that Debbie and I have found to be very effective is the law of two feet. Like if you are the first person to go and do a thing and you are willing to put in the work to maintain it, folks have a really hard time of like doing anything about it. They may yell and scream at you and tell you you're doing everything wrong,

but they can't really depose you. And it's actually very socially unacceptable to try to depose someone unless, you know, you go all the way up to escalate into the technical committee and there's much drama and, you know, then you end up on the front page of LWN or something like that. So yes, it is that we need to do better.

And I think that, you know, a lot of the work that Debian has been doing with anti harassment and stuff like that is making the community better. But goodness knows when we will have, I mean, it's not like we have this documentation team that we can just, you know, send things and be like, hey, you go document these build tools, because our story sucks, or go add like really good tutorials so that like more people can get involved in this stuff. Like Debian is just a collection of individuals who are all working sort of independently in their own little fiefdoms on things that they personally care about. And it sometimes amazes me that it works at all. And so I can't like just go and tell people like, go write these tutorials. Debian Woman woman the the group debbie and woman has previously been responsible for a lot of this stuff and now you know debbie and woman is not super active and they're merging with debbie and diversity and like all these tutorials are five years out of date what do we do well i don't know who do we figure out like how do we direct people

at working on this stuff i don't know and i don't even want to like try to suggest hey maybe we should pay someone to do this because the last time that happened, everybody cried bloody murder. So it is a problem. It seems to me that there's a better story for this in the future of making the community more accessible to people. I mean, again, I used to be deep in the weeds of IRC myself. I was network staff on Freenode for the better part of a decade. And part of the reason I did that was because I got tired of what I saw in a number of different channels, which was, oh, someone shows up and asks a question. And the first thing you do, and there's almost a race to be able to do it, is not to help them with the question, but to tell them their question is

stupid, they're stupid, they didn't ask the question properly, or read the documentation. And that is one of those things I found absolutely abhorrent. It's, why don't we have more people from more diverse backgrounds working in tech? Well, because every time someone shows up in tech, regardless of the rest, you start by subjecting them to trial by fire. And most people have better things to do with their time than playing these games. And I absolutely have nothing but respect for people who stick around through that hazing, but I think that is one of the crappiest things we can wind up doing. As a tech community, I say we as a tech community writ large. Not any particular community, not any particular network, not any particular software package, none of it. Just as a society, I guess, we can do better than that. And we're

finally starting to turn the corner on that, I think, I hope, where there are decent ways of finding mentorship, of getting involved in community. But Lord knows that one of the reasons that contributed to my not becoming a full-time developer all the time was I didn't want to sit and take that abuse every day. No, not at all. And I've certainly had my share of that myself. I think one of the reasons that I have been successful in the free and open source software community is that I'm very good at independently being able to research things and go find the documentation. And I can work for days without like needing to reach out for someone for help. I can just, you know, like, okay, I've got this problem, I will guide myself towards the various things and try to figure it out. Because, you know, I might ask someone,

and it's been good, because now that I'm working on some things, which are considered like, it's like gross to call them bleeding edge, but they're a little bit bleeding edge. Like, certainly, they are new fangled and untested previously. And so that definitely comes in handy, because it's not scary and off putting to not have someone holding my hand because nobody was holding my hand to begin with. But I'm certainly like that should not be the baseline or the standard. And I was very lucky to get involved in free software via OpenHatch because OpenHatch was such a welcoming, warm, helpful community. It was really, really great. And so folks would come into our IRC channel and they'd

ask basic questions and people would like be very helpful and respond right away and try to get them the help they needed, even if it was like the thousandth time that question had been answered that day. And sometimes as a maintainer, it can become very trying when somebody asks a question like this, that was its time that day, like, Oh, I guess I have to link that thing again, maybe I should just make a macro for this. But like, I mean, that person doesn't know that. So it's like unfair to take your anger out on them. One experience that I have that stuck with me years later was in 2012, where I went to Scale, the Southern California area Linux expo. And I saw a talk by Jordan Sissel, the founder and creator of Logstash, which has since been acquired by Elastic. It's the L in Elk Stack. And he's still there. And

he gave a talk on Logstash that was transformative in a number of different ways. First, that was one of the talks that inspired me to try my hand at public speaking. So if you've ever seen one of my talks and thought it was crappy, self-aggrandizing, I'm a terrible speaker, et cetera, blame Jordan. Secondly, it turned out that he had a line in there that just resonated with me now six years later, that if a new user has a bad time, that's a bug. Fix your documentation, fix your culture. And it was something that was electrifying where it set the stage for, yes, this is what every product should espouse and doesn't. And ever since then, it's sort of been something that I started, once you see it, you can't unsee it. Trying to create that type of environment for people has always been what I've been about.

My newsletter last week in A in AWS is snarky and sarcastic because that is my sense of humor, but I'm very careful never to punch down. When I'm sitting here making fun of Amazon, a near trillion dollar company, depending on the week, they can take it. They have succeeded. If I'm sitting here making fun of a newcomer to a space or a startup of five people, I'm not being clever. I'm being a jerk. And I think there needs to be an awareness that meeting people where they are and making things accessible to them is on the onus of you if you want to see uptake and adoption of what it is you do. Absolutely. So where can people find you if they want to hear more about your

thoughts, wisdom, code, thoughts on life, etc? Well, they can find me on PlanetDevian or read my blog directly. That syndicates to PlanetDevian. My website is hashman.ca. To be clear, PlanetDevian is one of those things where it's an aggregator of different blogs, or it's a way station that you can get to by connecting through Narnia? Definitely Narnia. No, it just aggregates various XML feeds into a single blogging place. And so folks are like, oh yeah, I saw your latest

blog post on Planet Debbie and I'm like, you did what? Oh yeah, I put my blog on Planet Debbie. Or you can access my blog at hashman.ca slash blog. I also tweet at e-hash-d-n. It's a bad LDAP joke because my username was taken, which was very disappointing. And you can also find me on Mastodon if you're so inclined. That raises the wonderful question of, is there such a thing as a good LDAP joke? You know, as a student, I implemented atomic incrementation in LDAP, and I think that we should just not even think about such things. Absolutely. Well, I'll put links to those in the show notes as well. Great. Yeah. And I can spell them out for you if you need me to do such a thing by email. Perfect. Well, thank you

once again for taking the time to speak with me. I appreciate it. Yeah. Thanks so much for having me on the show. Lana Hashman of Debian and Python fame. I'm Corey Quinn. This is Screaming in the Cloud. This has been this week's episode is Screaming in the Cloud.