How To Contribute To Open Source Without Being a Programming Rock Star 120
Esther Schindler writes "Plenty of people want to get involved in open source, but don't know where to start. In this article, Andy Lester lists several ways to help out even if you lack confidence in your technical chops. Here are a couple of his suggestions: 'Maintenance of code and the systems surrounding the code often are neglected in the rush to create new features and to fix bugs. Look to these areas as an easy way to get your foot into a project.
Most projects have a publicly visible trouble ticket system, linked from the front page of the project’s website and included in the documentation. It’s the primary conduit of communication between the users and the developers. Keeping it current is a great way to help the project. You may need to get special permissions in the ticketing system, which most project leaders will be glad to give you when you say you want to help clean up the tickets.'"
What's your favorite low-profile way to contribute?
The most needed thing... (Score:5, Insightful)
Documentation.... This is the most needed thing in open source.
Also... (Score:5, Insightful)
Well, if you're a programmer feeling like you may not be a programming rockstar and are afraid to contribute... consider that most projects are not written by programming rockstars either. The codebases might be large and intimidating because people have put in a lot of time getting lots of things to work, but it's often packed with cases of, "it's good enough for now". And that's not necessarily a bad thing, it keeps things moving forward.
I know Steve Jobs isn't the right character to invoke here, but he once said:
Once you discover one simple fact; and that is everything around you that you call life was made up by people that were no smarter than you. And you can change it, you can influence it, you can build your own things that other people can use. Once you learn that, you'll never be the same again.
I lean on that from time to time, and it's usually right. The only trick is knowing when it's wrong. ;)
Re:The most needed thing... (Score:5, Insightful)
New feature review (Score:5, Insightful)
Speaking as someone who contributes to PostgreSQL, one of the projects mentioned in TFA, the easiest way to contribute something useful to that project while having some fun too is to test out new features. Reviewing a patch [postgresql.org] that hasn't been committed yet is part of the community process for validating what features get committed. And testing recently committed features is useful too, to help flush out bugs in them before release. Working on new features seems to be more attractive to new contributors than trying to fix old problems, and good reviewing skills flow naturally into becoming a code contributor too.
Rock Star Programmers? (Score:5, Insightful)
Re:The most needed thing... (Score:5, Insightful)
...this is exactly the way you put it to volunteers if you want to look like a complete tool - and want them to fork your shit just so they don't have to deal with you.
Re:The most needed thing... (Score:5, Insightful)
I don't know if I agree with the premise.
Ideally, IMHO, code comments will tell you 'Why' you chose to do something instead of what is being done. If I wanted to know what is being done, I'd read the code. If I want to know why they chose to split the array instead of slicing it (arbitrary example)... that's what comments are for. For someone to come in and make a comment on why some algorithm was chosen over another is like trying to read minds.
Oh my, no. (Score:4, Insightful)
Re:The most needed thing... (Score:5, Insightful)
You can list "Uncovered and documented bugs on Firefox" on your resume? I thought only paid work experience applied.
You can put anything on your resume that you want. There is no Resume Police. You should put on your resume anything that will make the reader say "Hey, I need to bring this person in for an interview." Conversely, you should not put anything on your resume that does NOT make the reader say that. Your two summers at McDonald's? Don't bother, even though it's paid work experience. Blog post on the topic: Should I put _____ on my resume? [petdance.com].
With any experience on a resume, you'll want to quantify it as much as possible. Compare: "Uncovered and documented bugs on Firefox" with "Uncovered and documented 47 bugs in Firefox over a six month period." The latter gives the reader a better idea what it is you've done. More on using numbers in your resume: Numbers and resumes [petdance.com].
Where did you get the idea that it could only be paid experience? Did something tell you that? If so, I'd love to find out what book or blog told you so that I can bookmark it as bad advice.
Re:The most needed thing... (Score:5, Insightful)
Even simple in-code comments help cut down the time required to understand the thought process behind the code.
Developer docs are sorely needed, true, in many projects. But to my mind, the more grating lack is USER documentation. You know, decent manuals on how to use the software. No amount of commenting code will ever help with that, and I suspect is the area where non-developer contributors can help out the most.
Re:The most needed thing... (Score:4, Insightful)
The few marginally serious contributors I know have attributed that attitude to two things (they mostly have the same attitude whether they'll admit it or not).
1) They feel that proper (G)UI design as well as documentation and otherwise slows down coding. That's not even really wrong in a technical sense, but holy hell is it wrong in every other sense.
2) They don't want someone coming in after they've done all the "hard work" and telling them that something should really behave differently because it would be more user friendly.
It's a bad attitude, it's a common attitude among programmers, I even catch myself thinking that way once in a while.
I suspect it will always be a bane of OSS, because the buck starts and stops with programmers and we're generally an egotistical and stubborn lot.