Open Source Programming with Katie McLaughlin

Olivia: 0:00

Hello, and welcome to the Router, the official podcast of the UQ Computing Society, where we explore the human side of tech. I'm your host, Olivia. And on this week's episode, we'll be talking about open source programming.

Katie: 0:22

Hi, I'm Katie. I am currently a director of the Python software foundation, and I've got, I want to say five or six years now of active, open source contributions in the Python and Django ecosystem.

Olivia: 0:43

So what got you started there or six years ago. And what got you interested?

Katie: 0:48

So I graduated many years ago and I've been in industry for a bit, but it was very much like I graduated with a bachelor of information technology from Griffith. I did a whole bunch of different jobs around just sort of programming that it wasn't really like fun programming stuff. It was just whatever job, whatever tech stack was there. It's, okay, I'll do this for a few years. And then I find something else. And then I got to a job where I was in an engineering department and the engineering manager at the time said, we're going to build this o pen s ource product and we're going to write papers and give conference presentations on it. And at that time, like I knew that GitHub was a thing. This is going back. U m, I w ant t o say 2013, so quite a number of years ago, but we started working on GitHub in the open, u m, doing our normal day to day stuff where everyone could have a look at what was going on. And so that was a really different way of working. And so I started connecting with people like, u m, like seeing regular people pop up in different places on GitHub, and then finding out that there were conferences for this stuff and attending those and it sort of snowballed from there. And now I'm serving on the board of a foundation that keeps P ython going and I've served on, u h, the Linux Australia board. And I served on the D jango software foundation board. U m, yeah, I think snowball is definitely the, u h, right analogy here.

Olivia: 2:36

Um, sounds cool to be a part of all of these incredible projects too. Like what what's kept you interested, interested, I suppose, like with the, is it the switching projects, like, uh, being part of new projects what's, um, kept you involved, I guess if you previously switched around a little bit with like tech stacks

Katie: 2:55

What kept me around is the community Django definitely has a unofficial motto of, um, come for the code stay for their community. Uh, Django for listeners is, is a web framework built on top of Python, uh, that a whole bunch of places use such as Instagram and Eventbrite, um, and a few other, uh, bigger companies. It's sort of, it's like Python's version of Ruby on rails. If that's familiar, it's a very robust framework for building complex web applications. Um, but the community around Django as a subset of the Python community is absolutely wonderful and amazing. And I actively want to keep working in Django and Python stuff because it means that I get to hang around with awesome people who are wonderful to be around plus or minus actually getting to see these people in person because you know, we're all indoors right now, but

Olivia: 3:59

Yeah. Cool. So I guess like working on these projects and having them be open source versus just closed source, uh, what do you feel like is, I guess the best benefit in general, both on like your side as like developer and like, just to the wider community,

Katie: 4:16

When you're working on closed source things, you often have to re-engineer everything yourself or, um, you just don't have the tools. So if you're working in certain ecosystems, you have like a black box of a product that you just have to try to fine tune to meet your needs in open source. You can see exactly what's going on. You can take the entire product and change it. You can, uh, work from other people's examples and you can develop a whole lot faster. You also have the opportunity to contribute back. Um, it's a little bit of a mind melt where you realize that you took a copy of someone's project and changed it, but you actually only changed two lines and it would help the project in general, if you were to put those back into the main product, and then your changes can be used by everyone, without them having to go off and do the manual change, but it's just like the next person that downloads it gets your fixes. And it's that constant evolution of products where it's not determined by how expensive it is or how accessible it is because it is accessible and it's free, and it is supported by hours of volunteers just like yourself. So putting it back bit of time back into the projects that you use, help them continue. And that's the first time you go through this, it's a bit of a mind meld. And so trying to explain that to people, it's like, the first time you go through it, it's like, Oh, wow. And then you kind of get it.

Olivia: 6:01

Yeah. So I guess talking a little bit more about the first time. I know a lot of people can feel a little bit daunted working on open source projects, because they do have such a large scale. Uh, like you said, such a large scale team of people working on them. How would you suggest people kind of start out on an open source project? Um, as, you know, just like another programming project for them,

Katie: 6:28

This is where opinions are going to differ. Um, there are efforts like Hacktoberfest and other sort of, um, let's all contribute to open source that can seem like it is an invitation to just mass spam projects. And there has been some pushback from open source maintainers about that. Like a set month of the year that will just be people trying to complete their mandatory four pool requests to get a t-shirt. But the top 1% of open-source projects by popularity, uh, very, very large, but there is still the 99% of projects that, uh, one or two people that really just want someone to come in and help them out with their project. Like they have pull requests that are actively saying first time is up for grabs finding these projects is hard. Um, the motivation for why you want to get into open source is going to be one thing, but which projects you help out with is going to be another. Um, so just trawling GitHub for questions, for, uh, open offers for like, Hey, first time as welcome up for grabs. Like that might not be what you want to do, but if you were say working on a hobby project or working on a uni project or something, and you end up using one of these packages or projects, and you see that they are asking for help, that would be a way that, um, you have some familiarity with the project as a user. So why not contribute back? So it's finding those things that you're comfortable with and, um, maintainers often, uh, overloaded and overburdened. So they want help, but also they're overloaded and overburdened. So it's hard for them sometimes to be able to dedicate the time to help new contributors into the projects. So, um, if you're going to contribute to something, read their documentation, read their contributor guide, make sure that you are, uh, working within what structure the project wants. So if they want people to discuss on, say a discord or a Slack first, or they want people to discussing issues first, or they're just like, send us all the pull requests, we want all the pull requests, just make sure that you look and check how you're expected to behave in these individual projects, because every single project is going to have something different. A lot of them have a standard way of doing things, but a lot of the more evolved projects will have, um, different ways of interacting. And you really want to make sure because all these people are volunteers. You want to make sure you're getting up, getting off on the right foot. And at the end of the day, you want to make the project better. They want to make the project better. So making sure that you're all working from the same set of guidelines is super helpful.

Olivia: 9:44

That's, that's, that's really good advice. So I guess, like on a kind of related note, what have been your favorite open source projects to work on?

Katie: 9:53

That is a big question. I mean, so back in the day I made the mistake of giving a lightning talk at a conference, a lightning talk, being a five minute talk, very short, you can submit the talking proposal and presented on the same day. And back at my, the first conference I ever spoke at, I made the mistake of giving a lightning talk, saying, I want to make a open source cross-stitch app. And I will present my resulting project, uh, here at this same conference the next year that didn't happen. But what did happen is now I have a, uh, fairly robust project that does cross-stitch charts. Like you upload it image, and it will make a chart that you can make into a cross-stitch like the stabby and the wool and the, like the grandma knitting kind of things. Um, but that project is something I started, but I've also now got a stitching circle that we're all making the same design using artwork from another person put into my app and all this current is open source. And so I've given presentations on this. Somebody else has given a presentation on like, uh, some of the usability aspects of my thing. And it's this you can do, you can write open source for things that aren't also open source. Like you can actually do things like art. Um, so that's been really fun and, uh, I I'm sure I'll, but it's those kinds of things where the code is just one aspect of the project. Um, you end up getting like an art out of it or ended up getting something else. Um, it's very fun. I met an alpaca pharma through this project. That was cool.

Olivia: 11:59

That's pretty cool. Yeah. I guess as a source of, um, materials,

Katie: 12:05

Complete tangent, there's an entire ecosystem of different companies that produce the different colors that you use. And so having to map the colors with computer colors is hard, but our pack is like, normally, unless you dyed the wool, the natural fibers don't have an RGB value. So it's like there's an entire science around trying to match colors. Um, but there is a standard alpaca palette that my project now uses as a estimation of what your final result will look like.

Olivia: 12:41

Nice. Alpaca estimation. What a fun like pool requests that would have been.

Katie: 12:47

It was very fun.

Olivia: 12:50

Did you get to get some, a firsthand experience with the alpacas just to make sure those were right?

Katie: 12:56

Uh, sadly not because we're all inside, but one day, hopefully,

Olivia: 13:02

Hey, it's say that, that was a very lovely answer kind of on that note. So you developed your own open source project. How did you find that experience and how would you, like, how would you like pass on your learning starters?

Katie: 13:18

It is okay to fail. Um, the alpaca project, shall we say? Uh, wasn't my first open source project, but it's definitely one of the first where I wasn't afraid to have things wrong. Um, I've developed other open source projects where I didn't know what I was doing. And so when people would submit, pull requests in, which was something that should have been very basic should have been, uh, Oh, why didn't they think of that earlier? The first couple of times you have that, where it's like, you are wrong. This is right. You need to step back and consider that this person has gone out of their way to unsolicitedly give you constructive mentoring and advice and improve your code. So that is definitely the thing that you need to learn because you're working in public. So you need to understand that, like people want to, most of the time help, there are going to be some instances where they are not helpful, but most of the time people want to help. So getting a random email saying such and such wants to improve your documentation. That is a very, very good thing. And you should encourage it. And you are now an open source maintainer because you're now accepting contributions out, as opposed to previously where you may have been putting contributions in. So it's very much the other side of that equation. Be okay to be corrected, I think is the number one thing. Hmm. How,

Olivia: 14:52

How did you find, I guess, cause personally I haven't started an open source project, but I'd imagine that, would that be like some difficulties in actually getting comfortable use?

Katie: 15:02

Oh, absolutely. Like, depending on what you want to build, no one else wants to build that same thing and that's okay. Like I have a whole bunch of repositories trees where it's just me, but that's okay. But there is an entire separate ecosystem around how to get contributions, how to build a healthy community and everything else. But it's kind of like the same sort of things around. If you want to build a startup, if you want to build a business, you have to inspire and want people like encourage people to help, but in open source, there's no financial benefit. So it's a little bit of a harder incentive, but there is like, it's okay to work on your own. People can find your stuff. You can, uh, there are many ways that you can encourage people to help out. Um, but it's not the goal that you like unless your goal is to build a community. There's going to be a whole bunch of thought about how you do that, but it's okay to work alone if you need to, because you are capable and powerful and you are a good programmer and you can only get better by practicing and sharing and getting people to take a look at what you're doing.

Olivia: 16:29

Yeah. There's a lot really to be left from developing an open source, both with your own project and on other people's projects, because of course you can leave feedback on pull requests as well. So I suppose like working on open sources are really great option to like, not only apply your skills, but also get feedback on them in a way that, uh, you often wouldn't in other applications.

Katie: 16:53

Yeah. And in all of this, it's not just the code part. Like I've been talking a lot about pull requests, but there's also like talking about open-source projects or what you've done and teaching people that way, or there's the documentation side where, um, like if you know, a second language there's translations that you could contribute to projects, there's actually a really good book on this. So I'll make sure that I link in the show notes for your future with open source, by VM Brasseur, it's from, uh, the pragmatic programmers and only some of this entire 160 odd page book. Only some of that is about code because there are so many other things that you can do to contribute, to open source projects. There's documentation, there's a support, there's maintenance, there's a community collaboration and community building. There's so many things like you don't have to be a programmer to contribute.

Olivia: 17:57

Yeah. I guess how, how do you find the documentation side of like writing side of things for open source?

Katie: 18:05

Oh, I have learned the hard way that if you don't document things, people will not do the right thing. I've had a person give a talk on one of my projects where some of the talk was talking about how they couldn't get my project to work because I hadn't documented it properly because I was making assumptions about people. People will already know how to install things and whatever, but no, you won't, you can, you can never, like there are some things that you can assume like, um, if you say that a project is available to download on a certain package repository, like you can assume that people know how to click a link on a page, but you can't assume that people know how to install a package, but there is a balance of like, here's how you set up and on your, on every single operating system. And here's how you install my package. And now here's how to use it because how to install Python and how to install packages is a completely separate readme, but you can still link to these things. Um, but yeah, documentation and technical writing is a completely separate profession. And I know when documentation is bad, it's bad, but when documentation is good, it's excellent. Like the documentation for the Django project is phenomenal. As soon as you get over that barrier of learning, how to use the documentation and what it's talking about and the concepts around the project. Once you get over that, you have this entire ecosystem of all the strange and wonderful things you can do in Django. You've just got to find the search bar and type in your search terms, and then you'll find it. But there is an entire art, an entire separate community of technical practitioners who talk about documentation at events, like, uh, write the docs and read the docs, meetups, and that kind of thing. That's an entirely separate profession of like actual editors and writers and linguists, um, that developers should at least get a level one or level two in that sort of multi-class system. If you want to think about it like a gaming thing, but, uh, it is definitely, there are professionals that go full level 20 on, on writing that. Yeah, they are amazing, wonderful people

Olivia: 20:41

On the more conference side of things. Um, how do you get involved with those kinds of conferences and what are they like?

Katie: 20:48

Uh, open source conferences when we were allowed to go outside where I think seeing a lot of conferences like, um, Ruby conference, Australia PyCon, Australia will have student tickets. So if you have an active, uh, uh, tertiary or secondary mailing address, you can get really cheap tickets. Um, they usually like the events are like, I'll talk about Python specifically, which is Python Australia, which is a event that I ran for a few years. We typically run on a weekend. So we, um, have accessible student tickets. So if you want to come to your capital cities convention center for a few days and chat about Python, it's accessible. Like it's outside of normal class time, it's a cheap ticket and you end up just getting absorbed into this community, just attending these events and then getting inspired by other people, meeting people. Um, some of these events have a development sprints afterwards. So, uh, all these people are flown into a city. Why not hang around for an extra day afterwards and actually do open source development and, um, meet the people that you might only see on our pull requests occasionally. And then you go back the next year and you go back the next year, and then you end up speaking at it, talking about your open source project or a pipeline Australia has had the, um, education showcase where secondary students talk about like how they've made IOT things as part of their schoolwork. And from there, they then like a couple of years later, Mike gave a talk. Um, and then you might end up helping organize the event. And then you might end up running the event. Or it's not just me, if you definitely want, like when we're let outside again, if you want a weekend of just brain overload, coding madness with a whole bunch of wonderful people do check out your, uh, local conferences. And a lot of them are still doing a monthly or weekly meetups as well. Um, either via zoom or other mediums, but meeting and talking to the people that would otherwise just be on a pull request is such a mind meld of, Oh, there are humans at the other side of this. There are people like me. Um, it's a really wonderful experience and I'm very, very much looking forward to when we're allowed outside again.

Olivia: 23:25

Yeah. I think, um, everyone is. Yeah. I think that's all of my questions for today. Um, is there anything you'd like to about the tool or anything you'd like to add?

Katie: 23:40

Like when I went through uni, there wasn't a lot of things on open source and depending on what you're studying, there might not be, but you can explore this sort of stuff in your own time, but do be wary that if you're going through uni or whatever, you can actually do things that aren't always coding. Like there is a balance of things that aren't coding and like a lot of, uh, you'll, you'll hear the horror stories about how, um, recruiters might say, Oh, you have to be doing coding in your own time and do all these projects in order to prove that you're a real code. I know you don't have to like if this kind of thing interests you and you want to explore it, you go ahead and do that. But no one should force you to prove your dedication by volunteering your time, your treasure, or your talent.

Olivia: 24:38

That is very fair for sure. Like, I feel like a lot of, uh, little places seem to have this whole attitude where if your, basically, if you don't program in your free time, you're not a real program. You're not actually interested in it. You not passionate about it, but right. That's just not true.

Katie: 24:57

Django has a, uh, incubator project called Django girls where they run workshops, teaching, uh, women and underrepresented minorities to code Django. And they used to sell t-shirts that said, this is what a programmer looks like. And every time I see like a woman, a person of color, um, any sort of person saying how wearing this t-shirt that says, no, no, no, really I am a programmer. You believe them. And if more people show that they can do this, but they can also be a well-rounded individual outside of coding. Then we can slowly start to consider that you can be an awesome programmer and only do a 38 hour week. These people exist.

Olivia: 25:47

Yeah. Thank you so much for joining me. And that's all we have for you today. Please join us again in two weeks from now, for our next episode, until then feel free to join our community on Slack at uqcs.org.