Skip to content
GitHub Copilot is now available for free. Learn more

THE README PODCAST // EPISODE 1

From a 3D side project to the dream job

A full-time, community-backed maintainer, Gina sets boundaries but stays visible.

Elapsed time: 00:00 / Total time: 00:00
Subscribe:
Gina Häußge

The ReadME Project amplifies the voices of the open source community: the maintainers, developers, and teams whose contributions move the world forward every day.

Gina Häußge // @foosel

When she was young, Gina Häußge’s dad showed her how to make her first computer commands, and she was quickly hooked on watching code come to life. Fast forward to 2012, when she got her first 3D printer, which she loved. What she didn’t love were the noises and fumes it spat out during prints. So she put it in the spare bathroom, built a monitor that she could control from her office, and open sourced it on GitHub. Octoprint exploded in popularity, and Gina quickly learned there was much more to being a maintainer than writing code. Hear how she figured it all out, and what she’s doing now, on The ReadME Podcast.

Gina: Sometimes I feel a bit like a kindergartner or a cat herder or something like that, and I have to do all these things, and I had to become all these things. I’m not sure that if someone had asked me if I wanted to become them, I had said yes. But I don’t regret it. There is so much more to being a maintainer than just writing code.

Brian: That’s Gina Häussge, maintainer of OctoPrint and this is The ReadME Podcast, a podcast that takes a peek behind the curtain at some of the most impactful open source projects and the developers who make them happen. I am bdougie aka Brian Douglas.

Kathy: And I am Kathy Korevek. In this episode, we speak with Gina, whose project OctoPrint has revolutionized 3D printing. She came to open source the way many programmers do, seeing a problem and wanting to find a solution for it. What she didn’t expect was just how responsive the community would be and how quickly OctoPrint would grow. In this conversation, we discover how Gina’s love for programming grew, what happened when she first put OctoPrint onto GitHub and how she copes when her emotions get the better of her.

Gina: I have to say that I always was a very nerdy kid and I always wanted to know why things work, how they work, and how they tick. And love building stuff as well, and Lego, and crafting and all that. And then around age seven, my parents got their first computer, an Apple IIe. So a really, really ancient thing, even back then already somewhat ancient, so in the mid late ’80s. It being a computer and me being a child, the natural reaction of myself was, “Hey, nice. A new toy. I want to play with this thing. I want to play video games,” and my dad said, “Nope. This is not a toy, this is something that you work with. But I can show you something.”

So yeah, he showed me the very, very first basic commands of my life, I could not speak a word of English back then, so everything just looked like completely weird things that I didn’t understand at all, but I could put them to memory and use them to make stuff appear on the screen. And that was like an epiphany in a way because I realized quickly that hey, I can use these things to build stuff and make stuff happen in this computer. And contrary to Lego bricks, for example, they won’t run out and I even can build my own out of the ground blocks, so to speak. And that was when, basically, a lifelong love started.

And at some point, then I learned that a computer programmer was an actual profession that you could have and acquire and so that was when I knew what I wanted to be when I grow up and basically concentrated on that, made sure that I really got good in math, and signed up for the very first computer science course at school as soon as it was available to me, and then later studied at university and all that. So yeah, I was pretty much set on this path very, very early.

Brian: Those early years were so influential for Gina, they set the foundation for the rest of her professional life. And her discovery of coding came hand in hand with her discovery of the internet.

Gina: We only had dial up internet and my parents were a bit restrictive when it came to how long I was allowed to be online because it cost a lot of money to be online back then. So what I did usually was I could only be online for like an hour, so during that hour, I downloaded everything that I was able to download onto my small, little PC, and then spent the next couple of days sifting through whatever I had found there. I remember also being very happy when I finally managed to find a full download of the PHP documentation. So I did not have to stay online to go through it, but I could actually just open it on my PC and go through it which helped me a ton in moving my little hobby projects forward. So, yeah, that was that.

Kathy: That’s cool. So you have these hobby projects. When do you feel like you had your first big break? When did this passion of yours and these hobby products really start to fulfill you and be something that you could jump off from?

Gina: I would say that was actually with OctoPrint. I dabbled in other open source projects before. I was quite heavily involved with the DokuWiki project for a while and the maintainer of that, Andreas, is also still a very close personal friend of mine. I learned a lot during that time, but that’s something that I envisioned really, launched off, and made an impact, I would say, that definitely was this 3D printer remote manager/baby monitor that I built in late 2012 that suddenly took over my life.

Brian: Can you dig into why you built that and what sparked that project?

Gina: So back in late 2012, I got myself my first 3D printer. I saw one of these things working and I was fascinated because it was creating stuff out of thin air. Obviously, not really, but it felt like that. And I was just like, “Okay, one day, I want to have one of these.” And then some friends that I had made over the years all across Germany suddenly started getting themselves 3D printers and I was like, “I want one too,” so I got myself one.

And then it was sitting here next to myself in this office and tethered to my printer because back then, they didn’t come with… these days, they all come with a little controller that you can plug an SD card in and it will be able to print from that. But back then you still had to have a tether to your computer and for hours on end while it was doing its job. There was no spooling queue on that, but you really had to constantly feed it commands to work and that was a bit annoying.

So I figured, okay, I’ll just get one of these nifty little Raspberry Pis. They had just come out that year. They are only like 35 bucks or something. I’ll get one of these and install something on it. I’m sure there’s a solution for this and just throw it on the printer, and put the printer in a spare bathroom, and then monitor it from remote, and then everything will be fine. The theory was fine. In practice, sadly, I could not find a project that did exactly that, what I wanted. So there were some projects that were able to control a printer and feed it all the commands from a file over the course of the job, but there was basically no back channel there. So I didn’t know, was it actually printing or had it stopped something? Was there an error or something? Was it even hot or had it, maybe I don’t know, had the heating failed and now it was doing nothing but producing a horrible noise or something?

So that was when I decided, okay, I have a nice little Christmas vacation coming up, I would just sit down and write this myself. It can’t be that hard, can it? Famous last words. And I thankfully was able to build up on existing software. I basically borrowed the communication layer, the thing that talks to the printer because I had no idea of printer communication back then and built a web interface in front of that. And then after Christmas and after New Year’s, it could do what I wanted. So I had webcam feed, I could monitor the jobs, I could upload files and start them to print. I could see the heaters in a nice little graph and all that. Basically, I had reached my goal.

Basically, I threw it up on GitHub, put a license on it and said, “Hey, if anyone else has the same problem that I had, here is the code, have fun with it,” and returned back into my day job figuring, “Well, it works. That was a fun project, but it’s over now. Too bad.” And then suddenly, I started getting emails from all across the globe and people messaging me on Google+ and opening tickets on the issue tracker in GitHub. So apparently, a lot of people had had the same problem that I had and that I had just solved or started to solve. The project suddenly turned out to be a full-blown open source project with an actual community behind it and a lot of interest in it.

Brian: Suddenly, OctoPrint had built a following, people who not only were interested in using it themselves but also engaged in making it better, stronger. It was the confluence of two vital conditions: A need in the market and support from the community. It really took Gina by surprise.

Gina: I was elated. I started working on it, spending a lot of time with it, evenings, and weekends, and vacations and all of that. Friends and family started to become a bit annoyed at that thing. And I also cut my day job back a bit to 80% so that I could have one day per week, per work week, so to speak, to additionally concentrate on this thing, so not everything would need to be done in my spare time. And the project still grew, and grew, and grew and took up more and more of my time and at one point, I figured or I realized, well, not even one day per week is enough for that. There are too many people who want to use this and too much stuff that needs to be done to make it great. What could I do?

At that point, that was really just pure coincidence, but perfect timing, really, a company approached me who were also producing 3D printers and was saying, basically, “Well, we like what you’re doing and we would really like to see you do it more. How about we hire you full-time to work on this thing full-time and enable you to just do what you’re apparently very good at, which is building stuff like this?” And so we met and talked to each other, came to an agreement and a couple of months later, and we are now in mid-2014, I think, I was suddenly doing open source full-time from my home office. Then two years later, the company ran out of money which was not so great because now by this time, I had made OctoPrint even more, even bigger and more popular and the community had grown, and grown, and grown again so that by now, even my full work week was 100% or maybe 120% filled with work on that and suddenly, I was out of funding.

My first instinct was to just say, “Okay, that is not good. I need to find a new job.” And I will probably not be able to do OctoPrint anymore. And then I figured, okay, but on the other hand, I would probably kick myself for the rest of my life if I don’t even try to get funding for that through crowdfunding.

And so I sat down and started a Patreon campaign, not expecting much, fully prepared to see it fizzle on launch day and not going anywhere and just doing it basically, so that I could say, “Okay, I tried and I will not question myself for the rest of my day why I didn’t even try.” So the thing went live and it didn’t fizzle, but it rather went like up, and up, and up, and up, and people were like really, “Of course, we are going to support you. I use your software all the time.” Some other companies were also chiming in and saying, “Hey, we can give some more here. There’s money and please continue your work.” That is probably the biggest surprise of my life.

Within, I think two months after launching my Patreon, I managed to get back up to my previous salary. So that was really encouraging. Also, the 3D printing press was writing articles like OctoPrint startup, I don’t know why they think it was a startup, but okay, OctoPrint start up loses funding, community rallies behind developer. And that was like whoa, that sounds very epic and I felt so accomplished in that moment.

Kathy: How did the community grow? What did that feel like as people started to use it and find it, and it started to blossom into its own thing where you have this vibrant ecosystem?

Gina: It was pretty amazing, but also quite scary at times because suddenly, it felt like it was growing bigger than myself and that was a bit weird and something that I first had to come to terms with, so to speak. I remember the first time that I actually had usage tracking in OctoPrint so that I had a rough idea how many instances were out there, I just stared at the screen for a couple of minutes and felt a bit… how to say? Maybe a bit nauseous even because it was like there are so many people using it. And it’s just me sitting in this office primarily at least. I don’t know how best to describe this. It’s just I feel like there’s such a ton of responsibility on my shoulders and I sometimes am a bit scared that I cannot really do it justice, I think.

But still, it’s been pretty amazing to meet so many people through it. So I made some very, very close friends through open source and some of my best friends now, actually, and I would not have been able to meet people from the US or from Australia or from Canada or some or some other place. I mean, the person who does the OctoPi image, so this prepared Raspberry Pi image with OctoPrint and bunch of dependencies and all that included on it, and basically key ready to just flush and run from there, the person who maintains that lives in Israel. I would never have met him, but now, I actually met him because he happened to make a visit to Frankfurt two years ago. And so that was yeah, that’s just stuff that wouldn’t have happened to myself without open source and that has been very, very amazing.

Kathy: Gina was on a steep learning curve not only in building OctoPrint but becoming a maintainer of what had become a very big project. As she says here, she is primarily a software developer and architect, setting the structure of OctoPrint, focusing on how the various components interact within it. But being a maintainer comes with all kinds of other responsibilities. Was Gina expecting this?

Gina: No, not at all. I thought I was prepared because I had taken part in DokuWiki and I knew a bit about the downsides of being an open source maintainer through that and, of course, also the upsides. But yeah, being it, actually being it and finding myself in this position and frankly also, I sometimes have the feeling the project is also a bit bigger by now than DokuWiki was back then. So that is an additional thing where I just simply lacked experience. Yeah, it’s just sometimes a bit scary, really. But yeah, I definitely came a bit unprepared and had to grow with it. So still grow. I constantly try out stuff.

I’m not a community manager. I’m not a project manager. I’m not a support person. Primarily, I always was a software developer and maybe a software architect. But now, I suddenly find myself I have to do brand management and I have to do community management. Sometimes I feel a bit like a kindergartner or a cat herder or something like that, and I have to do all these things, and I had to become all these things. I’m not sure that if someone had asked me if I wanted to become them, I had said yes. But I don’t regret it. I don’t regret these experiences. It’s just, yeah, there is so much more to being a maintainer than just writing code.

Kathy: That is one of the things we hear most often, maintainers don’t necessarily intend for their projects to take off when they first create them. And while success is exciting, being a maintainer can take you away from the thing you love most, writing code. It takes vigilance to make sure that role doesn’t dwindle away.

Gina: The thing is that I love writing code so much that I never let it escalate away from this too much. In fact, OctoPrint happened at a time when in my day job, I was not writing enough code and I desperately needed to scratch that itch with a pet project. So yeah, I need code in my life otherwise, I’m not happy and this is also why I defend my right to work on my project. But I found that at some point, it was stuff like issue management, and community management, and brand management, and also funding and all that was eating up a ton more time than I actually wanted to give it.

And that was when I started to realize that I really needed to look into actually balancing my roles out and make sure that they didn’t become unbalanced and not unhinged or something like that. And also, for my own personal health because, as I said, I love to code and if all I do every day is answering emails, and looking into the issue tracker, and trying to help people on the forums or on discord, then I’m probably not going to be a happy maintainer.

Kathy: So right now, you’re thinking about diversifying and splitting up your roles so you can have better work-life balance, you don’t have to look at the issues and emails all the time. Can you talk about, when you were realizing this, what were some of the main challenges that you were facing that led you to that decision?

Gina: I think actually letting go of some control was one of the biggest challenges there because I suddenly had the feeling… I mean, if someone opens a bug report on GitHub, then naturally your first instinct as a maintainer is oh, my god, something is broken, I need to figure out what this is. And if I constantly do this with every single ticket that is being opened, then I will not do much else but analyze tickets and this is not going to move the code forward that much because a lot of the bugs aren’t even bugs and even if they are, maybe someone else could also take a look at them.

So what I had to do was just reduce this expectation of mine towards myself to jump on everything the second it arises and just feeling still in control, even if things weren’t immediately tackled. And that is something that did not come natural to me and that needed some work. I tackled it—I created myself a timetable like I used to have back in school where I scheduled work blocks, basically. So now, I can concentrate one hour on issues, and these two days are for maintenance, and the rest of the week is for development, stuff like this. That has helped a lot. I do not necessarily stick to this timetable all of the time, but just having this construct, basically, and having it remind me how things should be, and how the balance should look like, that helps a ton in reigning myself in when I try to gallup into the sunset of issues when, in fact, I should maybe look into other things first.

Kathy: Did you lean on anybody in particular in the community to help you navigate that or get advice from folks, other maintainers that you were meeting?

Gina: Actually, no. I have to admit that, it never even occurred to me to ask for advice there because I just had this feeling that it’s mostly my own personal problem that was very specific to myself, and to my perfectionism. and all that that I had to somehow tackle. I just tried the first thing that came to my mind after a couple of nights of sleeplessly thinking about the situation and the first thing actually worked, which was the timetable.

Kathy: That’s nice.

Gina: I might have been just lucky.

Kathy: Open source is inherently public and when you’re in the spotlight, the way Gina is, it can be difficult to be so exposed. And Gina puts her whole self out there. In a male dominated field like software engineering, being a woman adds another dimension to being a leader within technology. I wondered what that felt like for her.

Gina: It’s a bit of a scary experience because all kind people are looking at you and you are not, in my case, at least, I never wanted to be in the spotlight, it just suddenly kind of happened, at least in the space that I’m walking in and moving in. So that was a bit weird and I’m still not fully used to it, I have to say. My particular problem in this community, in the 3D printing community, is that a lot of people who use OctoPrint and are very familiar with OctoPrint are still assuming that I’m male and I’m at least 12 men or something like that. So I see a lot of comments like the OctoPrint developer, he said that or something like the OctoPrint developers, they all, when it’s, in fact, primarily me working on this.

So there’s a bit of ignorance going on and this is also why I try to be a bit more visible and try to set an example that hey, by the way, we do have women in open source and just because you tend to assume everyone is male doesn’t make it necessarily right. But that can also, of course, lead to some… I have not had really bad experiences when I put myself out. But of course, there’s always a bit of being afraid that something might happen. That would not be something that a man has to worry about. I had a situation at a conference once where I felt quite insecure, and not insecure because I was insecure, but because I found myself in a situation where I felt threatened. And that was when I reached out to someone that I know and he took care of everything. That’s still something that I always keep in my mind, and that I also try to handle and be prepared to handle. I wish that wasn’t necessary, but sadly, it is still.

In general, it would really be nice if people were just a bit less surprised when they see a woman at the steering wheel of an open source project because I sometimes feel like a unicorn due to that and I do not want to be a unicorn. I just want to be accepted for who I am, and what I do, and what I’ve accomplished, and I do not want to be like, look at her. She’s female. It sometimes feels like you get reduced to that when in fact, you have so much more also that you could share and that you could contribute to a community and then suddenly, you’re just like the quota woman.

Kathy: Yeah, the token woman. I’ve definitely been there.

Gina: A token woman is the English term, yeah.

Kathy: In your experience working as the maintainer of OctoPrint, are you inspiring other women to join and work in open source and do you see more women now than you did back in 2012?

Gina: I certainly have noticed that. Apparently, I had the same bias because I now look more at who does or who the maintainers are of open source projects that I use myself and I also try to find like-minded people more and realize that, in fact, there are a lot more women in open source than I thought there were, which is very reassuring, I have to say. And I also have heard from people that I’ve been like a role model for their daughters or for themselves and that is also really inspiring because I certainly did not ever expect to be a role model to anyone. That was not something on my bucket list. I’m not complaining, but it’s simply not something that I expected would happen, so that is really, really nice. When people send me stuff, this is also stuff that I print out and put up on my wall here so that when I feel really down or really annoyed at some nasty person commenting on some issue or something, I can just look at that and be reminded about the good parts about doing stuff like this.

Kathy: Do you get a lot of nasty comments and things like that in your community? Actually, I know you do because every maintainer does. I should ask, how do you manage that with the person? You have your coping mechanism, you look up on the wall, and I have words of affirmation that I share too and so when I’m feeling down, I look at those. But how do you interact with that person again in your community as a maintainer?

Gina: First of all, I actually have a second coping mechanism and that is usually what I first turn to when I run into an entitled and very nasty person. I have a punching bag in my office and I have to say that I can only recommend to every open source maintainer out there to get yourself a punching bag in your office because it makes a huge difference in your own personal stress levels. And yeah, it’s such a nice way to destress. When you read something really nasty, and you just want to kill whatever person wrote that on the other end of the screen. And instead, you just stand up, go to your punching bag, throw some really hard punches for a minute or so as long as you can. In my case, it’s usually not much longer than a minute, full out. And then you sit down again and you are just… the whole fight or flight response that your body was already amping up for is just stopped dead in its tracks and you can sit down and respond in a very factual manner without being emotional and without being too aggressive.

Though I have to say that I also do not take everything with a smile or something. When someone is nasty to me, then I will tell them hey, you’ve just crossed the boundary and I do not tolerate that. I do not tolerate that kind of tone. I do not tolerate these words. I’m happy to help you and I’m always happy to solve issues when they arise, but I will not see myself or anyone else in this community for that matter treated like that. And that has gotten me a surprising number of apologies from people who then realize, okay, maybe I was just really frustrated, and I vented it at you, and I’m sorry for that. It also has gotten me a bunch of people who doubled down and became even nastier and for those, there is the ban hammer.

Kathy: Yeah. You should recommend that those folks get a punching bag before they start to dive in.

Gina: Maybe. Maybe that would be an option, yeah. People have also mentioned I should just print out the issues and pin them to my punching bag, but frankly, that is usually not needed.

Brian: I loved that advice and it’s good for all maintainers because no matter how good you are at what you do, people complain and it can be hard to manage. Getting your frustrations out and returning to the thing you love, writing code, is hugely helpful. What advice does Gina have for those who are looking for that outlet to write more code and work on a project?

Gina: I would say that you really need to do something that you look forward to doing. I think it will not serve you very well if you just try to work on a project that already exists, maybe that is very high-profile, just to be able to put it on your CV or something. So in my case, the things that happened happened, I think, because I had a serious personal problem that I needed to solve. I wanted to have my printer in my spare bathroom and still be able to monitor it and so I just focused on doing that and learned a lot of stuff in the process. That was a ton of fun and it still is, actually.

And then you also have to find the resources to do it afterwards and you will have to do it afterwards at the beginning. When to make the jump is probably the trickiest thing. In my case, it was pure coincidence. I would not have made a jump if the company hadn’t approached me and offered me a full-time job. I was trying to find a way to make this work, but I cannot really tell people or give people a recipe that will always work. In my case, it worked.

Brian: Gina, so what do you think the future of OctoPrint is? What’s on the roadmap?

Gina: So currently, I’m working on the next big major version 2.0 and working on a new comm layer again. Finally found the time again to work on that because the pandemic completely threw a wrench into all these plans. Last year, I was just busy working on maintenance and all that because the support requests ramped up majorly. Anyhow, I also want to create a new user interface because the one right now is still the one that I built in late 2012 and the technologies used there aged quite a bit and it’s not the best that you can use for what I want to do anymore. So I’m currently also evaluating possible technologies for that.

And of course, do that as long as I can and also be prepared that if at some point, the funding does run out and the whole work model that I currently drive will not work out anymore, I will also have to be prepared to let OctoPrint go, basically. But I obviously hope that will not happen soon or at all. But still, it’s also something that I have to keep in mind and which I would also advise every open source maintainer to keep in mind that if, at some point, you realize it does not work for you anymore, then you have to let go.

Kathy: What does that mean let go? Would you find another maintainer? Would you shut down the project?

Gina: If I could find another maintainer, I would also happily assist in taking it over, though probably under another name because the name is very much associated with myself. But if I could not find someone like that, then I also… obviously, I do not hope this will happen. But if at some point it will happen, then it would mean setting it into an archive mode and saying goodbye.

Kathy: And this happens in software.

Gina: Yeah, it happens and it’s just something that is also part of the natural lifecycle of an open source project, I would imagine. I mean, if it’s no longer of value or not longer used or not longer sustainable to keep on developing, then you just have to shut it down.

Kathy: Yeah. That’s the arc of software in general. We’re often sunsetting and deprecating software all the time and the same for open source.

Gina: Yeah, it’s the cycle of life. I’m not singing now. I also do not want us to get sued by Disney. But in general, I think you just have to be aware of stuff like this and I could imagine that a lot of maintainers do not think about that when they start out. I certainly didn’t, but it’s also something that you have to keep in mind. And that also ties back into this whole you have to make sure that you feel comfortable with it, and that you feel good, and that you are healthy both mentally and physically, and all that, that you do not burn out because if you are starting to burn out on a project and there is no out of this situation other than shutting it down, then shut it down. It’s not worth more than your life.

Kathy: Yeah, that must feel freeing knowing that you put this out there on GitHub and then you’ve feeling a little nauseous because everybody’s now using it, and now you’re a maintainer. And I feel like a lot of maintainers find themselves in a similar situation overnight and you’re like, “Okay, now I have to maintain this thing. I don’t really know what that means.” And I imagine that could feel pretty constraining or like you’re trapped. But then when you think about, okay, well, what’s the out here? What are my options if this doesn’t work out for me? And being okay with one of them being I might shut down the project or I might end-of-life this project, I think that’s really healthy.

Gina: In general, I think with every open source project, as a maintainer, you have to also constantly remind yourself, you do not owe anyone anything. I mean, it doesn’t mean you should not try to do your best, but you do not owe anyone that you will maintain this project towards the end of your life or you do not owe anyone to accept a pull request, and you do not owe anyone to implement a feature request, and you do not owe anyone anything. This is just something that you need to internalize because people will try to walk all over you and claim that you owe them in some way or the other. Because they are using your software, now you owe them some kind of support, or accepting their ideas, or implementing their workflow, or solving their specific issue and yesterday. This is just a notion that you have to block in your head because otherwise, you will be abused in some way or the other.

Kathy: Yeah, like learning how to say no. Gina, as a woman who’s in open source or even as somebody who’s getting started in open source, and you mentioned you had a lot of people who look to you and get inspired by you. What advice do you have for them as they’re starting out and approaching open source?

Gina: Especially for women or rather for girls, I would say don’t let anyone tell you that whatever you’re interested in is something you should not be interested in. That is something that was really tricky while I was growing up because I was meeting a lot of resistance, especially later in school where people were constantly questioning why I was, for example, in the computer science course. And it’s just something that takes a lot of strength to work against. And I can imagine that a lot of people do not have this strength, maybe, and need help.

So I would also try to ask the parents maybe to not do this stupid compartmentalization of what their children are allowed to be interested in. But if they are interested in something, just be glad that they are interested in something, and coach it, and try to nurture it, and just enjoy that your child is showing passion for something, and is trying to learn something. Maybe something you have absolutely no inkling about, but still they are passionate about something. If you are interested in something, go for it and don’t let anyone tell you otherwise. And if you want to try out something, and if you want to get your feet wet in open source, go for it. And don’t let anyone tell you otherwise. The worst that will happen in the process is that you learn something and maybe you also grew some more frustration tolerance in the process, which you will definitely need as an open source maintainer.

Kathy: Frustration tolerance. I love that.

Brian: We all need some frustration tolerance! Gina has been amazing at managing the hardest parts of her project and overcoming them. So good to have her on the show. To learn more about her work, please visit OctoPrint dot org.

I am Brian Douglas, and I am a developer advocate here at GitHub.

Kathy: And I am Kathy Korevek, I work in product at GitHub. The ReadME Podcast is a GitHub podcast that dives into the challenges our guests faced and how they overcame those hurdles. In sharing these stories, we hope to provide a spotlight on what you don’t always see in the lines of code, and what it took to build the technology that inspires us all.

Brian: It’s been really great spending time with you. The ReadME Podcast is part of the ReadME Project at GitHub, a space that amplifies the voices of the developer community: The maintainers, leaders, and the teams whose contributions move the world forward every day. Visit GitHub.com/readme to learn more.

Our theme music has been produced on GitHub by Dan Gorelick with Tidal Cycles. Additional music from Rhae Royal and Blue Dot Sessions.

The ReadME Podcast is produced by Sound Made Public for GitHub.

Please subscribe, share, and follow GitHub on Twitter for updates on this podcast and all-things GitHub. Thanks for listening!

Meet the hosts

Kathy Korevec

Originally from Alaska, Kathy’s journey into tech didn’t start out like most. Her first tech job was redoing her college’s library website, and she later helped a car dealership put their inventory online. There was also a brief stint as a pastry chef in Tennessee. But she ended up at Google in San Francisco, which put her on her path as a product manager. At GitHub, she managed the Documentation team, working to make it easier for developers to learn about products and unlock solutions to their challenges. Now at Vercel, Kathy firmly believes that great products start with good conversation, and should be built on data driven design, business goals, and, above all, put the user first.

Brian Douglas

Brian grew up in Florida, and was in full-time sales before the birth of his son inspired him to build an app—and he saw an opportunity for a new career. He taught himself how to code, and started blogging. His content caught the eye of a San Francisco tech company, and he never looked back. Now living in Oakland with his family, Brian is a developer advocate at GitHub, where he creates space for other developers to find their voice. He’s passionate about open source and loves mentoring new contributors. He’s also the host of the Jamstack Radio podcast and created the Open Sauced community.

More stories

Co-maintaining openness

Peter Strömberg and Brandon Ringe

Let the games begin

The ReadME Project

About The
ReadME Project

Coding is usually seen as a solitary activity, but it’s actually the world’s largest community effort led by open source maintainers, contributors, and teams. These unsung heroes put in long hours to build software, fix issues, field questions, and manage communities.

The ReadME Project is part of GitHub’s ongoing effort to amplify the voices of the developer community. It’s an evolving space to engage with the community and explore the stories, challenges, technology, and culture that surround the world of open source.

Follow us:

Nominate a developer

Nominate inspiring developers and projects you think we should feature in The ReadME Project.

Support the community

Recognize developers working behind the scenes and help open source projects get the resources they need.

Thank you! for subscribing