4 ms·

How to Contribute to Open Source without Being a Programming Rock Star

121 points by Baustin 14y ago

Baustin 14y ago
I love seeing the great discussion that this started (both positive and negative feedback). Thanks everyone for turning the post itself into an open source project.
8ig8 14y ago
Just a reminder: > If the original title begins with a number or number + gratuitous adjective, we'd appreciate it if you'd crop it. E.g. translate "10 Ways To Do X" to "How To Do X," and "14 Amazing Ys" to "Ys." Exception: when the number is meaningful, e.g. "The 5 Platonic Solids." http://ycombinator.com/newsguidelines.html http://ycombinator.com/newsguidelines.html
- Baustin 14y ago
  Sorry about that, folks. I'll keep that in mind for all future posts.
- sublimit 14y ago
  That seems awfully pedantic and useless as an official guideline. I mean, it's the same article nonetheless.
freework 14y ago
One thing I've learned about contributing to open source is that it's primarily a social achievement. If I see a developer who has contributed to many oss projects, I don't think "wow this guy must be a great programmer", I think "this guy must have great communication/people skills". Often (especially with popular oss projects such as apache, python, firefox), you can fix a bug, add it to the ticket tracker, and it'll just sit there and rot. Every day people fix bugs and upload patches. You have to contact someone and sweet talk them into merging your fix.
- kyle_t 14y ago
  You make a good point. For those just getting their feet wet with Open Source projects it makes sense to start first with a smaller yet active project.
reginaldo 14y ago
In the same area, OpenHatch[1] seems very nice. From their own landing page: OpenHatch is a non-profit dedicated to matching prospective free software contributors with communities, tools, and education. [1] http://www.openhatch.org http://www.openhatch.org
IridescentBlue 14y ago
How about contributing to Open Source by helping write the documentation for projects? Properly documented projects go a long way in helping developers get recognition and notice. I, myself, have begun more thoroughly documenting projects, not only for my sake but for everyone else that comes along. I find that this book helped me get up to speed quickly: http://www.amazon.com/The-Elements-Style-4th-Edition/dp/0205313426/?_encoding=UTF8&keywords=Elements%20of%20style&tag=produc05-20&linkCode=ur2&qid=1356985769&camp=1789&sr=8-1&creative=9325 http://www.amazon.com/The-Elements-Style-4th-Edition/dp/0205...
bilalq 14y ago
Thanks for this. When I was first getting into programming, people would tell me and others like myself to "go contribute to open source projects". I don't think they realized just how daunting and impossible that seemed to us at the time. To be honest, none of us even knew where to begin.
- sublimit 14y ago
  Well, many of us still don't. I don't think I have the necessary teamwork skills. I just want to code, I don't want to deal with people who do, or read thousands of lines of foreign code.
  - sanxiyn 14y ago
    You may not want to read code, but you need to read code. I don't really consider code reading to be teamwork skill. Code reading is an essential coding skill.
- frozenport 14y ago
  1. Find a project you like 2. Spend a weeks looking at the code The daunting part is the time commitment.
  - zanny 14y ago
    This. You invest in a project and find out with your first merge the maintainers are assholes and toss out fine commits. I've seen that happen a bunch. It is why there are so many freaking forks, and a lot of them end up atrophying because one person can't recreate an ecosystem.
FourthProtocol 14y ago
This is a good guide for a starter, but doesn't address dealing with rock stars themselves, which is what's required if your contribution is going to be merged. And that usually requires the skin of a pachyderm, and the patience of a fox. The reality of today is that the world idolizes idols. Idols in turn become arrogant. Their worst trait is belittling others' contributions - especially when they're better than the rock star could've done. I have no solution. I'm pointing out what I see as an omission from an otherwise useful post.
bane 14y ago
Something I think that's interesting and too often overlooked is that even non-programmers can provide lots of help to Open Source projects, sometimes the help they can provide can be critical to the project's success. What kind of things? Everything from sane documentation to artwork is open and in need of lots of help in many projects.
lucian303 14y ago
Awesome post but instead of writing a program to move all the tickets over, a better suggestion would be to follow Joel's advice (http://www.joelonsoftware.com/items/2012/07/09.html http://www.joelonsoftware.com/items/2012/07/09.html) and get rid of that clutter. I can almost guarantee you most of those tickets were useless, completed, or irrelevant.
- petdance 14y ago
  I'm the author of the article, and throwing away the tickets was suggested many times by different people. We had a pretty big discussion in #parrot about the value of this ticket set. People on the project plowed through the Trac database and closed tickets, and even with that we still hundreds that tracked all sorts of development. Many were bug reports, and many were effectively to-do items, and many were bug reports that had been resolved but still couldn't be closed for various reasons, such as needing an automated test to verify it. It's nice to start over clean, but sometimes there's too much baby with the bathwater.
  - lucian303 14y ago
    Sounds like you guys did your due diligence. In that case, of course, writing the app to move them over is the right choice. Thank you for the article, BTW. It may be obvious to some but not to most. Especially contributing to documentation. I'd say that most open source projects can benefit more from that than from new features ... and maybe even most bug-fixes, depending on severity.
    - petdance 14y ago
      I'm glad you liked the article, and it seems to have struck a chord. One of the things I've found very handy is that I now have a place to point people on, say, StackOverflow when someone asks "How do I get started in open source?" I started 89starts.com as an offshoot of the article, but I haven't yet gotten it ready for prime time. Agreed about documentation, and at the top of my to-do list for today is making final edits to another article for them on open source documentation. Should be out in a week or two I think.
sanxiyn 14y ago
This post didn't mention internationalization, localization, and translation. Maybe because it was targeted to English speaking people? Here in Korea, a lot (probably majority) of people who contribute to open source started from i18n, l10n, and translation.

121 points by Baustin 14y ago

I love seeing the great discussion that this started (both positive and negative feedback). Thanks everyone for turning the post itself into an open source project.

8ig8 14y ago

Just a reminder: > If the original title begins with a number or number + gratuitous adjective, we'd appreciate it if you'd crop it. E.g. translate "10 Ways To Do X" to "How To Do X," and "14 Amazing Ys" to "Ys." Exception: when the number is meaningful, e.g. "The 5 Platonic Solids." http://ycombinator.com/newsguidelines.html http://ycombinator.com/newsguidelines.html

Baustin 14y ago
Sorry about that, folks. I'll keep that in mind for all future posts.
sublimit 14y ago
That seems awfully pedantic and useless as an official guideline. I mean, it's the same article nonetheless.

freework 14y ago

One thing I've learned about contributing to open source is that it's primarily a social achievement. If I see a developer who has contributed to many oss projects, I don't think "wow this guy must be a great programmer", I think "this guy must have great communication/people skills". Often (especially with popular oss projects such as apache, python, firefox), you can fix a bug, add it to the ticket tracker, and it'll just sit there and rot. Every day people fix bugs and upload patches. You have to contact someone and sweet talk them into merging your fix.

kyle_t 14y ago
You make a good point. For those just getting their feet wet with Open Source projects it makes sense to start first with a smaller yet active project.

reginaldo 14y ago

In the same area, OpenHatch[1] seems very nice. From their own landing page: OpenHatch is a non-profit dedicated to matching prospective free software contributors with communities, tools, and education. [1] http://www.openhatch.org http://www.openhatch.org

IridescentBlue 14y ago

How about contributing to Open Source by helping write the documentation for projects? Properly documented projects go a long way in helping developers get recognition and notice. I, myself, have begun more thoroughly documenting projects, not only for my sake but for everyone else that comes along. I find that this book helped me get up to speed quickly: http://www.amazon.com/The-Elements-Style-4th-Edition/dp/0205313426/?_encoding=UTF8&keywords=Elements%20of%20style&tag=produc05-20&linkCode=ur2&qid=1356985769&camp=1789&sr=8-1&creative=9325 http://www.amazon.com/The-Elements-Style-4th-Edition/dp/0205...

bilalq 14y ago

Thanks for this. When I was first getting into programming, people would tell me and others like myself to "go contribute to open source projects". I don't think they realized just how daunting and impossible that seemed to us at the time. To be honest, none of us even knew where to begin.

sublimit 14y ago
Well, many of us still don't. I don't think I have the necessary teamwork skills. I just want to code, I don't want to deal with people who do, or read thousands of lines of foreign code.
- sanxiyn 14y ago
  You may not want to read code, but you need to read code. I don't really consider code reading to be teamwork skill. Code reading is an essential coding skill.
frozenport 14y ago
1. Find a project you like 2. Spend a weeks looking at the code The daunting part is the time commitment.
- zanny 14y ago
  This. You invest in a project and find out with your first merge the maintainers are assholes and toss out fine commits. I've seen that happen a bunch. It is why there are so many freaking forks, and a lot of them end up atrophying because one person can't recreate an ecosystem.

FourthProtocol 14y ago

This is a good guide for a starter, but doesn't address dealing with rock stars themselves, which is what's required if your contribution is going to be merged. And that usually requires the skin of a pachyderm, and the patience of a fox. The reality of today is that the world idolizes idols. Idols in turn become arrogant. Their worst trait is belittling others' contributions - especially when they're better than the rock star could've done. I have no solution. I'm pointing out what I see as an omission from an otherwise useful post.

bane 14y ago

Something I think that's interesting and too often overlooked is that even non-programmers can provide lots of help to Open Source projects, sometimes the help they can provide can be critical to the project's success. What kind of things? Everything from sane documentation to artwork is open and in need of lots of help in many projects.

lucian303 14y ago

Awesome post but instead of writing a program to move all the tickets over, a better suggestion would be to follow Joel's advice (http://www.joelonsoftware.com/items/2012/07/09.html http://www.joelonsoftware.com/items/2012/07/09.html) and get rid of that clutter. I can almost guarantee you most of those tickets were useless, completed, or irrelevant.

petdance 14y ago
I'm the author of the article, and throwing away the tickets was suggested many times by different people. We had a pretty big discussion in #parrot about the value of this ticket set. People on the project plowed through the Trac database and closed tickets, and even with that we still hundreds that tracked all sorts of development. Many were bug reports, and many were effectively to-do items, and many were bug reports that had been resolved but still couldn't be closed for various reasons, such as needing an automated test to verify it. It's nice to start over clean, but sometimes there's too much baby with the bathwater.
- lucian303 14y ago
  Sounds like you guys did your due diligence. In that case, of course, writing the app to move them over is the right choice. Thank you for the article, BTW. It may be obvious to some but not to most. Especially contributing to documentation. I'd say that most open source projects can benefit more from that than from new features ... and maybe even most bug-fixes, depending on severity.
  - petdance 14y ago
    I'm glad you liked the article, and it seems to have struck a chord. One of the things I've found very handy is that I now have a place to point people on, say, StackOverflow when someone asks "How do I get started in open source?" I started 89starts.com as an offshoot of the article, but I haven't yet gotten it ready for prime time. Agreed about documentation, and at the top of my to-do list for today is making final edits to another article for them on open source documentation. Should be out in a week or two I think.

sanxiyn 14y ago

This post didn't mention internationalization, localization, and translation. Maybe because it was targeted to English speaking people? Here in Korea, a lot (probably majority) of people who contribute to open source started from i18n, l10n, and translation.