The Open Source Community: Getting Contributors

[00:00:00]
>> [MUSIC]

[00:00:03]
>> Speaker 1: So getting contributors, because you can't do it on your own, this is your contributor pipe line. This comes from a block post called healthy open source fantastic blog post by Michael Richards, or Rogers, of the node foundation, and they are phenomenal at managing an open search community.

[00:00:23]
It's really amazing what they've been able to accomplish with such a huge community. So your pipeline goes like this, this white space out here is everybody in the world, and a very, very small section of the world are your users, and a smaller section of those users become contributors.

[00:00:40]
Contributors are people who like write blog posts, and they contribute documentation, and they record screen casts, whatever, and then some of those people are actually committers to the project, so they have committed code, and then a small portion of those people are in the technical committee, the ones who make decisions, the ones who have the power to do releases.

[00:01:02]
So the one thing that might be a little counterintuitive to you, and I'm actually jumping ahead here. You might be thinking, okay, so the commiters are the one who made pull requests, and that's great. No, commiters are the ones who have made pull requests and have commit access to the repository.

[00:01:18]
So it might surprise you to know that, actually I'm not even sure how many people, or how to find out how many people have commit access to the repo. But there are probably hundreds of people who have commit access to the node repo, and they don't have release access necessarily, but they can commit directly to the repo.

[00:01:40]
And that has served them very well, because as soon as somebody lands a nontrivial change, it's like this isn't a documentation change, but this is actually core stuff, then they say, awesome. Thank you for contributing, you have commit access now, and that puts the onus on that contributor, like whoa, and they step back and think about it for a second like, this is a big deal, I have commit access to node.

[00:02:04]
I feel ownership over this project now, and that's a really great way to build a community. And so there are things that you can do to protect things, obviously. We've just automated releases by merging in a master that automates releases. So there are ways you can protect the master branch so that not just anybody can actually release anything, but by giving these people commit access it gives them a lot more feeling of ownership, so I think that is a really important part.

[00:02:34]
We talked about CONTRIBUTING.md. I need to delete that slide. That's kind of a silly slide. And we talked about not doing everything yourself. So supporting AMPAP, I made this up, as many platforms as possible. So even though many of us use Mac we should support Windows also. This is an important part of being an open and friendly community so that we can have contributors from all platforms.

[00:03:01]
So that is important. Don't commit generated files, they're really confusing. I'm not gonna cover this, you can go to kcd,im/generated to find out why we are excluding the disk directory, but, yes, it really hinders people contributing to your project. Newbies are a really, really great pipeline into contributing to your project.

[00:03:26]
They're really excited about life and about developing, and so having issues like help wanted, and good for beginners, or first-timers-only is really valuable. This first-timers-only thing is something that I started like a year and a half ago where I reserve issues for first-timers. So if you're not a first-timer, I won't accept your poll request.

[00:03:45]
First-timers are those who've never contributed to open source before. It takes a lot of work to prepare issues for first-timers, and so I don't do it like all the time, but it's really valuable and people get really involved and excited about your project when, like this is the first project I ever contributed to.

[00:04:03]
It's really exciting. Cool, then this is all contributors. At the bottom of the repo, of the readme, you can see this table of people who have contributed to the project, and this is totally automatic, and generated, and stuff. Well, it's generated based off of JSON, but there's a CLI to generate that JSON.

[00:04:29]
But by doing this, you're putting your face on people, people's face on your library's documentation page, or some prevalent place in your library. They feel like, wow. Okay, not only do I have commit access to this thing now, but I also, my face is on this. There's some warm and fuzzy feelings that are associated with this, and actually, Wikipedia did a study in Germany about retaining contributors to Wikpedia.

[00:05:00]
Wikpedia and open source have kind of an, some interesting relationship where we're both highly motivated to get new contributors to stay, we're not paying anybody to do so, and we're doing this at a huge scale. So how do we manage this? So what Wikipedia did was they took, I think they had 1,400 new contributors every month, and this is just in Germany, and they took, they whittled that down to 300 people, and they had the control group and the variable group, and with the variable group they gave them a special award saying, thank you to your first ever contribution.

[00:05:40]
They put it on their profile page, it's like this person contributed, and they also had a special blog post where they list out the people who contributed and thanked them, and they found that that group that they gave those special rewards to were 20% more likely to continue contributing over the next year then the other people in the other group, and they did this 11 times, for 11 months, and they found 20% more likely.

[00:06:06]
So I feel like this is very much the same idea. By giving people some special recognition for contributing, even non-code contributions. So GitHub is pretty good at saying hey, these people contributed, you can see, but contributions are more than just code. Not everybody is good at contributing code.

[00:06:24]
Some people, or as good at contributing code, some people feel uncomfortable about that. Some people are really good at contributing documentation, or answering questions on stack overflow or in the chat, and so recognizing those people I think is really important for building a good community around projects. I've actually, after having done some of these things that I'm telling you about, I'm been able to hand off projects that I still cared about, but didn't have time to maintain, and so now I'm still benefiting from those projects, but I don't have to maintain them.

[00:06:54]
That's pretty awesome. I like not having to work. Then MAINTAINING.md is a good file that you can add to talk about. Okay, here's how our infrastructure works. We're using semantic relays to do this and whatever else is important for people who are helping you maintain the project, and then I already talked about giving commit access freely and early, it's good, it's a good thing.

[00:07:19]
So here are a couple of resources, you could find those later, and yeah, that's pretty much it on my talk on community.