Are you new to open source? 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 Bader, and Ronald Maravanica. 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 at
mkennedy. Keep up with the show and listen to past episodes at talkpython.fm and follow the show on
Twitter via at Talk Python. This episode is 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 backstory
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 citywide 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,
know, he didn't set up for this. Like 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 backstory because we lose Ronald for a moment as he has to
work around to find this some way to be on the show. Dan, Anthony, Ronald, welcome to Talk Python.
Thanks. Thank you so much.
Hi, Mike.
Hey, everyone. It's great to have you here. It's going to be an adventure. We have, you know,
three of you on the call. So we'll try to do our best to not step on each other's 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, how do you find a project? How do you
just what are the steps of getting started at all? All right, when are you ready? Things like that. And 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 the roadmap for our project. But let's start with your story. Anthony, we'll go with you first. How do you get into programming in Python?
Yeah, programming was probably pretty early on. I think I was 13 when I started coding for the first time. Python was definitely a lot more recently. It's three years ago now. I think it was.
And I was actually working on an open source project called Lib Cloud. And I've been working on that ever since. And I wanted to make a contribution to the project, realized it was in a language that I didn't know how to write. So I 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.
That has taken it to a whole nother level. Like I want to contribute to this project. I don't know this technology.
I wouldn't I wouldn't I wouldn't generally recommend that path.
That's awesome. It works well for you. OK, Ronald, how about you?
Titan for me started is something which was very new. At that point, I was an intern and engineering intern at one of the international companies here called Unilever.
When I was there, there was a project of people having problems with capturing downtime and stuff like that.
So when I looked around, the only language that could fix that was Python.
And it meant that I had to be involved in programming.
So I looked around and then there was a scholarship where people were being taught Python for free by Equinite Wireless, which is a mobile company.
Yeah. And six months later, I joined in the program.
And that's how I started coding with Python since then.
Right now, I'm a bit mixing the two, the engineering aspect and the developer aspect.
But yeah, pretty much that's how I started with Python.
Oh, yeah, that sounds sounds really cool.
So doing networking type stuff, you're like, I got to talk to these devices.
Maybe something more than bash is required or something.
Cool. Dan, how about you?
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 the ski trip.
And obviously, we were all a bunch of nerds.
We didn't have any computers with us.
But one of my friends, he brought this tiny little book like Learn Python in 20 days or something.
Those ones that make all these promises that never really work out.
Learn Python on your ski vacation.
Yeah, exactly.
And I just, you know, I've been programming for a while.
And I just fell in love with this language.
And funny enough, you know, the same friend also later on introduced me to who is now my wife.
So, you know, this is quite the impact.
It was a heck of a trip.
Not on the same trip, though.
But, you know, Python and got married.
So, yeah.
Got a lot of mileage out of that.
Yeah, yeah.
That's very cool.
All right, guys.
So, let's start on the very beginning.
Just how do we get started contributing to open source?
So, 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 to the first one?
Yeah, yeah, sure.
So, I guess how many of you out there actually use open source software?
Well, everybody, I'd hope.
I mean, 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.
So, 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.
So, you know, 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.
It's an interesting thought that you really, you don't exactly owe it, but you almost do.
Like, you owe it to yourself to be a little more committed to the tools that run your life
as a developer, right?
Or someone in software.
Like, if you were 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, like, actually learn a little bit how it works and have a little
bit more control over it.
Yeah.
And if you use a project in particular to a sort of 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.
Yeah, for sure.
Ronald, how about you?
What do you think some of the benefits of getting involved in open source are?
Taking from, I would say, the African side of things.
Yeah, just so everyone knows, you're in Zimbabwe, right?
Yeah, I'm in Zimbabwe.
Okay, great.
So, I'd love to hear that perspective.
Yeah.
So, most of the software that we use on this side, they come from other countries like
India and the UK.
So, what happens is companies pay a lot of money to use those softwares every month.
And in here, we got experienced developers that can actually build those softwares.
But there's this notion here that foreign is always best.
So, to me, I got into open source trying to, like, show these guys that these softwares that
you're buying, we are contributing to those softwares.
So, that way, people can now try to look at you with the other eye that, wow, this guy
is actually serious.
Because the notion has been there for a long time that foreign is always best.
But I believe that software should be meant for Africans, by Africans, if you know what I
mean.
So, basically, at the African side, the Zimbabwean side, that's why people should contribute into
open source.
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.
And so, 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.
Like, because of the currency, this other software is extremely expensive.
And this is also a way to, like, empower people there to say, like, we are building this software
and if we need to or want to, we can fork it and make it our own, right?
Yeah, that's exactly it.
Get to that stage where we can build off software that can be, as Africans, build software that
can be used worldwide and people are comfortable with them.
So, there's a big push for tech startups in Africa.
How do you think open source is affecting that?
Do you think this is pretty much uniformly used within the tech startups around there and it
makes it more possible for that whole thing to work?
Okay.
So, here the situation is different because, like I said before, the economic situation here is very harsh
and people literally don't have time to do something that is not feeding their families, you know.
So, for someone to contribute into open source and they are not being paid for anything for it, to them it's like they'll be wasting time.
Of which, that's not the case.
So, for tech startups, I think open source is helpful to, like, getting the experience and trying to get that quality that will meet the global standards.
So, this is how open source now is affecting the tech startups.
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 project that things are moving forward.
Because when you are in open source, you definitely need a lot of help from a lot of people, right?
So, along the way, you get the experience and you get where you are messing things up, you know.
So, to me, I think that's how open source can contribute to tech startups.
Sure.
Okay.
Very cool.
Let's see.
Dan, I'll ask this question to you.
I think one of the biggest challenges for people getting started in programming, or maybe they've been programming for a while,
but in a more constrained environment, you know, standard corporate America, or something like this.
They don't necessarily feel like they're open source developers, right?
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?
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.
And, you know, either because they want to give back to society or because they just want to work on something cool.
And, well, I guess the idea of this imposter syndrome, or what imposter syndrome is, is that, well, like you said, you don't feel worthy.
And you're scared to put yourself out there.
And this is exactly how I felt when I published my first open source project, you know, that I started and pushed it to GitHub and then actually posted the link to Reddit and Hacker News.
And I was just sitting there, you know, I remember going to bed because I was in a different time zone.
I remember going to bed and just like almost like lying there and shaking and like just in anticipation what would happen, you know.
And I got up the next morning, checked my email.
And it was almost like, you know, at the time I perceived it as my worst case scenario.
You know, I had some like really experienced people shoot me down.
And someone said, you know, this should have never been written.
And like, who would use something like that?
And I was like, oh, my God, like, sorry, guys.
Like, what did I do here?
And, you know, now looking back, I obviously have a way different experience or like a way different perspective.
And I'm glad that I went through this.
But, you know, the struggle is real.
Like, absolutely.
Yeah.
Well, 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, you know, something really big and mature that there's no like low hanging fruit left.
It is like all hard work.
And like every little change has to be considered over all these use cases.
And so 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.
Yeah.
No, I totally agree.
I mean, what we're seeing there is like the equivalent of, you know, Elon Musk building his rocket ship.
Or, you know, like we're seeing like the super fancy like cruise ship or the latest like BMW car and whatnot.
And of course, like you can't compete with that because that stuff, you know, the Linux kernel was built on probably like millions of hours of work by hundreds of thousands of different people.
It's highly polished.
Yeah.
And it's highly polished, you know, and it's the barrier to entry there is so high.
But really what you should be aiming for is like the equivalent of building your own bicycle.
Right.
And then riding that around town.
And like maybe you get like one or two other people are like, oh, yeah, that's a nice bike.
Can I ride that?
That's a good point.
Oh, I saw your bike had a flat.
So I fixed its flat tire.
Yeah.
Awesome.
Yeah.
So I'll put in the show notes something by Adriana Friend.
She put a has a 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.
And we're going to switch to that just a second.
But Anthony, let me ask you, what do you do you think you need to know Git or like how you talked about learning technology?
Like maybe you have to learn how to do Git.
Maybe you have to learn Git flow.
You have to learn what GitHub is like.
How do you get started in all that?
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 workflow to create an account on GitHub, for example, how to raise a pull request and kind of some of the basics, 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.
So 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 kind of learned that, then, yeah, pick something simple.
And the other thing I recommend people do is create a sandbox project first.
So once you've created a GitHub account, then just create a project that's got nothing useful in it.
You know, just add some files, make some changes, do some commits and use it kind of like 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 your life.
Yeah.
Or make that part of your contribution, which then you have two different things you're trying to learn at the same time.
Yeah.
And there's a bunch of nice GUIs as well.
Like, it doesn't have to be all CLI, command line driven stuff.
It could be, you know, source tree or the GitHub tools or things like that.
So that's nice.
Yeah.
There's maybe one great tool to throw in the mixture.
It's called GitUp.
GitUp.
Personally, I feel like it doesn't get the recognition at this source.
I think it's a great UI.
It's a free open source tool.
I think it's available for Windows and Mac.
Maybe just Mac.
But still a great tool.
Yeah.
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?
Okay.
So one of the people that really encouraged me to get into open source is Mike Place.
He works for SoftTech.
And SoftTech, their business model is around open source software.
So when he came here for our mentorship week, December 5th, 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.
And these were like huge companies, you know, 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 continent, going to other continents.
Personal life, 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 still do your project.
And most of the time, the job you get, it will be a remote job.
You don't require to relocate or stuff like that.
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.
Yeah.
Yeah, definitely.
So to me, it's about getting the experience and also trying to get noticed out there.
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 bookstore and check out Linode at talkpython.fm/Linode, L-I-N-O-D-E.
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 gigabit 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?
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.
And 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.
I mean, I'm sure you're always going to have the top 1% of people.
If Linus Torwells is looking for a new job, well, I'm sure he's not going to have to look
for a long time.
But the average person...
Yeah, I think it's similar.
If you create something major like Django, Flask, or I mean, if there are like SQLAlchemy,
for example, like Michael Bay, Bayer doesn't probably need to go and look for a job if
he doesn't want to, right?
You could lever those types of things.
But, you know, fixing, adding a minor feature to even a popular project is not enough alone,
probably, right?
But it's one of the building blocks, maybe.
Yeah, exactly.
Like, it's not going to be enough alone, but it's still going to be helpful.
And it's going to be...
It's more of a long-term play, I think.
You know, I get...
Almost every week, I get a question of like, okay, how can I get more stars or likes on
my GitHub project?
And how can I do...
Like, 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, you know, what's probably vastly going to increase your chances is just to apply to
like five jobs every day.
You know, like, I would rather spend my time with like almost this prospecting work and reaching
out to people and building relationships and meeting people for coffee.
rather than thinking like, oh, how can I get 50 more likes on my open source project?
But I can totally see where that motivation comes from, right?
Because I feel like when you're from the outside looking in, it can seem like, oh, you know,
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.
Sure.
Like social proof.
Like, I applied to a job.
And when they go to look at my resume and think about what I've done, like, here is proof that
I actually have done the things I said I've done.
You can check out the quality and so on.
Yeah.
And it can also backfire, right?
Like, if you, you know, 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, right?
And so, yeah.
So you've got to balance it with that.
But in general, I would say, yeah, it's, you know, it's great work.
It's very rewarding.
And it can help you find the job of your dreams for sure.
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.
So, Anthony, you are in a place where you maybe review some resumes and think about giving
people jobs.
What do you think about this kind of briefly?
Yeah, I've probably interviewed about 300 developers in my lifetime.
Yeah, 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 styles and stuff like that.
But that's not a requirement.
I mean, that will come up in developer interviews anyway.
We'll talk about, you know, 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.
Yeah.
So if someone really cares about, I mean, 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.
Right.
So I think that's more about what it's about for me.
Yeah.
And it's like a signal that this person is something of a self-starter, 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.
Yeah.
Sure.
So I found this one.
Yeah.
This is a part of First Timers website.
So 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 yeah, we had a look.
Mike, yours was in C#.
It was.
Yeah.
Something with MongoDB.
Yeah.
MongoDB link queries.
Dan, I was pretty impressed.
Yours was Python 3 support for a project called PipRot.
And yeah, mine was the learning Python over a long weekend contribution.
Yeah, that's really cool.
And yeah, you can actually, you put in a name there and then there's a link to say,
show me every pull request that this person has ever made in GitHub, which is a pretty
good research if you're looking to work with someone.
Yeah, definitely.
Yeah.
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 a lot more than that.
For sure.
All right.
So that's a ton of information on like 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 like packages.
Like so at PyPI, 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, you know, how do I go to find something like that would be good for me if I was looking
for this, especially if I was somewhat new.
Yeah.
That's a huge problem, right?
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?
It's not too tall and too hard, but it's also not like a weed.
You want to make your bed out of or whatever.
And because it's a big liability issue as well, right?
If you pick the wrong project there, potentially if you're working for a company and that becomes
part of the code base you're working on, you may have to support this for several years in
the worst case.
So, yeah.
So I've just, you know, just been thinking about the process that I used, that I used,
that I evolved over time, how to go from, you know, I have a need for like some problem
that I'm facing.
Let's say I'm working on, you know, a Django app and I want to add, you know, some special
form validation or whatever.
How do I go from having identified this problem to actually finding a good package that I could
pull in and it would solve my problem?
I don't have to write it myself.
I don't have to reinvent the wheel.
And I think it comes down, you know, from a high level perspective, it comes down to coming
up with a pool of candidates there, like candidate packages that sort of kind of do what would
help you, what you're looking for.
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.
Like, so 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.
Yeah, absolutely.
I think it's not, like open source isn't a silver bullet, right?
Where you can just go in and it's like going to a candy store and like whatever you get
there will be great for you.
I mean, it's, well, not even in a candy store.
It's like that, right?
It feels great.
But then, you know, a day later, you're going to pay the price for that.
Oh my God, all these horrible analogies.
But yeah, no, it really, I think it really, it really comes down, like 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.
Yeah, for sure.
Okay.
So you talked about checking the package popularity as one of the things.
Yeah.
And I think it all comes, for me, all comes down to these, having these heuristics because
there's so many packages there.
You 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, to go through a curated list.
For example, there's awesome, awesome Python at awesome-python.com.
Yeah.
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, right?
So you got to do some legwork 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.
Yep, absolutely.
I think the project homepage and the readme, those kind of play similar roles.
Those give big indicators of does the person who created this project really care about it?
So is it worth my time to contribute?
You only want to contribute to a project where the maintainer actually cares about the thing.
Yeah.
Or where you're confident actually becoming the maintainer yourself, right?
Yeah.
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 you have, it's almost like you're pulling in this binary blob that no one really
understands, right?
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.
So I think it's always, it's all about these trade-offs and really scrutinizing what you're
bringing in into your system there.
Sure.
Absolutely.
Ronald, what do you use as a way to find projects that you can contribute to?
It was really hard to get into open source.
I asked around on social media because I just wanted to get involved in open source.
Most people recommended OpenShift as one of the projects.
So I went there and to be honest with you, I understood nothing about everything.
Yeah, that's a big project, right?
Yeah.
And people were saying this is the easiest project to start on and stuff like that.
So I backed up a little bit and tried to start with local projects.
So for example, I started with contributing for the Taikon Zimbabwe website and the Thai ladies
website, stuff like that, the symbol stuff.
Yeah.
So that makes a lot of sense to start there.
Yeah.
So still now I'm trying to get into bigger projects, but the choices like how to choose
the best project, which is too young, which is not too deep.
It's a little bit hard.
It's still very hard for me to find out that.
Yeah.
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 just that text, like 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 thought that's, 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 PRs, like a first pass
to see if they make sense, things like that, right?
Yeah, yeah, sure.
So I think the kind of case that you're talking about is quite typical.
It's the sort of Goldilocks and the GitHub projects.
Like you're trying to find one that's not too big and too complicated, that's not too small
and doesn't get maintained and maybe find something in the middle.
And I think people have this expectation that their first open source contribution would be
like this killer PR where they like, you know, improve.
Oh, I fixed this bug or, you know, I've added 20% performance improvement.
And it's, 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 it's contributions to an open source project and not just about code.
So this is simple stuff like code reviews.
Like you don't have to be a maintainer of the project to do code reviews.
So if you see a fairly popular open source project and, you know, you're pretty good at
reviewing, reviewing other people's code, maybe you do that as part of your job, then
there's nothing stopping you going in someone else's project and doing code reviews.
Obviously you have to understand their style guidelines, you know, what the rules are for
that particular project and what their preference is.
But, you know, code reviews, I'd love more people to, to do code reviews on projects that
I work on.
Documentation is also a really popular one.
So quite recently I contributed some to the Beware project.
Russell Keith McGee, he's been a guest in a past episode.
Yeah.
And he's very welcoming.
That project is very welcoming to newcomers as well, by the way.
Yeah, definitely.
And 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 kind of the gap that I saw
at the time was that, you know, 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 that 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.
So 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 know, 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.
So, yeah, documentation and the tests are really great.
And also contributions, more softer contributions.
So this could just be presenting at your local Python meetup about a project.
This could be, you know, blogging about it, tweeting about it, sharing it on social media,
like as well as a maintainer of projects.
Like 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.
And sometimes that's actually most of the work.
This portion of Talk Python 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've built a course to teach you Python the way professional
developers learn by building applications.
Check out my Python jumpstart 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 McKay and I 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.
And 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 the 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 PRs
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?
I don't know.
How do you feel about that?
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.
So that's actually kind of 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.
Now you can see how they've gone the same way in OSS.
Yeah, it's pretty interesting.
It's kind of like the nuclear option, but sometimes it has to be done if it really is abandoned.
Yeah, give them a chance, give them an opportunity.
But if you're still using 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.
Yeah.
Ronald, what advice do you have for like, are there things that you do that you found that
like 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?
One of the things that I do is I don't want people to suspect what my PR will solve.
So 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.
It's actually a very easy way for dealing with small projects.
When they get to bigger projects, maintainers may not read those comments, you know.
So it just depends with the type of project that you're involved in.
Yeah.
I guess having a really clear, well thought out, well structured message or comment associated
with the PR or the issue or whatever, it makes it seem like you're serious and it makes it
easier to understand what's going on.
Like some people just throw out like a sentence or some like very small thing and, you know,
how serious do you want to take that work, right?
Yeah.
That's it.
Sure.
Dan, how about you?
When you're evaluating a PR or issues or things like that, what do you look for?
I think for me, you know, when I became a maintainer of an open source project and I started getting
PRs, for me, the key realization was at some point, hey, this is really more, this is a social
project and not so much, not only a technical project, you know, where we're just looking for
technical solutions for things.
And I think it is really important, like 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, you know, being friendly,
like introduce yourself and just say hi.
And instead of, you know, maybe just instead of throwing a bunch of code over the wall,
actually try and understand to see where, which direction this project is going.
Right.
That's a good point.
We talked about before we hit record, like how we've all submitted PRs and actually we had
solved a problem, but it was actually taking the project in a direction that wasn't part
of the roadmap.
They weren't interested in going that way.
And so we did all this work and threw it at them and they're like, you know, this is really
cool, but it's, we're not going to take it because it's just not where we're trying to
go with this.
Right.
Yeah.
And it feels bad on both, both sides.
Right.
Like as a contributor, it feels not that great if you're putting in all that work and you feel
rejected.
And as a maintainer, you feel horrible because you have to reject someone's potentially very
good work.
You know, we can see they invested a lot of time into this, but it just takes the project
into a different direction.
And 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, like just,
you know, 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 like some time on rebuilding this thing.
And I feel like that's harder to do than just being very careful about what contributions you
take on in which direction you grow the project.
Sure.
How do you feel about things like continuous integration, you know, Travis CI and that
kind of stuff that sort of evaluates from a correctness standard, the PRs initially?
Yeah.
Oh, it's great that you're bringing that up.
I think it's these days it's table stakes for any open source project, right?
It's so easy to set that up.
If you just have a circle CI or Travis CI, they all have free plans for open source projects.
So they're like free build server farms where you can build your project and then you get,
you know, you get a notification via email and a comment on your pull requests.
And you can set it up so that it runs a PEP 8 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.
You know, we're not following the code style here.
Like it just reduces the code review time.
I think any open source project should take advantage of that, that kind of technology.
Yeah, I totally agree.
I think one of the interesting things is you mentioned this is a social experience.
There were some studies done that said people are less frustrated by getting this nitpicky
feedback from a machine rather than from another person.
So let it, let it say, no, your indentation is wrong.
No, this doesn't have a doc string.
Whatever, as like before the thing is accepted, just like I'll, I'll review it once you pass
the continuous integration.
Right.
That's really nice.
Yeah.
And then I'm a very nitpicky code reviewer.
And, you know, when I, when I became a team lead, like one of the things that I realized
very quickly is that you got to absolutely pick your battles, right?
Because you're just going to be upsetting people.
Yeah.
So having a linter in place on your CI infrastructure, continuous integration infrastructure, it should
take, it just takes away some of those, those discussions.
Yeah.
Everybody got to make the test green.
It's not my fault.
The machine says.
I can't, sorry.
I can't do that, Dave.
That's right.
Sorry, Dave.
Anthony, you know, another thing that's worth talking about when we're talking about running
a project is, is burnout.
So it's one thing to, you know, I talked about the, like the unanswered PRs, the unanswered
issues and stuff.
But the other, the dark side of that, if you will, is people expect that you maintain your
projects at like often really unreasonable levels, right?
Like you have this project.
I filed a PR.
Why isn't it here yet?
You know, and people have jobs, they have lives, they're busy.
There's burnout as a real issue here as well.
Right.
Hmm.
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, is pretty high.
And sometimes a little bit unreasonable.
I mean, as part of my day job, I think I manage 26 people.
You know, I've got a lot of things to do during the day.
I've also got three children, you know, so I've got a family and a house to also maintain.
These things kind of 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, you know, I've got other things to
focus on.
I think I'd found in the past, especially focusing on really unhealthy things like your GitHub
contribution graph, like how many recurring days you've done was 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.
Like 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, you know, I'm spending
time with my kids and actually trying to get that separation.
Otherwise, people kind of feel obliged to constantly, you know, almost be on call for a project and
remembering that, you know, this is your time, this is your contribution and there's no
obligation and actually try and invest some of that time into getting other people to
help out and getting other people to contribute.
Because, you know, if you advertise a project more, if you try and delegate work better, then
those kind of skills that you'll learn from open source will absolutely help you in your
day-to-day job.
Like that's a really typical problem that developers have, I think, because they kind of work their
way up the ranks is that they, you know, 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, you know, that's a really, 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?
Yeah, that's a really good point.
So 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?
Like how do you, how do you attract people to it?
Because then you'll get help, right?
You'll get people to come along and help with the code review, help adding new features, help
write the documentation and so on.
So, Ronald, let's start with you.
What are some of the things you think people running projects can do to make their project
attractive to folks like you who want to contribute to open source?
Okay.
So the first thing, it's little, but it's a big deal.
The first thing for PRI did, it was accepted.
But then I was new to open source, so I was not sure, was it accepted?
Was it rejected?
I wasn't sure where it was because I was trying to learn Git at the same time trying
to contribute.
So that small message just to say thank you or that small comment to say your code is okay
but you have to fix your hand.
It's really important.
And that's one of the things that can attract people to your project because most of these
projects, you get into them through referrals.
Right?
So if I enjoy the way I'm working with you on a project, definitely I'm going to reference
the next person who's close.
So I have this notion that the coding part of things is easy.
But the project framework is the most hard part.
So when you're trying to start your open source project, make sure there is a story behind
your project.
Like tell us your situation.
Because countries are different.
Cultures are different.
Right?
So try to explain your issue, what you're trying to solve.
Then make clear frameworks of what you want things to be done.
Right?
And then from there, people can get there and they don't have to ask questions.
Because when someone is getting into a new project, they are afraid of being embarrassed.
So they don't want to ask questions.
So try as much as possible to make sure that people don't ask questions, to make sure that
people that want to contribute feel appreciated.
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 is no message for that thing.
Something that's just sad.
So firstly, for me, firstly, is that little message.
Just communicate with your contributors, whether you accept or you don't accept their PRs.
Yeah, I think this is important because, like I said, having the unaddressed issues, the empty PRs, 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.
Yeah, that's absolutely right.
And then ensure that the frameworks are okay.
Maybe it's just me, but to me, putting up those frameworks is the hard part.
Right?
So the coding part of it is really simple.
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 background information 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.
Yeah, awesome.
Certainly having that disclaimer I talked about before to say you're welcome or like the things like the Beware 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?
So I think there are definitely some very actionable tactics that your listeners could apply.
So I'm just going to throw out some of them.
And this is not going to be, you know, this is going to not not going to solve everything and just make your project super popular.
But I think it definitely helps.
And so a couple of things you can do there is just having a really clear one sentence description of what your project is for, you know, what it what it does and for who.
Like what's the benefit to your user?
And you can actually put that on GitHub.
You can put it in the they have like a I guess like a tagline or subheading setting all the way up there or put it like right on the readme.
And I found that a lot of times that is missing.
And sometimes, you know, I find something that I feel like this seems like it sort of relates what I'm trying to do.
But what does it actually do?
And I think that is really important.
Just being very clear about it.
And then maybe you 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 with your continuous integration setup.
So, you know, you can show people what your test coverage is like, how the latest how is master building currently?
You know, is it are all the test screen?
Is there or is something failing there?
What's the latest version on PyPI?
And just sprinkle around some of these things that that make the project sound and seem appealing, look appealing.
Yeah, that's all great advice.
Anthony, how about you?
Yeah.
And if you don't know how to do some of those things, I really recommend using cookie cutter.
And there's some great Python templates out there that kind of give you things like test coverage or the badges, like a nice readme file, some contribution templates and stuff like that.
So, yeah, I normally use those as like to boilerplate 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 where they want to contribute.
It's 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, you know, it's not as enticing because maybe it might get merged, maybe it won't.
And everyone's pretty busy.
So I think it's, yeah, dressing the project up nicely and actually putting the time and investment into right documentation,
do proper test coverage, implement linters, stuff like that is really critical.
That's a great recommendation with cookie cutter as well, because that's like it's already prepackaged the all that stuff.
You got much of that stuff you got to do.
Yeah, definitely.
It takes takes ages otherwise.
And but the thing I think the main thing for me is actually if you want people to contribute to your project,
you users bring contributions.
So it's actually the question you should ask first is, does my project have any users?
And if the answer is no or not that many, then I would fix that first before you worry about why people aren't contributing to it.
Because, you know, if no one's ever used it before, people don't just contribute code to something they've never used that typically they don't anyway.
It's mostly going to be you're going to get some small subset of your users become contributors.
Right.
And so if you have a very small number at the top of that funnel, it's going to be really small at the bottom.
Yeah, exactly.
Unless it's been on Hacker News, in which case it's a different case.
So, guys, did we just scare everyone off?
I feel like we had this long list of like, oh, you got to do this and we got to do documentation and these badges.
And I just wanted to say, you know, if you're interested at all in open source, just put something on GitHub.
Anything.
Even if it's like a script or something that you built where you think it adds value, please just do it.
Because I think all of us, that's how we got started, right?
Like we added and optimized this process over time and, you know, just get it out there.
These are things you can add.
These are things to enhance, not requirements to get started, right?
Yeah.
Yeah, definitely.
So, yeah, in terms of getting users, I think it's – so if you've published your code to PyPI, if it's a package, I mean, if it's a web application or something, then maybe you don't want to do that.
But, yeah, if it's a package you want to publish, then there's actually a Google BigQuery table where you can go and look at like analytics about your package, how many people have downloaded it, which versions they're using, and some like historic data from PyPI.
So, like all the – I guess all the sort of back-end data they collect on pip downloads, you can actually go and query that, which is really cool.
So, yeah, 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 them a bit better and make sure that it's really obviously welcome for contributors.
Yeah, that's definitely good advice.
So, 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 Bitbucket or somewhere else?
What if I run my own Git server and I just throw it there?
Or what if I like SVN?
Are you ever thinking about bringing some of these companies on as sponsors?
Go ahead, man.
We're keeping it.
The sponsors don't influence the content.
No, just kidding.
It's a really valid question, right?
It's one that I've also received in the past.
And there are different websites that kind of all follow the same, have the same purpose, like GitHub, Bitbucket, GitLab, where you can host your code and work with other people collaboratively, right?
And I guess the question is, like, 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.
And 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.
I mean, in terms of the feature set, they're getting the job done.
You know, 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 just go to GitHub and search for stuff.
I think that is probably the biggest difference there.
Sure.
Anthony, what do you think?
Yeah, I think if you're working on a project in the open, so an open source project, some of the code review features in both Bitbucket and GitLab are actually better than they have been at 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.
You know, and so it's important to make sure the skills that you're learning are portable, I guess, across different platforms.
But for now, yeah, they've got most of the users.
So it's just like social media tools.
You know, this is, I guess, one of the reasons why some of them never took off.
You know, if none of your friends are on there, then it's just you posting to them.
You're posting to the database and it's not interesting.
All right, Ronald, what do you think?
You agree with this GitHub as a place to start?
Yeah, I definitely think GitHub is a place to start.
And especially here, for me, I knew GitHub through a Jungle Goals workshop.
And these workshops have been running all of Africa and people are getting reach to GitHub.
The other thing is that it's one of the most common personal tools.
So it's easier for you to get help if you get stuck because there are a lot of people that are there who are willing to support you.
But it has got a lot of commands and definitely to take time to learn.
I've been using it for a while now, but I mean, again, I discover new things.
Yeah, I'm still learning new stuff all the time.
Yeah, yeah, yeah.
So I think it's probably a good starting point.
And also, you can go through it for the bigger project.
For 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.
So 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?
Sublime Text.
I think it's an awesome editor, super fast.
Unfortunately, not open source, but I love it.
Awesome.
It's great.
Yep.
Ronald?
Yeah.
Sublime Text is good to me, and also not paid plus plus.
It's also fine.
For sure.
Okay.
Anthony?
Yeah, recent change, but Visual Studio Code.
Okay.
You were doing Komodo or something before, right?
Yeah, 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, move to VS Code.
Yeah, yeah.
I use VS Code some as well.
Cool.
All right.
Same rotation, PyPI package.
Just give me the name, Dan.
BPython.
It's an alternative Python REPL, and it's just B, the letter B, plus Python.
And it's awesome.
I love it.
Awesome.
I'm all about the PT Python.
Ronald?
I like the mathematics part of things, so I'm saying probably NumPy or something like that.
Sure.
Okay, great.
Anthony?
Yeah, I'd have to be biased, but Apache Lib Cloud.
So it's Apache Huff and Lib Cloud.
Cloud, which is a cloud abstraction API for Python.
All right.
I hear they have some awesome contributors.
That's cool.
All right.
Dan, do you want to give us the final call to action?
People want to get started?
What do they do?
For sure.
Okay, so if you want to get started, just 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.
Yeah, for us as well.
I'm happy to retweet an announcement of projects or something like that.
Yeah.
All right.
So 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.
Thanks, guys.
Thanks for having us.
Yeah, it was fun.
Thank you so much for having us.
Yep.
You bet.
Bye.
This has been another episode of Talk Python to Me.
Our guests today have been Anthony Shaw, Dan Bader, and Ronald Maravagnica.
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?
Well, check out my online course, Python Jumpstart by Building 10 Apps at talkpython.fm slash
course to experience a more engaging way to learn Python.
And if you're looking for something a little more advanced, try my WritePythonic 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.
Bye.
I'll see you next time.