04 May 2011
Not a post per se, but I thought I’d collect my notes from Greg’s video here for my purposes. Excellent advice throughout if you care about OSS at all. (You should still watch the video.)
The desire to get a sticker that says “you’re ready” is social conditioning that is incompatible with the diversity of work needed in open source. Being ready is just a commitment to help and a project compatible with any of your skills.
“The skills you’d need to help this project” and “ticket difficulty” would be good clarifications for maintainers. Also, “Newbie friendly” projects should clearly say that they offer more support.
It’d be nice to have a place where projects were centralized and organized by topic advertised for contribution
Not knowing where to start is OK, you just have to be able to deal with running down a couple of blind alleys first.
Failing at pull requests is winning at learning the project.
Bugmashes are a great way to dip your toe in the water and it means you’ve got a built-in invite.
Contribution guidelines may not be how you’d work in isolation, but are typically critical for the long-term viability of a project. Your patch is a one-time commitment for you, but the maintainer has to live with it forever. Keep that in mind.
Guidelines should be stated up front. For non-conforming contributions, maintainers could apply fixes for that first time, and provide feedback for future contributions.
Maintainers are as busy as busier than you are. Fixing & integrating your patches can take longer than doing the work themselves.
Not every maintainer is interested in contribution, and those who aren’t should probably put up “noobs keep off the grass” signs.
“Open source is for people who are better at this than me” is flat-out false.
Finding a bug (either organically or via a tracker) and writing a failing test case is a great way in. From there, trying to actually fix the problem is a great way to learn a codebase.
It’s a bit unfair to expect maintainers to be community-builders as well as hackers.
You shouldn’t expect immediate praise for a patch you submit, as it takes time to review and safely accept a patch. When not accepting a patch, a maintainer doesn’t always take the time to explain why they didn’t accept it.
Maintainers need to remove as many hoops as possible or risk losing many, many good contributors.
If you need a hand to hold, that’s OK, go find someone outside the project (like a coworker, user group, pair programmer, or hackfest)
If hacking takes you too long, you may have picked too large a problem. Try thinking smaller and solving an easier problem.
“The idea that you’re supposed to learn this stuff on your own is patently false.”
The idea of trying to privately study until you’ve arrived as an open-source coder is a recipe for failure.
If you just want to contribute, shop around a bit for a good fit for you, i.e. high level of developer support.
Expecting a vibrant, barn-raising community or a shark tank is drawing too sweeping a conclusion. It’s an ecosystem made up of smaller cultures. This means you need to find someone to help you find the subculture that fits you, and then work toward making the whole ecosystem better.
You probably have more resources at your disposal than you know… In my case, I could have used community resources already at my disposal rather than writing a frustrated 2 AM blog post.