How to Contribute to Open Source without Being a Programming Rock Star(blog.smartbear.com)
blog.smartbear.com
How to Contribute to Open Source without Being a Programming Rock Star
http://blog.smartbear.com/software-quality/bid/167051/14-Ways-to-Contribute-to-Open-Source-without-Being-a-Programming-Genius-or-a-Rock-Star
10 comments
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
> 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
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.
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.
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.
What kind of things? Everything from sane documentation to artwork is open and in need of lots of help in many projects.
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.
Here in Korea, a lot (probably majority) of people who contribute to open source started from i18n, l10n, and translation.
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.
1. Find a project you like 2. Spend a weeks looking at the code
The daunting part is the time commitment.
The daunting part is the time commitment.
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.
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.
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.
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
OpenHatch is a non-profit dedicated to matching prospective free software contributors with communities, tools, and education.
[1] http://www.openhatch.org
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.
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/0205...
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/0205...
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) and get rid of that clutter. I can almost guarantee you most of those tickets were useless, completed, or irrelevant.
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.
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.
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.
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.
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.
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.
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.