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?
Re:The most needed thing... (Score:5, Informative)
A few easy ones (Score:5, Informative)
Localization is always needed, either correcting, improving or adding translations for an open source project.
Doing themes, skins, plugins, macros, whatever is around it that is not specifically programming and could need less or different skills than programming.
Also actually using it and being vocal about that fact, the social component make people aware that exist that software, that have users that you know, and that there is a point of contact with the community behind it.
Documentation, and everything around documentation (i.e. putting in your blog or in a comment how to do x with that software)
Re:The most needed thing... (Score:5, Informative)
Shame you're posting at 0. If you aren't a great coder, read some existing code and document what it does. If you don't understand it, probably the next person along won't either. Find the person who wrote it and get them to give you a quick explanation, then write up that explanation in more details. Add doxygen comments. This is also a great way of learning a new codebase. If you think something is wrong, ask - you may have just spotted a bug.
Beyond that, look at the bug tracking system. See if you can reproduce bugs. If you can, try to produce a reduced test case. Detailed bug reports are incredibly valuable. Taking a bug report that says 'foo doesn't work' and saying 'when given X input, foo crashes with this stack trace. Valgrind output is {attached}. Problem appears to be in bar.c, but I don't know enough to fix it.' is amazingly valuable. Even just looking at the bugs, working out which person is most likely to be able to fix it, and making sure that they are aware of the bug is helpful. One of the best things about LLVM's development model is that when someone files a bug related to my code it gets assigned to me quickly, so I don't have to spend any time reading bug reports - ones I am likely to be able / wiling to fix are emailed to me automatically. This only happens because people are paid to do it. On other projects, volunteers who are willing to do this (tedious) work are worth their weight in gold.
Re:The most needed thing... (Score:5, Informative)
I think this is everyone's biggest issue with Open Source. It also seems to be the "least wanted" by programmers working on the projects.
As a professional tech writer, I've offered my services to a few open source projects that I'm a fan of but feel have a major lack of documentation. In each case I've been rejected. I've basically been told, "Our programmers write all of our documentation." The existing documentation in each case might as well say "just figure it out." I've offered GUI design in the past as well. Lets just say this didn't go over well at all.
It seems that Open Source is a programmers club more than anything. It's a real shame. There's so much talented work going into the development of the software that it would be nice if the rest of the work (documentation, gui design, graphic design, etc) was doled out to the experts. There's nothing wrong with admitting that you're not super talented at everything.
Re:The most needed thing... (Score:4, Informative)
Actually, many hirers like to see a service position on a resume. I get the point you're making but that's actually kind of a lousy example.
If you worked at a fast food place for more than six months, or went back two summers (showing that they actually wanted you to come back) it means you can eat shit and grin*. Whether that came from the public or your manager or both, it's something many people who hire like seeing.
*Not that they'll necessarily put that to the test in the position you're applying for, but being able to put up with somewhat hostile environments without flipping out is a plus
Things I do (Score:5, Informative)
I'm a sysadmin and totally not a coder. But I'm also a writer. So
1. Install it on stuff. In particular, install it on platforms that aren't Fedora or Ubuntu. Document problems you find. Cross-platform = robust.
2. Documentation, FAQs. The documentation always lags. 1. will generate lots of stuff you write up. Wikis can always do with maintainers too.
Re:Why I hesitate (Score:5, Informative)
LibreOffice, however, has a collection of easier fixes [documentfoundation.org] specifically to lure people in. And it works. Every project should do this.
Open Advice (Score:4, Informative)
A recent /. story discussed the bookOpen Advice [open-advice.org] which is about finding ways to contribute. It's worth reading.
Adopt a core library module (Score:4, Informative)
"What's your favorite low-profile way to contribute?" Well, since you're asking...
Something that's been on my "todo" list for ages is to volunteer to maintain some of the modules in the core perl library. That's something that any solid perl programmer ought to be able to help with (even if your C skills aren't well tuned-up at present), and I've been told that there's a shortage of people willing to do it.
Writing documentation is a great idea too, of course, but while the perl docs can always use some work, they're actually pretty good compared to some other projects. Perl programmers seem to like to write things down.
Andy Lester himself is famous for being willing to write test code. That's a good way to go, of course: there are still some big projects out there that barely have any tests.
Re:Why I hesitate (Score:4, Informative)
-I'm afraid of what setting up the dev libraries would do to my normal environment I use for normal work.
You should never install anything into the global directories, instead install things into your home directory by setting the prefix:
PREFIX="/home/juser/dev/software/"
make
make install
Then when you want to compile/run anything depending on the installed library:
PREFIX="/home/juser/dev/software/"
export PKG_CONFIG_PATH="${PREFIX}/lib/pkgconfig/";
export LD_LIBRARY_PATH="${PREFIX}/lib/";
export LD_RUN_PATH="${PREFIX}/lib/"
export LIBRARY_PATH="${PREFIX}/lib/"
export CPLUS_INCLUDE_PATH="${PREFIX}/include/"
export C_INCLUDE_PATH="${PREFIX}/include/"
For Python, Ruby, etc. you might need a few more variables to make things visible to them, but generally speaking there is almost always a way to install stuff locally without messing up the rest of the system.