Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by Soulskill on 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?

16 of 120 comments (clear)

  1. The most needed thing... by Hydrian · · 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 · · 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 · · 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 utkonos · · 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.

    4. Re:The most needed thing... by JoeMerchant · · 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.

    5. Re:The most needed thing... by ProppaT · · 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."
    6. Re:The most needed thing... by Anonymous Coward · · 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.

    7. Re:The most needed thing... by nschubach · · 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.
    8. Re:The most needed thing... by petdance · · 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.

    9. Re:The most needed thing... by idontgno · · 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.
  2. A few easy ones by gmuslera · · 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)

  3. Also... by SomePgmr · · 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. ;)

  4. New feature review by greg1104 · · 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.

  5. Rock Star Programmers? by davevr · · Score: 4, Insightful

    Um... I guess you haven't seen much open source code... Rock stars are definately not required.

  6. Things I do by David+Gerard · · 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
  7. Re:Why I hesitate by David+Gerard · · 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