Forgot your password?
typodupeerror
Open Source Programming

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

Posted by Soulskill
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?
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • by Hydrian (183536) on Monday March 12, 2012 @02:32PM (#39329419) Homepage

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

    • by Dexter Herbivore (1322345) on Monday March 12, 2012 @02:36PM (#39329513) Journal
      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.
      • by nschubach (922175) on Monday March 12, 2012 @03:31PM (#39330329) Journal

        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.

        • by gorzek (647352)

          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

          • by pclminion (145572)

            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

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

        • by neokushan (932374)

          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

          • by pclminion (145572)

            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

        • 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

      • by idontgno (624372) on Monday March 12, 2012 @03:56PM (#39330655) Journal

        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.

        • by Anonymous Coward

          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.

    • by TheRaven64 (641858) on Monday March 12, 2012 @02:41PM (#39329589) Journal

      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.

      • by Auroch (1403671)

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

        • by cpu6502 (1960974)

          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)

            by Esther Schindler (16185) <esther@bitranch.com> on Monday March 12, 2012 @03:35PM (#39330377) Homepage
            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.
          • by petdance (2588887) on Monday March 12, 2012 @03:51PM (#39330581) Homepage

            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.

            • by AdrianKemp (1988748) on Monday March 12, 2012 @03:56PM (#39330649)

              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

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

            • by gorzek (647352)

              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

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

          • by tehcyder (746570)

            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.

    • by baenpb (1343241)
      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!"
      • by JoeMerchant (803320) on Monday March 12, 2012 @02:59PM (#39329863) Homepage

        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.

        • by Anonymous Coward on Monday March 12, 2012 @03:24PM (#39330217)

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

        • by csumpi (2258986)

          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.

          • by jrumney (197329)

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

      • by cpu6502 (1960974)

        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.

      • by gorzek (647352)

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

    • by jank1887 (815982)

      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

    • by utkonos (2104836) on Monday March 12, 2012 @02:58PM (#39329843)
      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.
      • 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.

      • by tibit (1762298)

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

        • by gorzek (647352)

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

          • by tibit (1762298)

            I do the same. Many commits are small, sometimes few-liners if I'm hunting bugs and writing/updating tests.

      • by Xtifr (1323)

        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

    • by Hentes (2461350)

      True, but stuff should be documented by the people who wrote it, they are the ones who know how it works.

      • by tuffy (10202)
        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" [folklore.org] documentation is one such example.
      • 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.
    • by ProppaT (557551) on Monday March 12, 2012 @03:03PM (#39329919) Homepage

      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.

      • by oneiros27 (46144)

        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

        • by gparent (1242548)

          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)

      • by AdrianKemp (1988748) on Monday March 12, 2012 @04:03PM (#39330733)

        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.

      • by spasm (79260)

        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

        • 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

          • by spasm (79260)

            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

            • 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

      • 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

      • by haemish (28576) *

        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

    • by kefkahax (915895)
      Thanks! Write documentation, help with technical support and educate your friends on why open source is important. We'll love you long time, baby!
    • 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

    • by smash (1351)

      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.

    • 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

  • by i.r.id10t (595143) on Monday March 12, 2012 @02:39PM (#39329553)

    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)

    by gmuslera (3436) * on Monday March 12, 2012 @02:40PM (#39329561) Homepage Journal

    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)

    • by houghi (78078)

      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

      • 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 :-)

    • by grumbel (592662)

      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

      • by gmuslera (3436) *
        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.
  • by Anonymous Coward on Monday March 12, 2012 @02:41PM (#39329583)

    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.

    • by cpu6502 (1960974)

      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)

    by Anonymous Coward on Monday March 12, 2012 @02:41PM (#39329593)

    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.

  • Also... (Score:5, Insightful)

    by SomePgmr (2021234) on Monday March 12, 2012 @02:48PM (#39329711) Homepage

    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)

    by greg1104 (461138) <gsmith@gregsmith.com> on Monday March 12, 2012 @03:00PM (#39329879) Homepage

    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.

  • -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)

      by David Gerard (12369) <slashdotNO@SPAMdavidgerard.co.uk> on Monday March 12, 2012 @04:16PM (#39330873) Homepage

      LibreOffice, however, has a collection of easier fixes [documentfoundation.org] specifically to lure people in. And it works. Every project should do this.

    • by tqk (413719)

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

      by grumbel (592662) <grumbel@gmx.de> on Monday March 12, 2012 @06:17PM (#39332465) Homepage

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

      • by allo (1728082)

        just use a chroot, or maybe even lxc.
        debootstrap is a great helper there, too.

  • by davevr (29843) on Monday March 12, 2012 @03:12PM (#39330047) Homepage
    Um... I guess you haven't seen much open source code... Rock stars are definately not required.
  • Unix Philosophy (Score:3, Interesting)

    by Anonymous Coward on Monday March 12, 2012 @03:19PM (#39330151)

    I had written a Python script consisting of about a couple of hundred lines of code (including comments) for a task I do on a regular basis. I've been meaning to add features to it but haven't touched the code for over a year because to be honest, although I had structured it into proper functions/procedures only doing one task and group similar code into packages and had commented it, it was still a bit of a mess.

    I recently stumbled upon the Unix philosophy and it gave me a different perspective on how to program. I think the biggest eye-opener for me was the concept of connecting a number of small programs via streams to make larger programs. I've done this many times by for instance by piping the contents of find through grep to find a piece of text in a number of files but it did not occur to me that this could be used in programming. The implication is that rather than writing a lot of code, it could be easily done in a lot less lines by calling an existing program and putting the output into a data structure to be used by the program.

    I've been googling more about the Unix philosophy and I have tried to apply it to the Python script I had written. The things that stood out was writing a program that did one thing well and prototyping to get the program working then refining afterwards. I've had a look at my code and see a lot of functions and procedures that do a number of tasks. An example of this was one that was extracting data from a data structure and putting it into a pyGTK treestore. I had separated this and redesigned a new function to extract the data so that it outputs text to the function that puts it into the one which populates the pyGtk TreeStore. A useful thing about this is that it is easier to pull the code from this and insert it into other programs if I wish. As well as this, I am looking at other ways to make the code easier to debug and to add extra functionality.

    I think a lot of the Unix philosophy is common sense and I'm sure it is second nature to experienced programmers but to casual coders like myself, it is a number of guidelines that points me in the right direction.

  • Obviously some users need support.
    If you are good at troubleshooting, this is the way to go.
    Good troubleshooting has also value for the programming rockstars.

  • by grumbel (592662) <grumbel@gmx.de> on Monday March 12, 2012 @03:36PM (#39330401) Homepage

    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.

  • by SoftwareArtist (1472499) on Monday March 12, 2012 @03:47PM (#39330521)

    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)

    by David Gerard (12369) <slashdotNO@SPAMdavidgerard.co.uk> on Monday March 12, 2012 @03:59PM (#39330673) Homepage

    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.

  • 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)

    by hackertourist (2202674) <hackertourist&xmsnet,nl> on Monday March 12, 2012 @04:35PM (#39331141)

    A recent /. story discussed the bookOpen Advice [open-advice.org] which is about finding ways to contribute. It's worth reading.

  • Just wanted to add that I wrote a very similar article 8 years ago: ContributingToFOSS [berkshirelug.org].
  • I know I'm far from the first to say it, but write docs. Here's how. [linuxisit.com]

    cheers
  • With regards to the ticketing system - if someone posts a ticket for a problem, see if you can reproduce the problem with their particular version. See if the problem still exists in the head of the latest code trunk. See if the problem is a duplicate of another problem. See if the problem is with the program, or somewhere upstream, say, a library that the program depends on. If so, report the problem upstream.

    Core developers are busy, and most projects can use people who deal with and clean up tickets,

  • by doom (14564) <doom@kzsu.stanford.edu> on Monday March 12, 2012 @06:05PM (#39332327) Homepage Journal

    "What's your favorite low-profile way to contribute?" Well, since you're asking...

    Something that's been on my "todo" list for ages is to volunteer to maintain some of the modules in the core perl library. That's something that any solid perl programmer ought to be able to help with (even if your C skills aren't well tuned-up at present), and I've been told that there's a shortage of people willing to do it.

    Writing documentation is a great idea too, of course, but while the perl docs can always use some work, they're actually pretty good compared to some other projects. Perl programmers seem to like to write things down.

    Andy Lester himself is famous for being willing to write test code. That's a good way to go, of course: there are still some big projects out there that barely have any tests.

  • I sometimes spend time answering questions at the Firefox support forum [mozilla.org].
    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
  • 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?

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

  • 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

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

  • 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

  • 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

The opposite of a correct statement is a false statement. But the opposite of a profound truth may well be another profound truth. -- Niels Bohr

Working...