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.
Actually the message is coming from inside. That's where the chip is.
nosig today
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.
Obviously some users need support.
If you are good at troubleshooting, this is the way to go.
Good troubleshooting has also value for the programming rockstars.
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.
My biggest issue with Open Source is bug replication and bug report management. By the time I get to use a software and it has made it's way into the Ubuntu repositories it is already a few month old. Bug reports on that software in turn are often of limited use as a newer version might already fix the issue. The problem is that going through all the trouble of actually getting a new version, all the dependency, getting it compiled and setup is rarely practical. Thus a lot of bug reports end up hanging in the Ubuntu bug tracker, as nobody is going to spend time on checking that the issue still exist upstream and then reporting the issue to upstream, maybe including a better test case then found in the original report.
So simply put: If you want to help, act as a mediator between the developer and the user. Browse the bugtrackers and forums for problems users have, replicate them and check that those issues still exist. Then provide test cases or fixes for those issues to upstream and workarounds to the users.
Designing and building installers. It's something many programmers hate to do, and it's so critical to the success of the project. If installation doesn't go smoothly, many people will just stop there and never start using the program. It's also quite challenging, given all the subtle differences you encounter between different OS versions and even individual computers.
"I'm too busy to research this and form an educated opinion, but I do have time to tell everyone my uninformed opinion."
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.
Just wanted to add that I wrote a very similar article 8 years ago: ContributingToFOSS.
I know I'm far from the first to say it, but write docs. Here's how.
cheers
With regards to the ticketing system - if someone posts a ticket for a problem, see if you can reproduce the problem with their particular version. See if the problem still exists in the head of the latest code trunk. See if the problem is a duplicate of another problem. See if the problem is with the program, or somewhere upstream, say, a library that the program depends on. If so, report the problem upstream.
Core developers are busy, and most projects can use people who deal with and clean up tickets, leaving only real problem tickets to deal with. Also, sometimes a program or library from Gnome or freedesktop.org will have tickets in the trouble ticket systems of Debian, Ubuntu, Fedora, SLES, Gentoo etc. Someone doing a little coordination will be helpful.
The thing is, even top notch programmers unfamiliar with a large program are initially at a disadvantage to a middling programmer who is well-familiar with a large program. Everyone is initially at a disadvantage when a program breaks, no matter what the skill level. But even if your programming skill level is very low, most projects can benefit from extra help. Even if you just confirm a bug exists on your system too, or that you can't reproduce a bug - this helps core developers save time.
"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.