How To Contribute To Open Source Without Being a Programming Rock Star

← Back to Stories (view on slashdot.org)

How To Contribute To Open Source Without Being a Programming Rock Star

Posted by Soulskill on Monday March 12, 2012 @06:30AM from the step-one-become-a-programming-rock-star dept.

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?

120 comments

Min score:

Reason:

Sort:

The most needed thing... by Hydrian · 2012-03-12 06:32 · Score: 5, Insightful

Documentation.... This is the most needed thing in open source.

--
No good deed goes unpunished.
1. Re:The most needed thing... by Dexter+Herbivore · 2012-03-12 06:36 · Score: 4, Informative
  
  There's 2 comments on this story so far, and yours has hit on my major bugbear. Documentation is the biggest issue with most projects that I've seen. Even simple in-code comments help cut down the time required to understand the thought process behind the code.
2. Re:The most needed thing... by TheRaven64 · 2012-03-12 06:41 · 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.
  
  --
  I am TheRaven on Soylent News
3. Re:The most needed thing... by baenpb · 2012-03-12 06:42 · Score: 2
  
  Also the reason it's harder to get newbie programmers(like myself) interested in an open source project. "Welcome to the group, you're in charge of what the rest of us don't want to do!"
4. Re:The most needed thing... by Auroch · 2012-03-12 06:43 · 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...)
  
  --
  Quartz Extreme and Core Image. Are there any other real reasons to spend all that money on generic hardware?
5. Re:The most needed thing... by jank1887 · 2012-03-12 06:47 · Score: 2
  
  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 the documentation or wiki, or host then on your own site.
6. Re:The most needed thing... by utkonos · 2012-03-12 06:58 · Score: 4, Insightful
  
  One thing I would love for someone to explain is why are projects so worried about so-called churn in their repositories? To be honest, I would agree that documentation is something that is sorely needed. And when it isn't missing is typically a bit of a mess. But if you go and submit patches for documentation, devs tend to start whining about making too many changes and "repository churn". Personally, I would have though that the point of using a repository in the first place is so that you can have a developer commit their attempt at documentation then have others who are better at things like technical writing or even writing period come along behind and clean up what is there. Too many times I hear devs saying that docs only should have significant improvements and major error corrections. That going over a doc with a fine tooth comb and correcting all grammar, spelling, punctuation, and style mistakes will wake some mythical churn beast inside the repository that will eat everyone's code. The idea of keeping whitespace changes separate from content changes is clear, but that is only so that the translation teams can know what patches and changes they can safely ignore.
7. Re:The most needed thing... by JoeMerchant · 2012-03-12 06:59 · Score: 4, 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.
8. Re:The most needed thing... by Hentes · 2012-03-12 07:00 · Score: 1
  
  True, but stuff should be documented by the people who wrote it, they are the ones who know how it works.
9. Re:The most needed thing... by ProppaT · 2012-03-12 07:03 · 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.
  
  --
  Wise men say, "Forgiveness is divine, but never pay full price for late pizza."
10. Re:The most needed thing... by Anonymous Coward · 2012-03-12 07:16 · Score: 0
  
  You can still start your own open source project. Just because you're a newbie doesn't mean you can't start one.
  
  Who knows you might come up with something that rivals PHP or MySQL.
11. Re:The most needed thing... by cpu6502 · 2012-03-12 07:19 · Score: 1
  
  You can list "Uncovered and documented bugs on Firefox" on your resume? I thought only paid work experience applied.
  
  --
  My AC stalker: " I personally agree with your posts most of the time, but that won't keep me from modding you troll"
12. Re:The most needed thing... by Anonymous Coward · 2012-03-12 07:24 · 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.
13. Re:The most needed thing... by tuffy · 2012-03-12 07:30 · Score: 1
  
  Not necessarily. Sometimes the act of explaining how stuff works to a documenter can not only make for better documentation, but enlighten the original developer as well. The development of the "Inside Macintosh" documentation is one such example.
  
  --
  Ita erat quando hic adveni.
14. Re:The most needed thing... by nschubach · 2012-03-12 07:31 · Score: 4, 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.
  
  --
  Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
15. Re:The most needed thing... by kefkahax · 2012-03-12 07:32 · Score: 1
  
  Thanks! Write documentation, help with technical support and educate your friends on why open source is important. We'll love you long time, baby!
  
  --
  Easy BitCoins
16. Re:The most needed thing... by cpu6502 · 2012-03-12 07:36 · Score: 1
  
  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.
  
  --
  My AC stalker: " I personally agree with your posts most of the time, but that won't keep me from modding you troll"
17. Re:The most needed thing... by oneiros27 · 2012-03-12 07:42 · Score: 1
  
  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 framework documentation that never explains what MVC is. (replace MVC for any other methodology).
  The program might make perfect sense to those who wrote it, but unless others have the same experience and mindset, it's a hurdle for others to try to understand.
  
  --
  Build it, and they will come^Hplain.
18. Re:The most needed thing... by petdance · 2012-03-12 07:51 · 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?.
  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.
  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.
19. Re:The most needed thing... by AdrianKemp · 2012-03-12 07:52 · Score: 1
  
  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.
20. Re:The most needed thing... by tibit · 2012-03-12 07:54 · Score: 2
  
  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...
  
  --
  A successful API design takes a mixture of software design and pedagogy.
21. Re:The most needed thing... by AdrianKemp · 2012-03-12 07:56 · Score: 3, 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
22. Re:The most needed thing... by idontgno · 2012-03-12 07:56 · Score: 4, 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.
  
  --
  Welcome to the Panopticon. Used to be a prison, now it's your home.
23. Re:The most needed thing... by David+Gerard · 2012-03-12 08:01 · Score: 1
  
  I wrote large chunks of the Mozilla 1.0 FAQ. 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%.
  
  --
  http://rocknerd.co.uk
24. Re:The most needed thing... by AdrianKemp · 2012-03-12 08:03 · Score: 3, 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.
25. Re:The most needed thing... by David+Gerard · 2012-03-12 08:05 · Score: 2
  
  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.
  
  --
  http://rocknerd.co.uk
26. Re:The most needed thing... by BattleApple · 2012-03-12 08:11 · Score: 1
  
  Some developers are just not very good at writing documentation. They tend not to look at things from the point of view of the user. They'll omit details that are obvious to them only because they're so familiar with the code. Besides, I'm sure most programmers would always rather be coding than writing documentation, so they don't spend as much time as they should on it.
27. Re:The most needed thing... by gorzek · 2012-03-12 08:11 · Score: 1
  
  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 avoid a compiler bug (trivial example.)
  Documentation explaining what the code is doing can be helpful if, in the course of reading it, you realize it doesn't actually do what the documentation says. :) Again, though, this goes back to what the original programmer intended and why, something you can never divine from code alone.
  
  --
  Check out my world simulator thingy.
28. Re:The most needed thing... by gorzek · 2012-03-12 08:17 · Score: 1
  
  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 true bullshit artist or someone who knows what they're doing, and I can figure out which is which when I'm interviewing you.)
  I'd also point out that the accomplishment statements on your resume are the least verifiable pieces of information in the whole document, so don't be afraid to toot your own horn. I think software developers are more likely to downplay their individual contributions, but in a resume you really need to talk yourself up, since it's basically a sales pitch to prospective employers.
  
  --
  Check out my world simulator thingy.
29. Re:The most needed thing... by Xtifr · 2012-03-12 08:17 · Score: 1
  
  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 pure documentation, it still needs to be audited to make sure you're not trying to sneak in some code changes. A pure-documentation patch requires just as much work as a pure-code one. Maybe even more, because you don't just have to check what the code does--you've got to compare it to the code and make sure it's accurate and not actively misleading or pointless or dependent on irrelevant details of the implementation that are subject to change without notice.
  Furthermore, the world is full of grammar nazis who believe the most absurd things about English (like, split infinitives are bad, or sentences shouldn't end with prepositions). America is in love with The Elements of Style, which Prof. Geoffrey Pullum of the University of Edinburgh describes as a "toxic mix of purism, atavism, and personal eccentricity [...] not underpinned by a proper grounding in English grammar. It is often so misguided that the authors appear not to notice their own egregious flouting of its own rules." I can't tell you how many times I've received patches from people "correcting" things that weren't wrong to start with. And that's not even counting the people who don't realize that American English and British English differ.
  On top of that, churn is a real, albeit fairly minor, thing. If a problem crops up, you may need to juggle dozens of patches between several branches. Adding in lots of niggling little patches that don't actually affect the code (but do affect any attempts at automatic merging) can only complicate this. But that's such a minor issue overall that I can't help but feel there's more going on.
  My advice? Start small. Open source development is a social activity. Get known by making small-but-useful contributions before attempting to send in that huge patch that modifies every file in the system, and don't be a dickwad. If the people involved know you and feel they can trust your judgement, they're far more likely to accept your contributions. And if the problem is really that the project is actually run by dickwads (which happens), find another one to contribute to. It'll be better for your sanity and everyone else's. Fuck 'em if they can't take a <strike>joke</strike> patch. :)
30. Re:The most needed thing... by gorzek · 2012-03-12 08:23 · Score: 2
  
  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.)
  
  --
  Check out my world simulator thingy.
31. Re:The most needed thing... by gorzek · 2012-03-12 08:26 · Score: 1
  
  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.)
  
  --
  Check out my world simulator thingy.
32. Re:The most needed thing... by i_ate_god · 2012-03-12 08:27 · Score: 2
  
  like python and postgresql?
  
  --
  I'm god, but it's a bit of a drag really...
33. Re:The most needed thing... by Anonymous Coward · 2012-03-12 08:36 · 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.
34. Re:The most needed thing... by spasm · 2012-03-12 09:03 · Score: 2
  
  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 to help you document your software, and give the programmers one central location to look at from time to time to correct and update the documentation based on what changes have been made to the code.
35. Re:The most needed thing... by serviscope_minor · 2012-03-12 09:06 · Score: 2
  
  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 my well not be experts at GUI design, however...
  Because of the "scratch your own itch" nature of OSS, GUI improvements that make the workflow of the person hacking the GUI worse are unlikely to be accepted easily. One thing programmers are unlikely to do is make their own life worse voluntarily.
  Likewise, changes which make the GUI more similar/consistent with other existing programs and systems may well be met with hostility. This is especially so if the programmers and users are more familiar with the system being changed. Doubly so if it's an old program. An example of such (not that anyone's tried to change it) is xfig which has a rather unusual mode of operation, but is efficient when you know how to use it and predates modern conventions.
  The other problem is that if you design (rather than program) the GUI, then you need someone else to do the implementation. Even if the design is excellent, the other programmers simply might not have the time.
  
  --
  SJW n. One who posts facts.
36. Re:The most needed thing... by hendrikboom · 2012-03-12 09:18 · 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
37. Re:The most needed thing... by neokushan · 2012-03-12 09:28 · Score: 1
  
  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 any coder of any level can contribute and a master coder's "obvious" code can be completely obfuscated to a novice programmer. By giving a little insight into what the code is doing, along with why its doing it, can be a big help. I'm not saying you have to label every nook and cranny, over-commenting code can sometimes be worse than not commenting it at all, but if you're doing something reasonably complex, or implimenting a particular algorithm that isn't particularly obvious, just leave a note saying what it is.
  This is a pretty particular debate, as many would argue that if the code isn't self-explanatory/self-documenting then the code is bad, but I think there's more than enough room for a middle ground.
  
  --
  +1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
38. Re:The most needed thing... by tibit · 2012-03-12 09:49 · Score: 1
  
  I do the same. Many commits are small, sometimes few-liners if I'm hunting bugs and writing/updating tests.
  
  --
  A successful API design takes a mixture of software design and pedagogy.
39. Re:The most needed thing... by Elrond,+Duke+of+URL · 2012-03-12 10:18 · Score: 1
  
  That's a shame. My last big OSS project, Weasel Reader, 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 databases the program read. But, while the entry bar to begin using the program was low enough that you really didn't need *any* documentation, there were enough extra features and things that could have been explained better that a solid user's manual would have been great.
  I think part of the reason it never got done was that during the ten years, or so, that the program was a going concern I made a few proclimations that I would write a manual Real Soon Now. That may have put off others who might have been interested.
  Still, though I did have numerous patches submitted along with a number of translations, if somebody had offered to write a manual, I would have jumped at the opportunity and done everything in my power to make the job easier. In the end, though, nobody (including myself) stepped forward. It's definitely something I won't make the mistake of doing in my next OSS project.
  
  --
  Elrond, Duke of URL
  "This is the most fun I've had without being drenched in the blood of my enemies!"-Sam&Max
40. Re:The most needed thing... by csumpi · 2012-03-12 12:53 · 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.
41. Re:The most needed thing... by Anonymous Coward · 2012-03-12 13:11 · Score: 0
  
  I think the parent was paraphrasing GPs post.
42. Re:The most needed thing... by Anonymous Coward · 2012-03-12 13:22 · Score: 0
  
  Yeah that's great if you're paying for the contribution.
43. Re:The most needed thing... by spasm · 2012-03-12 14:11 · Score: 1
  
  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 entry (if I write and say I'm willing to help with documentation am I committing to doing something beyond what I have the time for?) is one of the other reasons I like wiki-based documentation from a contributor's point of view - it's easy to start off small, whether it's rewriting a few existing sentences to make something clearer, or documenting how to use one small feature, and then if you start feeling more ambitious (and especially if other people working on the project are making appreciative sounds about the contributions you're making), it's equally easy to start adding entire chapters or sections. I doubt I would have written back in the day to offer to write an entire manual for Weasel Reader, but I can completely imagine adding a section describing how a specific extra feature worked, or making some edits to the description of how to convert texts to make it a bit clearer for people with less computer savvy.
  Thanks again for writing Weasel - I for one definitely appreciated it.
44. Re:The most needed thing... by haemish · 2012-03-12 15:34 · 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 occasionally means that the tech writer is an idiot, but more often it means that my code isn't as clean as needed, and almost certainly has a clumsy UI.
45. Re:The most needed thing... by thesandtiger · 2012-03-12 16:04 · Score: 1
  
  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 navigational comments are great, IMO.
  
  --
  Since I can't tell them apart, I treat all ACs as the same person.
46. Re:The most needed thing... by jrumney · 2012-03-12 17:34 · Score: 1
  
  ....your patch is not in line with the "semi-pro-football club"'s ways or some other bullshit.
  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.
47. Re:The most needed thing... by smash · 2012-03-12 17:40 · Score: 1
  
  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.
  
  --
  I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
48. Re:The most needed thing... by pclminion · 2012-03-12 17:40 · Score: 1
  
  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 architecture itself provides most of the safety. On top of that, a rich set of unit tests provide confidence when making changes. Unit tests also serve as a kind of documentation in themselves, as they demonstrate use cases of specific modules and help to define what is and isn't expected to be valid. If you find it difficult to write meaningful unit tests at all, this itself is indicating deficiencies in design.
  Basic code comments are a matter of politeness to whoever comes next. Not putting in some reasonable comments is like giving that person a big fat finger. What other documentation you do have, must be accurate and relevant. I'm by no means discouraging comprehensive documentation, just pointing out that long-term maintainable software depends on a lot more than that.
49. Re:The most needed thing... by gparent · 2012-03-12 17:40 · Score: 1
  
  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)
50. Re:The most needed thing... by pclminion · 2012-03-12 17:53 · Score: 2
  
  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 languages. Masterful code is more like "read only code." It means exactly what it says, it looks elegant and simple (and in fact it is), HOWEVER, a novice isn't capable of writing it. If a novice attempted to do the same thing as the master, it might eventually work but it'll be a jumbled mess. The right ideas didn't pop into their thought processes in the right order, at the right times.
  Of course, not all code in the world has to meet the criteria for "masterful" status (nor is there any official such thing). There's tons of functional, important code which is difficult to comprehend. But to me, if I look at a piece of code and can't understand it, I usually blame the code, not myself.
  This is really, really important for new programmers to understand. If you go out there and grab the source to some massively popular open source project, chances are you're going to find a complete mess. Don't make the mistake of thinking it's because you're never going to be a good programmer -- the code might look incomprehensible because it IS incomprehensible. You don't have enough experience yet to really tell the difference!
51. Re:The most needed thing... by Elrond,+Duke+of+URL · 2012-03-12 18:55 · Score: 1
  
  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 have very little in the way of customization options for how the text is displayed. Considering that you spend 99% of your time in this mode of the app, you'd think it would receive a lot of the attention. Right now, I think that JReader is by far the best of the available apps (and it's OSS, too).
  When I started with GutenPalm/Weasel Reader, wikis weren't really available. Of course, 12 years later the Internet has changed a whole lot. For something like a reader I would most likely go with the wiki model for writing the manual... and probably collect some/most of it into a single document for use with the reader itself.
  Interestingly, there's still a handful of people who continue to use Weasel Reader. I hear from them from time to time. It certainly helps that they no longer make Palm devices for which I would need to test and/or update the code.
  
  --
  Elrond, Duke of URL
  "This is the most fun I've had without being drenched in the blood of my enemies!"-Sam&Max
52. Re:The most needed thing... by Anonymous Coward · 2012-03-12 20:43 · Score: 0
  
  I think I can see what did you do. You show up with a buch of documents and urged them to accpet them. But they did not. Maybe they asked you to rework them, maybe they simply refused.
  This is very common, and almost always wrong for many reasons:
  1. You (probably) did NOT ask beforehand if your help was wanted.
  2. You (again, probably) did NOT ask beforehand WHAT had to be done.
  3. You (positively) do NOT realize that you are adding burden to the project. Documentation has to be mantained along with the code.
  4. You (evidently) did NOT show any interest in adapting to the project. Just demanded that the project adapt to you.
  And, of course, there could be issues with the quality of your contribution, but this we cannot tell.
53. Re:The most needed thing... by Spugglefink · 2012-03-12 23:54 · 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 volunteers, mind you, but almost none of them can ever write worth a damn, and everything they try to do basically winds up being this stupid exercise in trying to make people feel good for helping when they're really just making even more work for the decent writers.
  What we're left with is a half-assed patchwork of partially complete docs mixed with all kinds of obsolete legacy cruft. It's a nightmare. Giving up on that was the smartest decision I ever made!
54. Re:The most needed thing... by tehcyder · 2012-03-13 01:42 · Score: 1
  
  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.
  
  --
  To have a right to do a thing is not at all the same as to be right in doing it
55. Re:The most needed thing... by datavirtue · 2012-03-13 07:47 · Score: 1
  
  Be sure you leave your home address and email address, and maybe even phone number, so people can contact you later about your shitty code, or perhaps deliver a dick punch.
  
  --
  I object to power without constructive purpose. --Spock
56. Re:The most needed thing... by Anonymous Coward · 2012-03-13 12:58 · Score: 0
  
  I've been documenting since 1988, (I'm from the technical side, but developed good documentation technique over the years), and agree with you. The comments that follow about writing tutorials and posting to your own website miss the point. The documentation with the original project should be good to begin with. No one wants to get a program and then spend an hour trying to find good tutorials on line for how to use it. I've tried using many open source programs that lacked documentation and lacked good tutorials etc on line and relied on the user to 'figure it out themselves' attitude. There is a bit of arrogance in some projects where they think people are dumb if they can't figure it out. I wrote the documentation to an on-line game (it was free, but not open source) that was very popular before it got bought out (by a big company) from the guy who had developed it for free (it then didn't make enough money so they shut it down). Another guy did the screen shots, so was a two man effort to do the documentation. My original screen shots weren't considered good enough, so he improved them. The developer of the game was amazed at what a great job we'd done and our doco became the 'official' documentation for the game. (We'd developed the documentation without telling the developer till after we'd finished). But, my experience with open source projects are similar to your own. Most of the developers complain about not having good documentation, but when you try to help, they seem to think that the stuff written by programmers (who can't write and leave a lot of nec. detail out) is good enough. Rewriting inadequate doco gets rejected as it hurts the programmers egos, even when the original doesn't make sense (obscurity abounds), and has major grammar problems etc.
My favourite is bug reports. by Anonymous Coward · 2012-03-12 06:34 · Score: 0

Especially bugs that the developer sees as not worth fixing, and the solution is to simply not use that feature.
Glad I could help.
Better options by Anonymous Coward · 2012-03-12 06:36 · Score: 0

GSoC (20% acceptance, considering the low SNR on applications, someone serious has a good chance)
Also, KDE SoC and Openhatch
And probably many others I dont know about
1. Re:Better options by Noughmad · 2012-03-12 06:55 · Score: 1
  
  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 mentoring side.
  
  --
  PlusFive Slashdot reader for Android. Can post comments.
2. Re:Better options by TheRaven64 · 2012-03-12 07:13 · Score: 1
  
  I've mentored a few GSoC students and among the ones I've mentored and the other ones on the same project, the best successes that we've seen have been people with a prior involvement with the project. The GSoC[1] really isn't long enough if you need to spend 2-3 weeks getting to know your way around the code. If you're serious about it, get involved with the project six months earlier, poke at the code, and send a couple of patches. Then you can actually accomplish something in the GSoC time.
  [1] Especially with its inflexibility with dates, meaning that non-US students often start a week or two later and have another week or two to go by the 'pens down' date.
  
  --
  I am TheRaven on Soylent News
3. Re:Better options by Anonymous Coward · 2012-03-12 07:16 · Score: 0
  
  A good idea and a few bug fixes give you a decent chance of entry
  Time commitments are present for sure, and I had participated last year
  Would have continued contributing to the project except one of the main devs is an asshole of epic proportions, but it did get me significant programming and open source experience and I do maintain the module that I developed.
Redial by Anonymous Coward · 2012-03-12 06:39 · Score: 0

I think the most important thing is to contribute to something you use and like. That’s how it is supposed to work. You add features / fix bugs that effect you, and everyone else benefits as well! Ever use a program and think “damn, I wish I could do whatever>”. That’s a good place to start.
The article touched on IRC and mailing lists, but I think it’s worth adding that a period of “just hanging out” is usually a good idea before going into contributor mode. Let people get to know you. Get to know the main people. Maybe it’s a den of politics that you don’t want any part of!
When you are ready to contribute something... I think it’s a good idea to ask in the channel/mailing list first. Maybe someone is already working on something similar. Maybe they have discussed the change before and decided against it. At the very least, it creates a kind of expectation that when you are done, it won’t just be ignored.
Not really low profile way to contribute just general advice.
Also, big time on sticking in the channel and helping other people out.
release day help outs by i.r.id10t · 2012-03-12 06:39 · Score: 3, 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.

--
Don't blame me, I voted for Kodos
A few easy ones by gmuslera · 2012-03-12 06:40 · Score: 4, 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)
1. Re:A few easy ones by houghi · 2012-03-12 07:15 · Score: 2
  
  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.
  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.
  Or if you have time, tell them why you like it, what you like and what you dislike. As long as it is constructive, it might end up in a newer version.
  The worst that could happen is that they disagree.
  
  --
  Don't fight for your country, if your country does not fight for you.
2. Re:A few easy ones by grumbel · 2012-03-12 07:28 · Score: 2
  
  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. This is of course a much bigger issue for text heavy apps.
  
  Doing themes, skins, plugins, macros, whatever is around it that is not specifically programming and could need less or different skills than programming.
  
  Same as for localizations, probably even more so. More stuff doesn't make a project better, it just means more stuff the maintainer has to worry about. The focus should thus be on making the existing stuff better, more smooth and more compatible, not just on making more of it.
  Case in point: Gtk3 themes, there are hundreds of them, yet none that replicates the old Clearlooks of Gtk2, which used to be the default in Ubuntu for quite some years. Most of the Gtk3 themes also lack polish and throw tons of errors. So while specific themes that replicate popular Gtk2 looks or a convert tool to make Gtk2 themes compatible with Gtk3 would be very valuable, just yet another mindlessly thrown together half-done theme really is not.
3. Re:A few easy ones by David+Gerard · 2012-03-12 08:14 · Score: 2
  
  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 :-)
  
  --
  http://rocknerd.co.uk
4. Re:A few easy ones by gmuslera · 2012-03-12 08:20 · Score: 1
  
  Could be dependant on the project (where its used, how much it varies with time, how hard or easy is to incorporate this collaborations, etc), both for translation and customization. If the collaborator feels that is something that is needed, for some cases don't even need to be integrated in the core product, even could be a separate download from his own page.
Test new releases on your platform by Anonymous Coward · 2012-03-12 06:41 · 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.
1. Re:Test new releases on your platform by cpu6502 · 2012-03-12 07:29 · Score: 1
  
  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).
  
  --
  My AC stalker: " I personally agree with your posts most of the time, but that won't keep me from modding you troll"
2. Re:Test new releases on your platform by Anonymous Coward · 2012-03-13 01:37 · Score: 0
  
  This latest version of Firefox doesn't work on my platform (XP with Pentium 3)
  Curious.. what are your other specs, and how fast is your P3? While I'm using a more current CPU than a P3, I am still running XP, and the latest version of Firefox runs on it just fine.
  
  Safari 4 refuses to work on my MacG5
  This isn't the same mac from last week, is it? Because you were already called out twice regarding Safari 4 being able to run on it.
  Oh wait, nevermind, it can't be the same mac. There's no way you have a G5 that is only two years old. For someone who hates Apple as much as you do, you sure seem to possess lot of their products.
Bug Reports by Anonymous Coward · 2012-03-12 06:41 · 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.
Open Source doesn't have bugs by Anonymous Coward · 2012-03-12 06:44 · Score: 0

If there was a bug, someone would fix it. Therefore Open Source does not have bugs. This article is Microsoft FUD.
1. Re:Open Source doesn't have bugs by Dexter+Herbivore · 2012-03-12 06:56 · Score: 1
  
  I have a tinfoil hat that you can borrow.
2. Re:Open Source doesn't have bugs by CBravo · 2012-03-12 07:16 · Score: 2
  
  Actually the message is coming from inside. That's where the chip is.
  
  --
  nosig today
Also... by SomePgmr · 2012-03-12 06:48 · 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. ;)
1. Re:Also... by Anonymous Coward · 2012-03-12 08:08 · Score: 0
  
  Like when you've got cancer?
New feature review by greg1104 · 2012-03-12 07:00 · Score: 4, 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 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 by Compaqt · 2012-03-12 07:01 · Score: 1

-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.

--
I'm not a lawyer, but I play one on the Internet. Blog
1. Re:Why I hesitate by Anonymous Coward · 2012-03-12 07:30 · Score: 0
  
  There's the perfect place to help with documentation. The ideal, optimal perfect place ot help with documentation. There's not a documetn well written.
2. Re:Why I hesitate by David+Gerard · 2012-03-12 08:16 · Score: 4, Informative
  
  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
3. Re:Why I hesitate by tqk · 2012-03-12 08:31 · Score: 1
  
  -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 the re-install. You'll also have a great deal more disk to play with.
  Then again, if your box is $honking_big_powerful, VMs are the way to go these days. I prefer two separate boxes, but YMMV.
  BTW, Debian (for instance) prefers contributors to send bug reports related to "Testing" and "Unstable", not "Stable", as often the bug will already be fixed in stable and stable's not open to feature fixes (other than security updates), so run stable on Prod. and testing on Dev.
  I've also just shown up out of the blue with fixes to documentation, and they were welcomed. The projects were run by non-English foreign speakers who were trying their best with English, but having a native English person polish their work was very much appreciated. It made them look more professional to us English speaking slobs.
  
  --
  "Tongue tied and twisted, just an Earth bound misfit ..." -- Pink Floyd.
4. Re:Why I hesitate by grumbel · 2012-03-12 10:17 · Score: 3, 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/" ./configure --prefix=$PREFIX 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.
5. Re:Why I hesitate by allo · 2012-03-13 01:35 · Score: 1
  
  just use a chroot, or maybe even lxc.
  debootstrap is a great helper there, too.
Rock Star Programmers? by davevr · 2012-03-12 07:12 · Score: 4, Insightful

Um... I guess you haven't seen much open source code... Rock stars are definately not required.
1. Re:Rock Star Programmers? by Anonymous Coward · 2012-03-12 09:18 · Score: 0
  
  Um... I guess you haven't seen much open source code... Rock stars are definately not required.
  I guess you haven't seen much Jamie Zawinsky!
Do it like most here on Slashdot by CheerfulMacFanboy · 2012-03-12 07:18 · Score: 0

Post inane drivel in the name of OPEN SOURCE. Oh wait, that's how not to do it.

--
Fandroids hate facts.
1. Re:Do it like most here on Slashdot by PerfectionLost · 2012-03-12 08:16 · Score: 1
  
  Do it like most here on Slashdot
  In your mom's basement, with your hand...
  Sorry couldn't resist.
Unix Philosophy by Anonymous Coward · 2012-03-12 07:19 · 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 by gedeco · 2012-03-12 07:22 · 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.
Oh my, no. by Esther+Schindler · 2012-03-12 07:35 · Score: 3, Insightful

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.
Bug replication by grumbel · 2012-03-12 07:36 · Score: 2

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.
Closed source as well by Anonymous Coward · 2012-03-12 07:46 · Score: 0

Many of the suggestions listed will work for closed source - which you may not want to do for philosophical reasons, but go towards improving it for every one.
Installers by SoftwareArtist · 2012-03-12 07:47 · Score: 2

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."
Things I do by David+Gerard · 2012-03-12 07:59 · Score: 4, 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.

--
http://rocknerd.co.uk
1. Re:Things I do by Anonymous Coward · 2012-03-12 13:48 · Score: 0
  
  I'm a sysadmin and totally not a coder.
  
  Sounds like an oxy-moron.
Artists and musicians needed a lot too. by jackpot777 · 2012-03-12 08:11 · Score: 1

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. Once you learn a few things about the game, you start posting hints and tips for other people on the forum and before you know it you're getting involved in multi-participant submissions and developing planets like you're Slartibartfast...

--
Shiny. Let's be bad guys...
Open Advice by hackertourist · 2012-03-12 08:35 · Score: 3, Informative

A recent /. story discussed the bookOpen Advice which is about finding ways to contribute. It's worth reading.
I wrote similar article 8 years ago by CountJoe · 2012-03-12 08:58 · Score: 2

Just wanted to add that I wrote a very similar article 8 years ago: ContributingToFOSS.
Documentation by minderaser · 2012-03-12 09:06 · Score: 2

I know I'm far from the first to say it, but write docs. Here's how.

cheers
Where to find help? by Anonymous Coward · 2012-03-12 09:21 · Score: 0

I have recently started a project, http://www.pmsapp.org and I am doing everything I can to get people to follow the project and help out.
I have fairly active bloggers blogging about the project, I am tweeting about it and I have it listed on freecode.
So far, a single person has offered to help, which is great, but a lot more help is needed to get the project flying.
Am I simply not doing enough updates on the project or is there something I have missed?
1. Re:Where to find help? by LaRainette · 2012-03-12 19:55 · Score: 1
  
  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.
Tickets by Dennis+Sheil · 2012-03-12 09:36 · 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, 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.
50 Ways to be a FOSSer by Anonymous Coward · 2012-03-12 09:47 · Score: 0

A group of FOSS developers and faculty interested in FOSS brainstormed a list of ways
that people (especially students) could get involved in FOSS projects.
http://xcitegroup.org/softhum/doku.php?id=f:50ways
Adopt a core library module by doom · 2012-03-12 10:05 · Score: 3, 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.
Hosting by Anonymous Coward · 2012-03-12 10:06 · Score: 0

Not every project has their own hosting, can host everything (proprietary files which need to be included, but can't be directly due to licensing), or are too big for common hosts like SourceForge. If you've got a bit of spare bandwidth, why not offer up a public mirror for them to use?
Support Forums by oyenamit · 2012-03-12 10:24 · Score: 1

I sometimes spend time answering questions at the Firefox support forum.
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 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 software application. IMO, this is an invaluable experience and insight for any programmer developing any kind of application.
What else is there? by chrismcb · 2012-03-12 10:52 · 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. 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?
1. Re:What else is there? by sidthegeek · 2012-03-12 15:40 · 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 by gravis777 · 2012-03-12 15:35 · Score: 1

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 hardware decoder (for the life of me, I can't remember what it was called, but I think it was made by Creative Labs). Anyways, other people had gotten most of the functionality working, but there were bugs in things such as Subtitle colors and positioning, being able to read multi-angle discs, and being able to read chapters on a disc. The code was there, but some was commented out because it had bugs in it, some had the code but was improperly implementing it, etc. I just played around with the code for a couple of days, fixed the issue, and submitted my patch back to the community. And I learned a lot about how DVD actually worked.
Granted, I couldn't write a GUI to save my life, databases scare me, and I don't know many of the newer languages. But tackling a bug here and there is usually not as hard as one might think. You don't have to go through ten million lines of code, just work on a couple of hundred lines for a menu or an event or something. Play with it and see what happens. Once you learn how it works, then you can start working on bugs. And put comments left and right in the code, so that others can easily code as well.
FLOSS Manuals and also doing good by Anonymous Coward · 2012-03-12 16:24 · Score: 0

Two thoughts:
1) check out FLOSS Manuals for creating documentation in a collaborative way
2) contribute to open source and do social good at the same time, check out http://socialcoding4good.org
Great apples to apples example by devleopard · 2012-03-12 19:14 · Score: 1

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.1 and 3.2, and a few articles related to 3.3 features - so unorganized and disjointed. Yeah, you can dig around on blogs and Stack Overflow, but saying it's "community supported" really doesn't cut it when you need to find a solid answer. Hell, most of the time when working on a Railo project I'll jump over to Adobe's documentation and hope that it's 100% compatible (most of the time it is).
That said, I think Railo is a great and in many ways superior product, especially in terms of performance and a few innovations, so I'm not bad mouthing as much as lamenting the fact that its documentation hasn't kept up with engineering.
So back to the original issue: I think great documentation is much more of a value add than adding new features, and this is an area where someone who may be good with ColdFusion but not Java (which is what all version of ColdFusion are written in) can help.

--
The best thing about a boolean is even if you are wrong, you are only off by a bit.
Build documentation or other useful material by Anonymous Coward · 2012-03-13 01:13 · Score: 0

I hear you,
yes open source does not mean open minded. By their nature projects are meritocracies, only those that show effort and quality are accepted as contributers. And Google is you friend.
That means you can build documentation, and tutorials w/o permission of the actual projects owners. I have done it at http://plan-b-for-openoffice.org/index. I build a documentation project with 1,000+ videos and did not even ask for permission. And recognition has come in form of links from the official project website and posts in forums that reference my material. If you do some terrific documentation Google will help people to find it. And if you are consistent and also work with the community in their forums, mailing lists, bug tracking system, then most of the times they'll come around and recognize you. If not you still did follow your passion, helped your favorite project become more popular and had a good time finding others that feel passionate about the same project.
Marketing by Conficio · 2012-03-13 03:47 · 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 projects home page (how often is the home page indecipherable
Then spread this knowledge on websites like http://wikipedia.org/ http://ohloh.net/ and others that catalog open source projects. this makes it easier for potential users to find the project and pinpoint if they want to use it.

--
Busy helping non technical users of OpenOffice.org - http://plan-b-for-openoffice.org/
complex testing by Conficio · 2012-03-13 03:53 · 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 reproducible). If you can run the test against different versions, to show a trend of improvement or not that is certainly helpful. If you can compare different (competing) projects that is helpful too. In the process you have a lot of interesting things to say and write about.

--
Busy helping non technical users of OpenOffice.org - http://plan-b-for-openoffice.org/
Be creative! by Anonymous Coward · 2012-03-13 03:58 · Score: 0

Generally, you can contribute in any way suited to your abilities! Do some graphic art, proofread, compose music, design icons, write documentation, edit the documentation so it's actually fun to read, write unit tests, compose a propaganda flyer, ... if you're a student, apply for Google Summer of Code-- you can write your own proposal, and nothing says it has to be about coding!