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.
Re:The most needed thing... (Score:5, Informative)
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.
Re: (Score:2)
The "why" is definitely important if you have code that needs to be maintained over a long period of time and by more than one person. Yes, anyone can read the code and figure out what it does, but without any indication as to why, future maintainers are likely to break it. Or, say you do things a certain way because of a known compiler bug--once that bug is fixed (maybe years down the road), someone else can pick up on that and change the code, since your comment indicated it was only done this way to avoi
Re: (Score:2)
Yes, anyone can read the code and figure out what it does, but without any indication as to why, future maintainers are likely to break it.
True, but comments aren't the only way to improve maintainability. If code can't be safely modified without comprehending a mountain of side effects, the real problem is coupling, not a lack of documentation. Good designs are easy to change, and bad ones are not. Just because an over-complicated system is well-documented doesn't make it easily maintainable.
Ideally, the
Re: (Score:2)
Re: (Score:2)
I disagree that comments should only tell you "why". The "what" is just as important, too. Of course, it really does depend on the situation and how complicated the code is but going by the logic of "if I wanted to know what it was doing, I'd just read the code" doesn't always work, or we'd all just learn ASM and read the OP Codes to figure out how stuff works.
Sometimes what the code is doing isn't immediately obvious to everyone - this is something that open source code in particular can benefit from, as a
Re: (Score:3)
a master coder's "obvious" code can be completely obfuscated to a novice programmer
Truly masterful code is never obfuscated. In fact, it looks a lot like novice code, pseudocode even. It's an amazing coming together of all the right ideas, all the right interfaces, to make code that reads exactly like what it does. Masterful code makes you wonder how the hell the programmer made it look so incredibly easy.
You may have heard of a joke about "write only code," commonly applied to perl and some other languag
Re: (Score:2)
I think there is a need for both sorts. If I want to quickly acclimate myself with a new project and zero in on a certain section, comments along the line of "begin user authentication" or some such help greatly, and I definitely don't mind finer granulation than that.
Comments in open source projects like that DEFINITELY help especially since the experience levels of contributors will be different and this way the newbies can quickly get up to speed or at least learn.
Definitely comments about the why, but n
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: (Score:1)
Speaking as somebody who has contributed documentation toi a few projects, it's extremely difficult for someone without the
requisite chops to write end user documentation unless they spend an inordinate amount of time distilling
the mailing list archives. Even so, that method is inadequate since not every feature is discussed on list and
the implementations of those that do may differ from what was discussed on the list.
Shitty attitudes from coders doesn't help either.
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: (Score:1)
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.
This is great advice for the non-technical QA / User Experience Tester. Someone who likes IT, but can't be bothered to learn can stack their resume by contributing in this manner (and let the real workers get to it...)
Re: (Score:2)
You can list "Uncovered and documented bugs on Firefox" on your resume? I thought only paid work experience applied.
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: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
Re: (Score:3)
Or, to put it another way, employers love someone who shows actual evidence they will work for their pay without being a whiny little bitch with first-world problems.
Re: (Score:2)
I'd like to bump your comment just for pointing out that quantitative statistics on a resume are a great idea! I've seen too many resumes where it's unclear exactly what someone did. "Maintained application X." Well, great. That sure tells me a lot. "Inherited application X from retiring developer; documented legacy codebase of over 3 million lines; improved performance 40%" tells me a LOT more about what someone did. (Yes, they could very well be lying, but a resume full of this stuff indicates either a tr
Re: (Score:2)
I wrote large chunks of the Mozilla 1.0 FAQ [mozilla.org]. You bet I listed it on my CV. This is back when no-one outside open-source circles had heard of it and IE's usage was 96%.
Re: (Score:2)
You can list "Uncovered and documented bugs on Firefox" on your resume? I thought only paid work experience applied.
Why exactly do you think people make such a thing about joining school science clubs, becoming president of a university societu, helping out at weekends with the Scouts, directing their local amateur dramtic outfit, or whatever? It's at least partly so they can go on your resume/CV. In many ways, unpaid work shows more about you than paid work does.
Re: (Score:2)
Re:The most needed thing... (Score:5, Interesting)
Yeah, man, like we're a semi-pro-football club, members have all been playing for 10+ years and we've all been on the team together for 3 or more, and there's lots of people who want to play with us because we totally kick ass, and man like, thanks for showing up, you know, why don't you start off our next game?
If you want to contribute code quickly, think about joining a smaller project, or even reviving an interesting looking dead one.
If you want to be a part of something big and high profile, be prepared to work the bottom of the bug list, or do some documentation.
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: (Score:2)
Attitude like yours is probably why many programmers are deterred from contributing.
I mean nothing like submitting a patch that you worked hard on, tested, documented, just to be completely ignored. Or being told that you are a moron, your patch is not in line with the "semi-pro-football club"'s ways or some other bullshit.
Re: (Score:2)
Personal insults aside, the "semi-pro football club's ways" are probably part of the reason they are a long term successful project. Projects are better off without volunteers who toss out their patches on an as-is basis, and then get upset when noone else wants to clean them up to meet the project's standards and commit them to the mainline.
Re: (Score:3)
like python and postgresql?
Re: (Score:2)
Testing and documenting the flaws isn't that bad. It frees you up to listen to news, college lectures, or audiobooks (since testing doesn't require a lot of mental concentration). And if you are getting paid 50-60 an hour, the testing is even less of a chore.
Re: (Score:3)
Welcome to the rest of the software industry. Guess what "junior" developers are hired to do? They get stuck with the crap no one else wants to bother with, and once they prove themselves, they get to move up the food chain (either within the company, or having gained enough experience to bail for a better job.)
Re: (Score:3)
definitely agree. If a tool you use actually has something like a user manual or a help file, read through it and submit comments/improvements/suggestions (probably should check with project leader first so he doesn't just think you're being a grammar jerk. there may also be a way he prefers you submit doc. changes.) If there's a tutorial set, work through them and note any discrepancies. Tutorials often fall behind software revisions. Last, write some of your own tutorials and offer to make them part of
Re:The most needed thing... (Score:5, Insightful)
Re: (Score:2)
It's because so few people use versioning systems as versioning systems. Many use it as a method for control first and everything else a distant second.
Not that there's anything wrong with exerting control over a repository, it's just silly that it tends to come at the cost of actually using the functionality of a repository.
Re: (Score:3)
Avoiding repository churn is an euphemism for being change averse as a way of life, no matter what. It's a negative personality trait. I wouldn't loudly proclaim it.
I mean, what the heck, do they worry that they'll overflow the revision counter in subversion of something? What kind of idiocy is that ... I'm glad nobody has ever told me not to submit something just to prevent "repository churn". I hope it's not some wider-reaching phenomenon...
Re: (Score:2)
I commit frequently. I'm a bit perturbed by people who don't.
(Of course, I use git, so I can do local commits as often as I want, and only push when I'm confident what I'm sharing isn't a broken mess.)
Re: (Score:2)
I do the same. Many commits are small, sometimes few-liners if I'm hunting bugs and writing/updating tests.
Re: (Score:2)
They may be being polite. Good documentation is useful; bad documentation is not only useless, but often becomes a maintenance nightmare, if it documents the wrong things, or, especially, if it actively misleads those who come later. No documentation is generally preferable to bad documentation. So, your patches have to be audited, just like a patch containing code would. Which is extra work for someone who may have limited time for the project, and other priorities. Also, even if you say your patch is
Re: (Score:2)
True, but stuff should be documented by the people who wrote it, they are the ones who know how it works.
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
There's nothing to stop you posting to your own website some 'tutorial to using (whatever)' ...
Of course, you then have to hope that you haven't decided to document stuff that the developers have deprecated but haven't bothered documenting.
The sad thing is that the programmers who write the code are typically the *worst* at writing documentation -- they may developed their own jargon or niche terminology which makes reading the docs no better than reading the code directly. Imagine reading some MVC framewo
Re: (Score:2)
Of course there needs to be a difference between technical documentation and user documentation. Both work well as wikis (FAQs being a sneaky form of wikis)
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.
Re: (Score:3)
I've contributed documentation to a few projects, but only those who use a wiki approach to documentation. The one attempt I made to contribute documentation to a piece of software I used a lot but which didn't have a wiki ended the same way as yours - 'thanks but no thanks'. I don't think wikis make for the absolute best documentation (unless someone puts a lot of effort into organization, you end up with a lot of randomly arranged howtos), but they're extremely low threshold as far as getting end users
Re: (Score:2)
That's a shame. My last big OSS project, Weasel Reader [weaselreader.org], was a Palm OS program so it was, by nature of the OS, much simpler than a standard PC program. And, as well as the project turned out and for all the users I had, I have to admit that my biggest failure with it was the lack of external documentation.
The code was well documented and the program had useful in-app help texts and such. Also, I think there was sufficient web page documentation for the PC command line tool which generated the text/book da
Re: (Score:2)
Hey, I remember Weasel Reader; I used it for years from when it was still called GutenPalm. Thanks for writing it - it made many a commute far more tolerable!
As you say, I doubt there were many users who would have needed a more comprehensive manual to get up and running, but I notice that even when your project didn't need anything that huge in the way of a manual, writing the whole thing still seemed daunting enough that you (or any other contributor) never got around to tackling it. That barrier to ent
Re: (Score:2)
Yeah, GutenPalm... right up until I received that stupid cease and desist letter from Palm when they decided that they owned the word. At least Android hasn't done something stupid like that.
And thanks for the reply. One of these days (again, Real Soon Now) I need to revist it and write an Android version. In general, I'm just as unhappy with the currently available reader programs for Android as I was back in the early Palm days, though for different reasons. Still, just as before, most reader apps hav
Re: (Score:3)
As an open source developer, I think I speak for many of us when I say please don't be put off, we're not all like that.
I consider documentation to be very important. One of the biggest contributions made to my project was someone essentially documenting a large amount of it. It has certainly made a big improvement to the community as people cna join much more easily. Also it introduced a culture of documentation which makes other people more likely to document.
For GUIs, it's a bit more tricky. Programmers
Re: (Score:1)
As a life-long programmer myself, I've always had great relationships with the tech writers I work with. For one, I may be excellent at coding, but I'm crap at prose, and the delicate task of writing prose that is both understandable and accurate is a truly hard skill. Programmers need to have a little humility towards, and understanding of, tech writers. The other big thing about tech writers in my career has been that if a tech writer comes to me and says "I don't know how to describe this" it occasion
Re: (Score:1)
Re: (Score:1)
Even if you *are* a rock-star programmer, if you happen to be able to write, working on documentation is probably going to be a more important contribution to usability that messing with the code. Bad or missing documentation is the number one reason why most free software is unusable. And it you can both program and write, your docs are going to be a lot better than if you can only write.
-- hendrik
Re: (Score:2)
Exactly. I'm trying to sort out istgt on FreeBSD at the moment, and the documentation is uh..... sparse, to say the least.
If something was hard to get working, write a howto for it. A. it will help you remember how to do it 18 months down the track, and B. you'll help fix the lack of documentation problem that made it hard to get working in the first place.
Re: (Score:1)
Documentation.... This is the most needed thing in open source.
Documentation is a perennial problem that's just damn hard to solve. I spent years working my ass off just trying to get one single project documented properly, and I had help from several other people.
Trying to do a thorough and complete job of documenting something that changes continuously is a fool's errand. It's not impossible, it's just monumentally huge, and there just aren't enough decent writers in the world to volunteer enough hours to get it done properly. There are always plenty of eager volu
Re: (Score:2)
If you want to get accepted into GSoC (at least by serious projects), you have to have something to show. It also requires a serious commitment, and it's expected that you'll continue working on that project. So it's not really a great way to start contributing.
On the other hand, I found the non-paid and non-binding Season of KDE much better for starting, because the pressure on both students and mentors is much lower.
I participated in both programs only as a student, so I have no information from the mento
Re: (Score:2)
[1] Espe
release day help outs (Score:4, Interesting)
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.
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: (Score:3)
Re: (Score:3)
What is needed is people who know nothing to do beta-testing. Sure, feedback is appreciated from people who know how to code, what is needed is feedback from those pesky users.
This. Get in there and break shit.
Or even just a 'thank you' to the makers, so the makers will be motivated to go on. An email saying something like "Thanks for making this program. Keep up the good work. I really like it." will be great to programmers.
And this. Debian reportbug even has a "--kudos" option for the purpose :-)
Re: (Score:3)
Localization is always needed, either correcting, improving or adding translations for an open source project.
While localization is an easy way to put time into a project, I find it is more often done only because it's easy, not because there is a need for it. I personally have given up on accepting localization on my newer projects simply because the overhead of maintaining those localizations is just to big and not worth the effort. And half the time the localizations are worthless anyway, as they are almost always outdated and incomplete, as getting localization updates never happens in sync with the release. Th
Re: (Score:2)
Test new releases on your platform (Score:3, Interesting)
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.
Re: (Score:2)
Sadly "This latest version of Firefox doesn't work on my platform (XP with Pentium 3)" or "Safari 4 refuses to work on my MacG5" is usually greeted with "Upgrade it."
And perhaps they're right but I can't help all my hardware refuses to die. ;-) I feel no desire to throw-away stuff that isn't broke (why I still use 2 TVs from the 70s and 80s).
Bug Reports (Score:3, Interesting)
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.
Re: (Score:2)
Re: (Score:3)
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. ;)
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.
Why I hesitate (Score:2)
-Can't even think of contributing to OpenOffice or Gnome, since just setting up the build environments for those is highly complex, I've heard.
-Huge amount of time to build and test those programs.
-I'm afraid of what setting up the dev libraries would do to my normal environment I use for normal work.
-Requires a hugely powerful machine, whereas some of us like to work on a less-powerful, smaller, portable laptop.
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.
Re: (Score:2)
-Can't even think of contributing to OpenOffice or Gnome, since just setting up the build environments for those is highly complex, I've heard.
-Huge amount of time to build and test those programs.
-I'm afraid of what setting up the dev libraries would do to my normal environment I use for normal work.
-Requires a hugely powerful machine, whereas some of us like to work on a less-powerful, smaller, portable laptop.
This is why anyone into this stuff needs access to (at least) two boxes; "Production" that you use for every day use (incl. work), and "Development" or "Sandbox". You can find a year old box for a fraction of the price of the latest ones, sometimes just by walking in an alley (users throw out the strangest things). If something/you futz(es) up your Dev box, blow it away and re-install. You also won't need it to run $another_os on it, so you won't need to worry about that getting blown away if you futz up
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.
Re: (Score:1)
just use a chroot, or maybe even lxc.
debootstrap is a great helper there, too.
Rock Star Programmers? (Score:5, Insightful)
Unix Philosophy (Score:3, Interesting)
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.
Support (Score:2)
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.
Bug replication (Score:3)
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.
Installers (Score:3)
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.
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.
Artists and musicians needed a lot too. (Score:2)
Many open-source projects need more than just programmers. If you have an artistic bent, whether it's musical or with actual artwork, look around and see if there are any open-source games that require input.
In my case, I contributed (as 'Pangloss') to an open-source remake and update of 'Elite' (the first open-ended 3D space trading and combat game) called Oolite [oolite.org]. Once you learn a few things about the game, you start posting hints and tips for other people on the forum [aegidian.org] and before you know it you're getting [aegidian.org]
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.
I wrote similar article 8 years ago (Score:2)
Documentation (Score:2)
cheers
Tickets (Score:2)
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,
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.
Support Forums (Score:1)
It is one of the easiest ways of contributing to the open source browser without having to dig into its code.
Being a regular user of the browser, I am already familiar with most of its features and options. So, the learning curve is pretty easy.
Even answering fairly "low-hanging fruits" like this one [mozilla.org] can be a pretty rewarding feeling.
On top of that, you get to closely observe the diverse ways in which real end-users interact with a
What else is there? (Score:2)
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
Maintenance of the code IS bug fixing, or adding a new feature to old code. From a programming standpoint, what else is there? What is in your trouble ticket system that is NOT a bug of a new feature?
Re: (Score:1)
Maintenance of code and the systems surrounding the code often are neglected in the rush to create new features and to fix bugs.
Making sure the text properly conveys your intended meaning often is neglected in the rush to get a comment or story posted.
Debugging and documentation (Score:2)
I am no great programmer, but I am usually good pretty good at following logic in code. I can usually tweak a little code here and there to get the desired result. Many times, bugs in code comes from typos and / or poor documentation in the code. Pretty much, anyone with a year or two of programming in school can do some simple debugging.
Back in my Linux days, I helped with some of the early DVD software code. This was the days before DeCSS, so we were working on getting drivers and software working for a h
Great apples to apples example (Score:2)
ColdFusion: There's a commercial version (Adobe's) and open source version that almost exactly the same (Railo). (There's also another open source version, Open BlueDragon, but it has diverged enough away from the original version that it's not a good comparison - but honestly I feel OpenBD docs are the best of the 3)
I won't say the Adobe documentation is great, but it is very complete, with every tag and function fully documented. Railo, however, has a loosely organized wiki, with semi-complete docs for 3.
Marketing (Score:1)
Many, many open source projects need a marketing strategy and execution (did I say execution). It starts with descriptions of the project, the target audience (library for programmers, end users, supported OS, functions/features, competition/comparable projects, positioning (faster, smaller, more beautiful, supported, ...). Also gather stories from users, how they use it why and what they'd like to improve. Also don't forget history.
Make this knowledge available in a thoughtful way, if possible on the proje
complex testing (Score:1)
Another great way to contribute is through complex testing, such as vulnerability testing, penetration testing, security testing, performance testing.
You do not need to be a great coder to run a test app, if you happen to have access to it. Run it and report the results or even better turn it into singular bug reports.
The same is true for performance testing. If you use a particular project, see what performance characteristics are important to you and distill a canned test with appropriate data (so it is r
Re: (Score:1)
Do it like most here on Slashdot
In your mom's basement, with your hand...
Sorry couldn't resist.
Re: (Score:2)
You need at LEAST one page dedicated to explaining WHAT your application is, what it does, and why it does it well (i.e. why should one use this application instead of X or Y other method )
I think that is what's lacking right now.