Slashdot Mirror
How To Contribute To Open Source Without Being a Programming Rock Star
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?
Documentation.... This is the most needed thing in open source.
No good deed goes unpunished.
I have a few linodes around that 99% of the time have plenty of spare bandwidth, so I will typically start seeding the torrents when a new release hits, even of a distro I don't use, and I'll upload 25gb or so.
Don't blame me, I voted for Kodos
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)
There are lots of platforms and the developers might not have access to all combinations of hardware and compilers. It's always good to hear about tests of new releases even (especially) if it's simple "works for me" on such-and-such platform.
Report bugs you find with detail, and any errors you receive, what you were doing when you received the error, etc. Enable automatic bug reporting if the program has such a feature.
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. ;)
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 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.
Um... I guess you haven't seen much open source code... Rock stars are definately not required.
I had written a Python script consisting of about a couple of hundred lines of code (including comments) for a task I do on a regular basis. I've been meaning to add features to it but haven't touched the code for over a year because to be honest, although I had structured it into proper functions/procedures only doing one task and group similar code into packages and had commented it, it was still a bit of a mess.
I recently stumbled upon the Unix philosophy and it gave me a different perspective on how to program. I think the biggest eye-opener for me was the concept of connecting a number of small programs via streams to make larger programs. I've done this many times by for instance by piping the contents of find through grep to find a piece of text in a number of files but it did not occur to me that this could be used in programming. The implication is that rather than writing a lot of code, it could be easily done in a lot less lines by calling an existing program and putting the output into a data structure to be used by the program.
I've been googling more about the Unix philosophy and I have tried to apply it to the Python script I had written. The things that stood out was writing a program that did one thing well and prototyping to get the program working then refining afterwards. I've had a look at my code and see a lot of functions and procedures that do a number of tasks. An example of this was one that was extracting data from a data structure and putting it into a pyGTK treestore. I had separated this and redesigned a new function to extract the data so that it outputs text to the function that puts it into the one which populates the pyGtk TreeStore. A useful thing about this is that it is easier to pull the code from this and insert it into other programs if I wish. As well as this, I am looking at other ways to make the code easier to debug and to add extra functionality.
I think a lot of the Unix philosophy is common sense and I'm sure it is second nature to experienced programmers but to casual coders like myself, it is a number of guidelines that points me in the right direction.
Your resume is a document that shows what you have done, and backs up your assertion that you're qualified to do the stuff you've applied for. What you're paid -- or whether you are paid -- is not relevant. Accomplishments are.
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.
http://rocknerd.co.uk
LibreOffice, however, has a collection of easier fixes specifically to lure people in. And it works. Every project should do this.
http://rocknerd.co.uk
A recent /. story discussed the bookOpen Advice which is about finding ways to contribute. It's worth reading.
"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.
-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.