#132: Contributing to open source Transcript

00:00 Michael Kennedy: Are you new to open source? Or maybe you've been using it for a long time and never got around to contributing to it, wondering how to get started. In this episode, you'll meet Anthony Shaw, Dan Bater and Ronald Maravanika. All of these guys have been successful open source developers. I speak with them about how to find a welcoming project and what you need to know to get started. We also cover what open source project maintainers can do to help attract new and experienced contributors. This is Talk Python To Me, Episode 132, recorded July 27th, 2017. Welcome to Talk Python To Me, a weekly podcast on Python, the language, the libraries, the ecosystem, and the personalities. This is your host, Michael Kennedy. Follow me on Twitter, where I'm @MKennedy. Keep up with the show and listen to past episodes at talkpython.fm and follow the show on Twitter via @talkpython. This episode's brought to you by Linode and Talk Python training. Be sure to check out what the offers are for both of these segments. It really helps support the show. Hey everyone, before we get to the interview, I just want to share a little bit of the back story with you real quick here. So right before the show started, something happened in Zimbabwe that made this really difficult for Ronald to be on the show. There was a city wide power outage where he lives. Unfortunately, that's something that happens every now and then and right before we started recording, he had to scramble to find a place where he could just get in touch with us and get online. His audio might not be as good as he had planned and I just want to let you know, so you don't think you know, he didn't set up for this, he made heroic efforts to get onto the show and I just want to say thank you. A special thank you to Ronald for that and also, if you're thinking about the challenges of being a software developer, sitting in the US or Europe or somewhere like that where the power is on 99.99% of the time and it's all a matter of just the code, think about battling things like power outages just to contribute to open source. Once again, Ronald thanks for being on the show along with Dan and Anthony and I want to make sure you guys got the back story because we lose Ronald for a moment as he has to work around to find some way to be on the show. Dan, Anthony, Ronald, welcome to Talk Python to Me.

02:23 Anthony Shaw: Thanks.

02:24 Ronald Maravanyika: Thank you so much.

02:26 Michael Kennedy: Hey everyone, it's great to have you here. It's going to be an adventure, we have three of you on the call so we'll try to do our best to not step on each others' toes, but I'm really looking forward to our conversation about contributing to open source and we want to take this from basically two perspectives. We're going to spend the first half of the show on how do you get started as a new person or a relatively new person to open source. How do you find a project, how do you, just what are the steps of getting started at all? When are you ready, things like that. The second half is about running an open source project and getting contributors and welcoming new people to your project, so that's sort of the road map for our project but let's start with your story. Anthony, we'll go with you first. How did you get into programming in Python?

03:15 Anthony Shaw: Yeah programming it was probably early on, I think I was 13 when I started coding for the first time. Python was definitely a lot more recently, three years ago now, I think it was, and that was actually working on an open source project called Live Cloud and I've been working on that ever since. I wanted to make a contribution to the project, realized it was in a language that I didn't know how to write so sat down over what was a long weekend and basically took a few courses and learned Python which was a great experience, really easy to learn.

03:46 Michael Kennedy: That is taking it to a whole other level, I want to contribute to this project, I don't know this technology, so let's learn it.

03:51 Anthony Shaw: Yeah I wouldn't generally recommend that path.

03:54 Michael Kennedy: It's awesome, it works well for you. Okay, Ronald how about you?

03:58 Ronald Maravanyika: Python for me started as something just very new at that point I was an intern, an engineering intern at one of the international companies here called Unilever. When I was there there was a project of describing problems with scattering downtime and stuff like that. When I looked around, the only language that could seek that was Python and this meant that I had to be fluent in programming, so I looked around and then there was a scholarship where people were being taught Python for free by Econic Wireless which is a mobile company here and six months later, I joined in the program and that's how I started coding with Python since then. Right now I'm mixing in too the engineering aspects and the developer aspects, but yeah, pretty much that's how I noticed with Python.

05:04 Michael Kennedy: Oh yeah, that sounds really cool. Doing networking type stuff, you're like I've got to talk to these devices maybe something more than bash is required or something. Cool, Dan how about you?

05:16 Dan Bader: Hey so I got into Python on a ski trip. I was going to university for computer science at the time and a group of friends were going on this ski trip and obviously we're all a bunch of nerds who didn't have any computers with us but one of my friends, he brought this tiny little book, Learn Python in 20 Days or something. Those ones that make all these promises that never really work out.

05:40 Michael Kennedy: Learn Python on your ski vacation.

05:42 Dan Bader: Exactly, and I just had been programming for a while and I just fell in love with this language. Funny enough, the same friend also later on introduced me to who is now my wife, so this is,

05:57 Michael Kennedy: That was a heck of a trip.

06:00 Dan Bader: It was a heck of a trip, not on the same trip though, but yeah Python and got married, yeah got a lot of mileage out of that.

06:06 Michael Kennedy: Yeah that's very cool. All right guys, let's start on the very beginning, just how do we get started contributing to open source? Let's maybe start at a high level, start from why maybe do you want to get involved in open source at all, Anthony you want to take that first one?

06:25 Anthony Shaw: Yeah, sure. I guess how many of you out there actually use open source software? Everybody I hope, Python itself is open source, all the packages that you use day to day are open source and someone's got to maintain those projects. I don't think it's an obligation but I think everyone really should think about the software that they're using, the software that they use every day and actually think about giving something back. Maybe that's contributing a bug fix or doing some documentation, there's various different ways you can contribute to open source projects but most of the projects on PyPI for example, are all open source, so yeah I really think people should get into it as a way of helping improve the whole Python ecosystem.

07:10 Michael Kennedy: That's an interesting thought, that you don't exactly owe it, but you almost do. You owe it to yourself to be a little more committed to the tools that run your life as a developer or someone in software, if you're that involved to work with software every single day, a particular piece of software, maybe you should help a little, just so much so that you actually learn a little bit how it works and have a little bit more control over it.

07:39 Anthony Shaw: Yeah and if you use a project in particular to a very advanced level, I think at some point, you're going to be frustrated with things which are missing or don't work properly and contributing back to the project is a great way to fix it.

07:51 Michael Kennedy: Yeah, for sure. Ronald, how about you, what do you think some of the benefits of getting involved in open source are?

07:56 Ronald Maravanyika: Speaking from our side, or the African side of things.

08:02 Michael Kennedy: Yeah just so everyone knows, you're in Zimbabwe right?

08:04 Ronald Maravanyika: Yeah, I'm in Zimbabwe.

08:06 Michael Kennedy: Great, I'd love to hear that perspective.

08:08 Ronald Maravanyika: Day to day, most of the software that we use this side, it comes from other countries like India and the UK so what happens is, companies pay a lot of money to use those softwares every month. In here we got experienced developers that can actually create those softwares but there's this notion here that foreign is always best. To me, I got into open source trying to show these guys that these developers you are hiring, we are contributing to those softwares. That way people can now try to look at that eye that wow, that guy's actually serious. Because the notion has been there for a long time that foreign is always best, but I believe that software should be made for Africans by Africans, if you know what I mean, so basically the African sites, the Zimbabwean sites that's why we should contribute into open source.

09:28 Michael Kennedy: I think that's a really interesting point. I think open source has this ability to basically make this software something that everybody can use. It's not like half a million dollar Oracle installation. It's something that you can go to the internet and you can get and you can get the source code and adapt it to whatever you need. I think it's really interesting to think about how that works in places like Africa where it's not a little bit of money to buy some software, because of the currency, other software is extremely expensive and this is also a way to empower people there to say we are building this software and if we need to or want to, we can fork it and make it our own right?

10:11 Ronald Maravanyika: Yeah that's exactly it. Get that state where we can read off software that can be as Africans go to software that can be used worldwide and people are comfortable with them but for us to do that, there should be a trust. These people that we are talking about, they are running a business they have met their investments and they are not willing to take any risk just to have their software made by an African. The quality of the software should definitely meet the standard that we need.

10:45 Michael Kennedy: There's a big push for tech startups in Africa. How do you think open source is a factor in that? Do you think this is pretty uniformly used within the tech start ups around there and it makes it more possible for that whole thing to work?

11:00 Ronald Maravanyika: Here the situation is, because like I said before, the economy situation here is very harsh and people literally don't have time to do something that is not feeding their family. For someone to contribute into open source and they are not being paid anything for it, to them, it's like they will be wasting time. That's not the case. For tech start ups here, I think open source is helpful to getting the experience and trying to get that quality that would meet the global standard. This is how open source now is affecting the tech start ups and now I have a little bit of some guys who I have joined into the open source community and you can see from their projects that things are moving forward. When you are in open source, you definitely need a lot of help from a lot of people. Along the way, you get the experience and you get where you're messing things up, so to me I think that's how open source can contribute to tech start ups.

12:33 Michael Kennedy: Sure, okay very cool. Dan, I'll ask this question to you. I think one of the biggest challenges for people getting started in programming, maybe they've been programming for a while but in a more constrained environment, standard corporate America or something like this, they don't necessarily feel like they're open source developers. This imposter syndrome is a pretty real thing, especially for people learning a new technology or learning a programming language for the first time. What do you think about this imposter stuff?

13:08 Dan Bader: Well first of all, I think it exists, and I think you're touching on a really important problem that's holding people back from contributing to open source, either because they want to give back to society or because they just want to work on something cool. The idea of this imposter syndrome, or what imposter syndrome is that, like you said, you don't feel worthy and you're scared to put yourself out there. This is exactly how I felt when I published my first open source project that I started and pushed it to GitHub and actually posted the link to Reddit in Hacker News and it was just sitting there. I remember going to bed because it was in a different time zone, I remember going to bed and almost lying there and shaking in anticipation, what would happen. I got up the next morning, checked my email and it was almost, at the time, I perceived it as my worst case scenario, I had some really experienced people shoot me down and someone said, this should have never been written and who would use something like that and I was like oh my God, sorry guys, what did I do here. Now looking back, I obviously have a very different experience or a way different perspective and I'm glad that I went through this but you know, the struggle is real, absolutely.

14:31 Michael Kennedy: I also feel like part of the problem is, when people are new, they look at the things that they know that are major and you probably start using Django or Python or something really big and mature that there's no low hanging fruit left. It is all hard work and every little change has to be considered over all these use cases. It looks really really hard, but there's thousands of projects out there that could use a little help, even with things like documentation or something, right?

15:02 Dan Bader: Yeah, I totally agree. What we're seeing there is the equivalent of Elon Musk building his rocket ship, we're seeing this super fancy cruise ship or the latest BMW car and what not and of course, you can't compete with that because that stuff, the Linux kernel was built on probably millions of hours of work by hundreds of thousands of different people.

15:26 Michael Kennedy: It's highly polished.

15:28 Dan Bader: Yeah and it's highly polished, the barrier to entry there is so high, but really what you should be aiming for is the equivalent of building your own bicycle and riding that around town, maybe you get one or two other people who are like, that's a nice bike, can I ride that?

15:43 Michael Kennedy: Yeah that's a good point. Oh I saw your bike had a flat, so I fixed its flat tire.

15:47 Dan Bader: Yeah.

15:51 Michael Kennedy: Awesome, I'll put in the show notes, something by Adrienne Friend, she has basically an imposter syndrome disclaimer which is a markdown file you can include in your GitHub project that says no, no I really want you, even if you're new and here's the way in which I can help you. We're going to switch to that in just a second, but Anthony let me ask you, do you think you need to know Git or you talked about learning technology, maybe you have to learn how to do GitFlow, you have to learn what GitHub is, how do you get started in all that?

16:20 Anthony Shaw: Yeah there's some great videos out there already. There's one that Scott Hanselman put together about getting involved in open source that talks about the work flow to create an account on GitHub for example, how to raise a pull request and some of the basic steps you would take. I'd say that you definitely need to know a basic level of Git because most of the projects, pretty much all of the projects that you'll come across will be based on Git for their source control, I think if you don't know that already, I would go and learn a very basic level. Don't get into any of the advanced features and functionality of Git yet, that's definitely a minefield, but once you've learned that, then yeah pick something simple and the other thing I recommend people do is create a sandbox project first. Once you've created a GitHub account, then just create a project that's got nothing useful in it, just add some files, make some changes, do some commits and use it as a bit of a sandbox to learn how to use Git and be familiar with it and also raise a pull request against your own project, which you can do and that gives you a good place to practice I guess and experiment with things without having to do it in real life.

17:27 Michael Kennedy: Yeah or make that part of your contribution which then you have two different things you're trying to learn at the same time. There's a bunch of nice GUIs as well, it doesn't have to be all CLI, command line driven stuff. It could be SourceTree or the GitHub tools or things like that, so that's nice.

17:45 Anthony Shaw: There's maybe one great tool to throw in the mix there, it's called GitUp and personally I feel like it doesn't get the recognition it deserves. I think it's a great GUI, it's a free open source tool. I think it's available for Windows and Mac, maybe just Mac but still a great tool.

18:00 Michael Kennedy: Nice, awesome. All right Ronald, you talked about contributing to open source and some of the challenges people in Africa are facing, this kind of gives you a chance to equally show up in the international tech world if you will. If you have a popular project or you make a big contribution that can really make a big difference, how do you see, do you think contributing to open source will help you get a job there or is it just better for learning and then you've got to do something else? What do you see from your perspective?

18:30 Ronald Maravanyika: Okay one of the people that really encouraged me to get into open source is Mike Place, UX for Source Tech and Source Tech, they make their business model is around open source software. When he came here for mentorship week the Zimbabwe mentorship week, we were just talking to each other and he showed me all these emails of companies asking him if he wants a job. These are huge companies, like Amazon, really huge companies and what they would say is that they saw his GitHub account and they liked what he did, so despite the fact that open source you can do it to get your skills to that level, I'm also doing it so that in the near future, I can get a good job. Honestly I don't believe in moving in from the continents, going to other continents, it's not fair for the people that live in that country, so open source is a way that you can stay in your country but do your project and most of the time, the job you get will be a remote job, you don't require to leave or get or stuff like that.

20:01 Michael Kennedy: Yeah open source definitely leads to more remote work, just the nature of it, people are more willing to accept that rather than a standard developer job or something.

20:11 Ronald Maravanyika: Yeah, definitely, so to me, getting the experience and also trying to get noticed out there.

20:19 Michael Kennedy: Okay that makes a lot of sense. This portion of Talk Python to Me is brought to you by Linode, are you looking for bulletproof hosting that's fast, simple and incredibly affordable, look past that book store and check out Linode at talkpython.fm/linode, Linode. Plans start at just $5 a month for a dedicated server with a gig of RAM. They have 10 data centers across the globe, so no matter where you are, there's a data center near you. Whether you want to run your Python web app, host a private Git server or a file server, you'll get native SSDs on all machines, a newly upgraded 200 GB network and 24/7 friendly support, even on holidays and a seven day money back guarantee. Want a dedicated server for free for the next four months? Use the coupon code Python17 at talkpython.fm/linode. Dan, I know you're asked frequently through your Pythonista Cafe, through other things that you're doing, how do I get started in Python, how do I make my first big step so that I can get noticed and get a job and you and I both answer these questions fairly often. What do you think?

21:22 Dan Bader: In my last position, the last job that I had, I spent time every week reviewing resumes and doing phone screenings and just interviewing engineers. I would say that having a solid open source portfolio or just anything up there, it's definitely a credibility indicator but I don't think it will ever fully tip the scales, I think rarely will people get hired purely based on their open source contributions. Sure, you're always going to have the top 1% of people, if Linus Torvalds is looking for a new job, I'm sure he's not going to have to look for a long time, but the average person.

22:04 Michael Kennedy: Yeah I think it's similar, right if you create something major like Django, Flask, if there, or like SQLAlchemy for example, like Michael Bay, doesn't probably need to go and look for a job if he doesn't want to. You could lever those types of things. But adding a minor feature to even a popular project is not enough alone probably, but it's one of the building blocks maybe.

22:29 Dan Bader: Yeah exactly, it's not good enough alone but it's still going to be helpful and it's more of a long term play I think. Almost every week I get a question, how can I get more stars or likes on my GitHub project and how can I promote this so that it will lead to me getting a job and I think that is probably not the optimal way to go about it. I think what's probably vastly going to increase your chances is just to apply to like five jobs every day. I would rather spend my time on almost this prospecting work and reaching out to people and building relationships and meeting people for coffee rather than thinking oh, how can I get 50 more likes on my open source project. But I can totally see where that motivation comes from because I feel like when you're from the outside looking in, it can seem like obviously this person got a job because they have a well-liked or popular open source project but I would see it as a decent signal, but it's not going to be the only thing that's going to make you successful.

23:33 Michael Kennedy: Sure, like social proof, I applied to a job and when they go to look at my resume and think about what I've done, here is proof that I've actually done the things I said I've done, you can check out the quality and so on.

23:46 Dan Bader: Yep and it can also backfire. If you, I've reviewed a bunch of resumes where people, they just had forked another project and then put their name in as the author and you could actually see that in the commit history and so that is not a positive signal that you want to give off. You got to balance it with that, but in general, I would say it's great work, it's very rewarding and it can help you find the job of your dreams for sure.

24:12 Michael Kennedy: It's definitely a way that you can get experience in some part of technology where you can't immediately find a job but then after you can say yes, I have experience in this thing. Anthony, you are in a place where you maybe review some resumes and think about giving people jobs, what do you think about this briefly?

24:29 Anthony Shaw: Yeah I've probably interviewed about 300 developers in my lifetime, I'd say if they include a GitHub profile on their CV, then I'll definitely have a look at it and I'll see what kind of projects they work on and look at some of their code stars and stuff like that, but that's not a requirement, that will come up in developer interviews anyway. We'll talk about how you break down problems and how you address things, but it is good to see people actually, what it tells me more is not that they contribute to projects, it's that they have a passion outside of their work. If someone really cares about, I was interviewing C# developers, if someone's really passionate about C# .NET or the technology that they work in, they will probably have lots of pet projects on the side. Or maybe just one or two and they probably have other things they want to tinker with and that tells me more about what they're going to be like at work because if they really care about their profession, then they're going to be a great developer. I think that is more what it's about for me.

25:32 Michael Kennedy: Yeah it's like a signal that this person is something of a self-starter or self-learner and passionate, I think that's a huge signal. Maybe this is a good point to talk about the website you shared with us a little bit ago, firstpr.me.

25:43 Anthony Shaw: Yeah sure, I found this one, this is part of first timers websites, there's a couple of really cool links you can look at, one is firstpr.me and you can type in someone's GitHub username and it will show you the first pull request that they raised, so I've had a look, Mike yours was in C#.

26:02 Michael Kennedy: It was yeah. Something with MongoDB.

26:06 Anthony Shaw: Yeah MongoDB Linq Queries and Dan, I was pretty impressed, yours was Python 3 support for a project called pip Rocks. Yeah mine was the learning Python over a long weekend contribution.

26:22 Michael Kennedy: Yeah that's really cool. You can actually, you put in a name there, then there's a link to say show me every pull request that this person has ever made in GitHub which is pretty good research if you're looking to work with someone.

26:34 Anthony Shaw: Yeah definitely. There's some other great ways as well to do some background research on people and look at what their contributions are, it's not just about code commits, it's about a lot more than that.

26:44 Michael Kennedy: For sure, all right that's a ton of information on why getting started is good, what it can give you, maybe what it won't give you, things like that. Now Dan, I know you've done a lot of work trying to help people basically evaluate open source projects and you did some of this around the concept of packages, so at Py PI we have, gosh I haven't looked for a while, well over 100,000 packages, virtually every one of those is open source and is a thing you could contribute to, but how do I go to find something that would be good for me if I was looking for this, especially if I was someone new?

27:22 Dan Bader: That's a huge problem because there's so much stuff, it's like a whole forest of packages, how do you find the one tree that is just perfect for you.

27:32 Michael Kennedy: It's not too tall and too hard, but also not like a weed.

27:37 Dan Bader: You want to make your bed out of or whatever and because it's a big liability issue as well. If you pick the wrong project there, potentially if you're working for a company and that bit becomes part of the code base you're working on you may have to support this for several years in the worst case. I've been thinking about the process that I use, that I used and I evolved over time, how to go from, I have a need for some problem I am facing, let's say I'm working on a Django app and I want to add some special form validation, whatever, how do I go from having identified this problem to actually finding a good package that I can pull in and it would solve my problem, I don't have to write it myself, I don't have to reinvent the wheel? I think it comes down, from a high level perspective, it comes down to coming up with a pool of candidates there, candidate packages that sort of kind of do what would help you, what you're looking for.

28:37 Michael Kennedy: Before you go on, I think one of the things that you touched on there that's interesting is, it will do what you need to do. I wouldn't necessarily think just randomly hunting GitHub for projects and then trying to contribute to them necessarily makes sense, but if it's something that you can use, that you can basically, because you need that experience of consuming and using the software to even be reasonably able to contribute to it I think.

29:01 Dan Bader: Yeah absolutely, I think it's not, open source isn't a silver bullet where you can just go in and it's like going to a candy store and whatever you get there will be great for you. Not even a candy store is like that. It feels great, but then a day later, you're going to pay the price for that. Oh my God all these horrible analogies. But I think it really comes down, really identifying this need and also having the knowledge to know what you're really looking for because otherwise, it's just impossible to find a good solution.

29:35 Michael Kennedy: Yeah for sure. Okay you talked about checking the package popularity as one of the things.

29:41 Dan Bader: Yeah and I think for me, it all comes down to having these heuristics because there's so many packages there, you've got to have some heuristics to just cut that list down to size so that you can ideally select something that works for you and I think there's a good way to do that is for example is to go with a curated list, for example there's awesome python at awesome-python.com and they have a curated list of packages and that's also an open source project where people can add new projects that they liked and it's sort of a filtered view of everything that's out there, but obviously it's not going to cover everything so this is also not a panacea. You got to do some leg work and look at Stack Overflow and maybe see if you can find some Reddit comments on a particular package, just to get a feel for the quality of it.

30:28 Michael Kennedy: Yeah absolutely. I think the project home page and the read me, those kind of play similar roles, but those give big indicators of does the person who created this project really care about it. Is it worth my time to contribute? You only want to contribute to a project where the maintainer actually cares about the thing.

30:49 Dan Bader: Yeah or where you're confident actually becoming the maintainer yourself, that's why I always want to spot check the source code and think about it. Would I feel comfortable making changes to this project myself, would my team feel comfortable making changes to this project, because otherwise, it's almost like you're pulling in this binary blob that no one really understands and it is Python source code, but if it's a really complicated project, then that could really derail things and you might be better off going with a different solution or coming up with a custom solution. I think it's all about these trade offs and really scrutinizing what you're bringing in into your system there.

31:30 Michael Kennedy: Sure, absolutely. Ronald, what do you use as a way to find projects that you can contribute to?

31:38 Ronald Maravanyika: It was really hard to get into open source. I asked around on social media, it was, I just wanted to get involved in open source. Most people recommended Open Shift as one of the projects, so I went there and to be honest with you, I understood nothing about that.

31:59 Michael Kennedy: Yeah because that's a big project right?

32:03 Ronald Maravanyika: Yeah and people were saying this is the easiest project to start on and stuff like that. I picked up a little bit and tried to start with local project so for example, I started with contributing for the Python Zimbabwe website and the Pyramids website, stuff like that, the simple stuff.

32:30 Michael Kennedy: Yeah that makes a lot of sense to start there.

32:33 Ronald Maravanyika: Still now I'm trying to get into bigger projects, but the choice is how to choose the best project which is not too deep, it's a little bit hard, it's still very hard for me to decide on that.

32:52 Michael Kennedy: It is a challenge, one thing I'll throw in there is I mentioned Adriana Lowe's Imposter Syndrome disclaimer. I went and I took a piece of text, the title of that and I threw it into GitHub and I searched for projects that had adopted that disclaimer which is like hey you're welcome to get started. So I found 23 projects so far that have that in there, so those are places where newcomers are welcome I guess. Anthony, it's not just writing code necessarily that people can help with, there's documentation, there's examples, there's evaluating issues and PR's, like a first pass to see if they make sense, things like that right?

33:34 Anthony Shaw: Sure, I think the kind of case that you're talking about is quite typical, sort of Goldilocks and the GitHub projects, you're trying to find one that's not too big and too complicated, that's not too small and doesn't get maintained, maybe find something in the middle. I think people have this expectation that their first open source contribution will be this killer PR where they improve, oh I fixed this bug or I've added 20% performance improvement and really as a project maintainer as well, whilst I would love those pull requests, there's a lot of other stuff that we do need and contributions to an open source project are not just about code, so there's simple stuff like code reviews, you don't have to be a maintainer of the project to do code reviews. If you see a fairly popular open source project and you're pretty good at reviewing other people's code, maybe you do that as part of your job, then there's nothing stopping you going in to someone else's project and doing code reviews. Obviously you have to understand their style guidelines, what the rules are for that particular project and what their preference is, but code reviews. I'd love more people to do code reviews on projects that I work on. Documentation is also a really popular one. Quite recently I contributed some to the BWare project, Russell Keith McGee, he's been a guest on a past episode.

35:00 Michael Kennedy: Yeah and he's very welcoming, that project is very welcoming to newcomers as well by the way.

35:04 Anthony Shaw: Yeah definitely, my first contribution was to write a blog article about how to use it and then whilst doing that, I think I learned more about the project and how it worked and then my other contributions were all documentation because that was the gap that I saw at the time. For me to get up and started with the project, there were a few things which weren't super clear, so taking that learning and sharing it back with the project this is really about where you want to be an experienced user of the project in order to make valuable contributions. To start off with, those contributions could be testing and documentation and I don't think people should be making drastic code changes to a project if they can't at least document the thing they're changing or they can't write a test to prove that it already works, so yeah, especially for big, complicated projects, you might find that maintainers are not going to be very comfortable with someone coming in to a project and making some drastic changes because you've got, you don't know what other expectations there might be for the users. Yeah, documentation and the tests are really great and also contributions more softer contributions, so this could just be presenting at your local Python meet up about a project. This could be blogging about it, tweeting about it, sharing it on social media as well as the maintainer of projects, I really value those contributions because those are people helping out with the whole community, they're not just helping out on the code base. Sometimes that's actually most of the work.

36:35 Michael Kennedy: This portion of Talk Python to Me is brought to you by us. As many of you know, I have a growing set of courses to help you go from Python beginner to novice to Python expert and there are many more courses in the works, so please consider Talk Python training for you and your team's training needs. If you're just getting started, I built a course to teach you Python the way professional developers learn, by building applications, check out my Python Jump Start by building 10 Apps at talkpython.fm/course. Are you looking to start adding services to your app? Try my brand new Consuming HTTP Services in Python. You'll learn to work with restful HTTP services as well as SOAP, JSON and XML data formats. Do you want to launch an online business? Well Matt Makai and I have built an entrepreneur's playbook with Python for Entrepreneurs. This 16 hour course will teach you everything you need to launch your web based business with Python. Finally, there's a couple of new course announcements coming really soon so if you don't already have an account, be sure to create one at training.talkpython.fm to get notified and for all of you who have bought my courses, thank you so much, it really really helps support the show. One of the issues, I guess I didn't bring this up in finding the right project, but one of the things that I look at, it's not a deal killer if it's in a bad state, but something I think is a really strong signal of the health of an open source project is how many open PR's are there and how many open issues are there, especially unaddressed, like how many people have tried to contribute a feature to this and it wasn't even responded to? How many people have filed an issue and tried to ask for an improvement and it wasn't even responded to? How do you feel about that?

38:13 Anthony Shaw: Yeah there's a few projects that I work on where I've tried to fix things in the past and the maintainers have maybe written the project as part of their day jobs and then they've moved companies or they're just not interested in maintaining it and the solution was actually to raise an issue saying, this is a notice for anyone else, I'm taking this party somewhere else and then basically just maintaining a fork and publishing a separate package on PyPI. That's actually taking it on really and forking a project and open source is, if you go and look at the Linux distro graph, it's a sort of history of Linux distributions, you can see how they've gone the same way in OS's.

38:55 Michael Kennedy: Yeah it's pretty interesting, that's kind of like the nuclear option, but sometimes it has to be done if it really is abandoned.

39:02 Anthony Shaw: Yeah give them a chance, give them an opportunity, but if you're still using the software and you need things fixed and you need bugs updated or you need it to work with Python 3 for example, then absolutely I'd encourage building a fork but then also maintaining a fork and publishing it as well so other people can access it.

39:19 Michael Kennedy: Ronald, what advice do you have for, are there things that you do that you've found when you're filing a new issue or issuing a PR to an open source project that you do that make it more likely to be accepted or received well by the person running the project?

39:35 Ronald Maravanyika: One of the things that I do is I don't want people to suspect what my PR will solve. On the comment I will state exactly what the PR is doing. This way it's easier for the maintainer to either accept or reject your pull request and it's actually very easy way for dealing with small projects. When they get to the bigger projects, maintainers may not treat those comments. It just depends with the type of project that you are in.

40:16 Michael Kennedy: Yeah I guess having a really clear, well thought out, well-structured message or comment associated with the PR or the issue or whatever makes it seem like you're serious and makes it easier to understand what's going on. Some people just throw out a sentence or some very small thing and how serious do you want to take that work right?

40:36 Ronald Maravanyika: Yeah that's it.

40:38 Michael Kennedy: Sure. Dan, how about you, when you're evaluating a PR, or issues or things like that, what do you look for?

40:45 Dan Bader: I think for me, when I became a maintainer of an open source project and I started getting PR's, for me the key realization was at some point, hey this is really more, this is a social project and not only a technical project, where we're just looking for technical solutions for things. I think it is really important, whether you're running a project, an open source project or whether you're contributing to one, or maybe you want to get the foot in the door there, just to be very careful around the social dynamics there and basically just being friendly. Introduce yourself and just say hi. Instead of just throwing a bunch of code over the wall, actually try and understand to see which direction this project is going.

41:35 Michael Kennedy: That's a good point we talked about before we hit record how we've all submitted PR's and actually we had solved a problem but it was actually taking the project in a direction that wasn't part of the road map, they weren't interested in going that way and so we did all this work and threw it at them and they're like this is really cool, but we're not going to take it because it's just not where we're trying to go with this.

41:57 Dan Bader: Yeah it feels bad on both sides. As a contributor, it feels not that great if you're putting in all that work and if you're rejected, and as a maintainer you feel horrible because you have to reject someone's potentially very good work, you can see they invested a lot of time into this but it just takes the project into a different direction. What's also important to realize is that as a maintainer, you have a lot of responsibility to actually be able to maintain the project. If there's a new feature that you don't fully understand yourself, maybe that hasn't been requested by other people before, I'm always leaning towards not bringing that feature in because I want to be very careful that I actually know what's going on with the project. It's very easy to get a mixture of different code styles and just a mixture, just architecturally to have a quickly very unmaintainable project or very unmaintainable code base and it's just so much harder to go back and rewind and then say oh, you know what, now we're going to spend some time rebuilding this thing. I feel like that's harder to do than just being very careful about what contributions you take on and which direction you grow the project.

43:08 Michael Kennedy: Sure, how do you feel about things like continuous integration, Travis CI and that kind of stuff that sort of evaluates from a correctness standard the PR's initially?

43:18 Dan Bader: It's great that you're bringing that up. I think these days it's table stakes for any open source project, it's so easy to set that up if you just have Circle CI or Travis CI, they all have free plans for open source projects. They're like free build server farms where you can build your project and then you get a notification via email and a comment on your pull requests and you can set it up so that it runs a PEP8 check or a linter check on your project and runs all of the tests and that's going to make it easier also for you as the maintainer and also for a contributor, just to cut down on some of that back and forth. We're not following the code style here. It just reduces the code review time. I think any open source project should take advantage of that kind of technology.

44:05 Michael Kennedy: Yeah I agree, I think one of the interesting things is you mentioned this is a social experience. There was some studies done that said people are less frustrated by getting this nitpicky feedback from a machine rather than from another person. Let it say no, your indentation is wrong, no this doesn't have a doc string, whatever as before the thing is accepted. I'll review it once you pass the continuous integration. That's really nice.

44:36 Dan Bader: Yeah and I'm a very nitpicky code reviewer and when I became a team lead, one of the things that I realized very quickly is that you got to absolutely pick your battles because you're just going to be upsetting people so having a linter in place on your CI infrastructure continuous integration infrastructure, it just takes away some of those discussions. Everywhere you got to make the tests green.

44:59 Michael Kennedy: Yeah it's not my fault, the machine says.

45:03 Dan Bader: Sorry I can't do that Dave.

45:05 Michael Kennedy: That's right, sorry Dave. Anthony, another thing that's worth talking about while we're talking about running a project is burnout. It's one thing to, I've talked about the unanswered PR's, the unanswered issues and stuff but the dark side of that, if you will, is people expect that you maintain your projects at often really unreasonable levels. You have this project, I filed a PR, why isn't it here yet and people have jobs, they have lives, they're busy, burnout is a real issue here as well, right?

45:39 Anthony Shaw: Yeah definitely and a lot of people that contribute to open source do so in their spare time as well, so I think the expectations people have for maintainers, for reviewers is pretty high and sometimes a little bit unreasonable. As part of my day job, I think I manage 26 people, I've got a lot of things to do during the day, I've also got three children, so I've got a family and a house to also maintain. These things add up and it's important for me, I think for me I kind of make sure that I'm realistic about setting expectations with people about how much I'm going to work on a project and actually not feeling guilty to say you know what, I'm going to step back for a bit because I've got other things to focus on. I think I've found in the past that especially focusing on really unhealthy things like your GitHub contribution graph, how many recurring days you've done, what's called the running streak was like how many days in a row you've contributed to open source and GitHub actually took this feature out because it was really encouraging the wrong behavior. For my contribution graph, really I make sure that I've got a good healthy number of days where I'm not contributing anything because I'm spending time away, spending time with my kids and actually trying to get that separation, otherwise people kind of feel obliged to constantly almost be on call for a project and remembering that this is your time, it's your contribution and there's no obligation and actually try and invest some of that time to getting other people to help out and getting other people to contribute, because if you advertise a project more or if you try and delegate work then those kind of skills that you'll learn from open source will absolutely help you in your day to day job, that's a really typical problem that developers have as they work their way up the ranks is that they get to be the technical specialist for a particular project or the principal for example and everyone comes to them with queries day and night and they burn themselves out because they don't learn how to delegate work so that's a really critical skill I think people have to learn and you can do that open source, you can do that during your day job, but if you work in technology, you're going to have to figure that out at some point because otherwise, you're going to be the go to person for that piece of technology and you're going to be supporting it for the next 35 years and do you really want to do that?

48:10 Michael Kennedy: Yeah that's a really good point. Maybe that's a great way to segue to our last topic, which is if you're running an open source project, how do you make it attractive? How do you attract people to it because then, you'll get help, you'll get people to come along and help with code review, help adding new features, help write the documentation and so on. Ronald, let's start with you, what are some of the things you think people running projects can do to make their projects attractive to folks like you who want to contribute to open source?

48:44 Ronald Maravanyika: The first thing, it's little but it's a big deal. The first if a PR I did it was accepted. But then, I was new to open source so, I'm not sure whether it's accepted, whether it's rejected, I wasn't sure, waiting for a few hours trying to learn Git, at the same time, trying to contribute. That's more my suggest to say thank you or that small comment to say your code is okay but you have to fix and it's really important. That's one of the things that's going to attract people to your project because most of these projects, you get into them through referrals. If I enjoy the way I am working with you on a project, definitely I'm going to refer to the next person who is close. Then the fundamental of getting into open source, it's all based on clear highlight of things. I have this notion that the coding part of things is easy but the project frameworking, that's the most hard part. When you're trying to start your open source project, make sure the story behind your project, like and also if you see questions because countries are different, cultures are different. Try to explain your issue, what you are trying to solve. Then make clear frameworks of what you want things to be done and then from there, people can get there and they relate to that question because when someone is getting into a new project that they are afraid of being embarrassed so they don't want to ask questions. Try as much as possible to make sure that people don't ask questions to make sure that people that want to contribute to appreciate it. Anthony said it a while ago, that an open source contributor you have put a lot of work into it and it's hard to just know that your work has been rejected and there's no message for that thing, something that's just done, so especially for me, especially is that little message, just communicate with your contributors whether you accept or you don't accept their PR's.

51:34 Michael Kennedy: Yeah I think this is important because like I said, having the unaddressed issues, the empty PR's, that looks really bad for the project. Even if you have to reject them or close the issue, just having that communication there makes a big difference.

51:49 Ronald Maravanyika: Yeah that's absolutely right and then if your frameworks are okay, maybe just me but to me, putting up those frameworks is the hard part. The coding part of it is really easy or maybe you may differ in the direction that one person wants to go and the other wants to go, so if those things are clear and even putting a picture on deeper mission of your project, if it applies in that situation, it will be so helpful, so that's what I think people should do to attract more people on their project.

52:28 Michael Kennedy: Yeah awesome. Certainly having that disclaimer I talked about before, to say welcome or things like the BWare folks have, they have almost a mentorship program, so making it very clear that newcomers are welcome, I think is a big deal. Dan you spoke of continuous integration, that's probably another good signal that you care about your project. What else would you recommend there?

52:49 Dan Bader: I think there are definitely some very actionable tactics that your listeners could apply, I'm just going to throw out some of them and this is not going to be, this is not going to solve everything and just make your project super popular, but I think it definitely helps. A couple of things you can do there is just having a really clear, one sentence description of what your project is for, what it does and for who. What's the benefit to your user. You can actually put that on GitHub, you can put it in the, they have a tagline or subheading setting all the way up there, or put it right on the read me and I found that a lot of times that is missing sometimes I find something and feel like this seems like it sort of relates what I'm trying to do, but what does it actually do? I think that is really important, just being very clear about it and then maybe want to have some code examples right below that so people can see how it works, you can put these little badges that you can integrate with your continuous integration setup, so you can show people what your test coverage is like, how the latest, how is master building currently, are all the tests green or is something failing there? What's the latest version on PyPI and just sprinkle around some of these things that make the project sound and seem appealing, look appealing.

54:10 Michael Kennedy: Yeah that's all great advice. Anthony how about you?

54:13 Anthony Shaw: Yeah and if you don't know how to do some of those things, I really recommend using cookie cutter. There's some great Python templates out there that kind of give you things like test coverage or the badges, like a nice read me files and contribution templates and stuff like that. Yeah, I normally use those to boiler plate my project so at least for a new project, it looks like I've actually put time and effort into it. I think that's really important when people look at a project and they think when they want to contribute is they can see that you care about the project and the people who maintain it care about the project so they think that their contribution is actually going to be valued because if it's just a whole bunch of code that you just dumped online and stuck in GitHub then it's not as enticing because maybe it might get merged, maybe it won't, and everyone's pretty busy, so I think dressing the project up nicely and actually putting the time and investment in to write documentation, do proper test coverage, implement linter, stuff like that is really critical.

55:16 Michael Kennedy: That's a great recommendation with cookie cutter as well because that's like already prepackaged much of that stuff you got to do.

55:23 Anthony Shaw: Yeah definitely. It takes ages otherwise. I think the main thing for me is actually if you want people to contribute to your project, users bring contributions, so actually the question you should ask first is, does my project have any users and if the answer's no or not that many, then I would fix that first before you worry about why people aren't contributing to it, because if no one's ever used it before, people don't just contribute code to something they've never used or typically they don't anyway.

55:54 Michael Kennedy: It's mostly going to be, you're going to get some small subset of your users become contributors. If you have a very small number at the top of that funnel, it's going to be really small at the bottom.

56:04 Anthony Shaw: Yeah exactly unless it's been on Hacker News, in which case it's a different case then.

56:07 Dan Bader: Guys did we just scare everyone off? I feel like we had this long list of you got to do this and we got to do documentation and these badges. I just wanted to say, if your interested at all in open source, just put something on GitHub, anything, even if it's a script or something that you built or you think it adds value, please just do it because I think all of us, that's how we got started. We added and optimized this process over time and just get it out there.

56:36 Michael Kennedy: Yeah these are things you can add. These are things to enhance, not requirements to get started.

56:42 Anthony Shaw: Yeah definitely, in terms of getting users, if you publish your code to PyPI, if it's a package and if it's a web application or something then maybe you don't want to do that, but if it's a package you want to publish then there's actually a Google Big Query table where you can go and look at and analytics about your package, how many people have downloaded it, which versions they're using and some historic data from PyPI, so all the backend data they collect on pip downloads, you can actually go and query that which is really cool, so what I found with some of the projects I work on is focusing my efforts on projects that I know have a lot of users and then actually just trying to promote that better and make sure that it's really obviously welcome for contributors.

57:33 Michael Kennedy: Yeah that's definitely good advice. I don't remember who started this conversation and I'm not entirely sure we should go down there, but I will, Dan you said it, you should just throw your stuff on GitHub. What if I throw it on Bit Bucket or somewhere else? What if I run my own Git server and just throw it there or what if I liked SVN?

57:51 Dan Bader: Are you ever thinking about bringing some of these companies on as sponsors?

57:56 Michael Kennedy: Go ahead man, we're keeping it, the sponsors don't influence the content.

58:00 Dan Bader: No just kidding, it's a really valid question. It's one that I've also received in the past and there are different websites that kind of all have the same purpose, GitHub, Bit Bucket, Git Lab where you can host your code and work with other people collaboratively. I guess the question is what is the best one or where should you put your code? I think first of all it's great that we have that choice, if I have to make that choice right now, I'm heavily invested into GitHub just in terms of my code being there, so I'm going to stick with GitHub and it's probably what I would recommend to someone just starting out but the other ones are great too, in terms of the feature set, they're getting the job done, so theoretically you can go with whatever you like the best. I think GitHub will have an advantage in terms of that a lot of people are going to go to GitHub to search for stuff, I think that is probably the biggest difference there.

58:55 Michael Kennedy: Sure, Anthony what do you think?

58:56 Anthony Shaw: I think if you're working on a project in the open, an open source project, some of the code review features in both Bit Bucket and Git Lab are actually better than they have been in GitHub so there's definitely some feature differences between the different platforms but if you want to put a project out there and you just want it to be seen by as many people as possible and you want as many contributions as possible, I think you've really got to go with GitHub because that's where the vast majority of the users are. In the future, that might change, so it's important to make sure that the skills you are learning are portable across different platforms. For now, they've got most of the users, so it's just like social media tools. This is one of the reasons why some of them never took off, if none of your friends are on there and it's just you posting to no one.

59:43 Michael Kennedy: Posting to the database, it's not interesting. All right Ronald, what do you think, do you agree that GitHub is the place to start?

59:51 Ronald Maravanyika: Yeah, I definitely think GitHub is the place to start. Especially here, for me I knew GitHub through a Django goes workshop and usually a trip has been running all of Africa and people are getting news from GitHub. That I think is one of the most common project among my friends, so it's easy for you to get help if you get stuck. There are a lot of people that are there who are willing to support you. But if you have got a lot of comments and definitely to take time to learn. I have been using it for a while now, but that mean that we may discover new things.

01:00:43 Michael Kennedy: Yeah I'm still learning new stuff all the time.

01:00:45 Ronald Maravanyika: Yeah, so I think it's probably a good starting point and also you can go to it for a specific project.

01:00:56 Michael Kennedy: Sure, okay excellent, well I think we should probably leave it there guys, we're a little bit over time maybe, but I think we covered a lot of good stuff. Very, very quickly, I'm going to go around and ask you each two questions, but just super short answers. Favorite editor for writing Python code, Dan.

01:01:14 Dan Bader: Sublime Text, I think it's an awesome editor, super fast. Unfortunately not open source, but I love it. It's great.

01:01:21 Michael Kennedy: Awesome, Ronald.

01:01:22 Ronald Maravanyika: Yeah Sublime Text is good to me and also not the last for Python.

01:01:28 Michael Kennedy: For sure, Anthony?

01:01:30 Anthony Shaw: Yeah recent change but Visual Studio Code.

01:01:32 Michael Kennedy: Okay you were doing Komodo or something before right?

01:01:35 Anthony Shaw: Yeah I've been on Komodo for a long time. Yeah if anyone from Komodo wants to ask me why, then I'll happily give you a list of bugs that never got fixed, so yeah that move to VS Code.

01:01:46 Michael Kennedy: Yeah I use VS Code some as well. All right same rotation, PyPI package, just give me the name, Dan.

01:01:54 Dan Bader: BPython, it's an alternative Python REPL and it's just b, the letter b, plus Python and it's awesome, I love it.

01:02:01 Michael Kennedy: Awesome, I'm all about the PT Python. Ronald?

01:02:04 Ronald Maravanyika: I like the McMagic surplus of things so I'd say probably NumPy or something like that.

01:02:09 Michael Kennedy: Sure okay great, Anthony?

01:02:11 Anthony Shaw: Yeah not to be biased, but Apache Live Cloud, it's Apache Live Cloud which is a cloud abstraction API for Python.

01:02:20 Michael Kennedy: All right I hear they have some awesome contributors, that's cool. Dan do you want to give us the final call to action. If people want to get started, what do they do?

01:02:31 Dan Bader: For sure, if you want to get started, put something on GitHub or one of these other wonderful sites that we talked about and if you tweet your project at me, I'd be happy to share it on Twitter and help you promote it.

01:02:44 Michael Kennedy: Yeah for us as well, I'm happy to retweet an announcement of projects or something like that. All right just get out there, create a project, find something you care about and get started or if you're new to programming open source, go and find an existing project that you can contribute to. It'll be really rewarding. All right, Ronald, Anthony, Dan, thank you guys all for being on the show, it's been a lot of fun.

01:03:08 Dan Bader: Thanks guys.

01:03:09 Anthony Shaw: Thanks for having us, yeah, it was fun.

01:03:11 Ronald Maravanyika: Thank you so much.

01:03:12 Michael Kennedy: Yep you bet, bye. This has been another episode of Talk Python to Me. Our guests today have been Anthony Shaw, Dan Bater and Ronald Maravanyika and this episode has been brought to you by Linode and us, right here at Talk Python training. Linode is bulletproof hosting for whatever you're building with Python. Get your four months free at talkpython.fm/linode. Just use the code Python17. Are you or a colleague trying to learn Python? Have you tried books and videos that just left you bored by covering topics point by point? Check out my online course, Python Jumpstart by building 10 Apps at talkpython.fm/course to experience a more engaging way to learn Python. And if you're looking for something a little more advanced, try my Write Pythonic Code course at talkpython.fm/pythonic. Be sure to subscribe to the show. Open your favorite podcatcher and search for Python. We should be right at the top. You can also find the iTunes feed at /itunes, google play feed at /play and direct rss feed at /rss on talkpython.fm. This is your host, Michael Kennedy. Thanks so much for listening, I really appreciate it. Now get out there and write some Python code.