Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

Soulskill posted more than 2 years ago | from the step-one-become-a-programming-rock-star dept.

Open Source 120

Esther Schindler writes "Plenty of people want to get involved in open source, but don't know where to start. In this article, Andy Lester lists several ways to help out even if you lack confidence in your technical chops. Here are a couple of his suggestions: 'Maintenance of code and the systems surrounding the code often are neglected in the rush to create new features and to fix bugs. Look to these areas as an easy way to get your foot into a project. Most projects have a publicly visible trouble ticket system, linked from the front page of the project’s website and included in the documentation. It’s the primary conduit of communication between the users and the developers. Keeping it current is a great way to help the project. You may need to get special permissions in the ticketing system, which most project leaders will be glad to give you when you say you want to help clean up the tickets.'" What's your favorite low-profile way to contribute?

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


The most needed thing... (5, Insightful)

Hydrian (183536) | more than 2 years ago | (#39329419)

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

Re:The most needed thing... (4, Informative)

Dexter Herbivore (1322345) | more than 2 years ago | (#39329513)

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.

Re:The most needed thing... (4, Insightful)

nschubach (922175) | more than 2 years ago | (#39330329)

I don't know if I agree with the premise.

Ideally, IMHO, code comments will tell you 'Why' you chose to do something instead of what is being done. If I wanted to know what is being done, I'd read the code. If I want to know why they chose to split the array instead of slicing it (arbitrary example)... that's what comments are for. For someone to come in and make a comment on why some algorithm was chosen over another is like trying to read minds.

Re:The most needed thing... (1)

gorzek (647352) | more than 2 years ago | (#39330813)

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.

Re:The most needed thing... (1)

neokushan (932374) | more than 2 years ago | (#39331867)

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.

Re:The most needed thing... (1)

thesandtiger (819476) | more than 2 years ago | (#39335487)

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.

Re:The most needed thing... (4, Insightful)

idontgno (624372) | more than 2 years ago | (#39330655)

Even simple in-code comments help cut down the time required to understand the thought process behind the code.

Developer docs are sorely needed, true, in many projects. But to my mind, the more grating lack is USER documentation. You know, decent manuals on how to use the software. No amount of commenting code will ever help with that, and I suspect is the area where non-developer contributors can help out the most.

Re:The most needed thing... (1)

Anonymous Coward | more than 2 years ago | (#39331149)

Speaking as somebody who has contributed documentation toi a few projects, it's extremely difficult for someone without the
requisite chops to write end user documentation unless they spend an inordinate amount of time distilling
the mailing list archives. Even so, that method is inadequate since not every feature is discussed on list and
the implementations of those that do may differ from what was discussed on the list.
Shitty attitudes from coders doesn't help either.

Re:The most needed thing... (5, Informative)

TheRaven64 (641858) | more than 2 years ago | (#39329589)

Shame you're posting at 0. If you aren't a great coder, read some existing code and document what it does. If you don't understand it, probably the next person along won't either. Find the person who wrote it and get them to give you a quick explanation, then write up that explanation in more details. Add doxygen comments. This is also a great way of learning a new codebase. If you think something is wrong, ask - you may have just spotted a bug.

Beyond that, look at the bug tracking system. See if you can reproduce bugs. If you can, try to produce a reduced test case. Detailed bug reports are incredibly valuable. Taking a bug report that says 'foo doesn't work' and saying 'when given X input, foo crashes with this stack trace. Valgrind output is {attached}. Problem appears to be in bar.c, but I don't know enough to fix it.' is amazingly valuable. Even just looking at the bugs, working out which person is most likely to be able to fix it, and making sure that they are aware of the bug is helpful. One of the best things about LLVM's development model is that when someone files a bug related to my code it gets assigned to me quickly, so I don't have to spend any time reading bug reports - ones I am likely to be able / wiling to fix are emailed to me automatically. This only happens because people are paid to do it. On other projects, volunteers who are willing to do this (tedious) work are worth their weight in gold.

Re:The most needed thing... (1)

Auroch (1403671) | more than 2 years ago | (#39329621)

See if you can reproduce bugs. If you can, try to produce a reduced test case. Detailed bug reports are incredibly valuable. Taking a bug report that says 'foo doesn't work' and saying 'when given X input, foo crashes with this stack trace. Valgrind output is {attached}. Problem appears to be in bar.c, but I don't know enough to fix it.' is amazingly valuable.

This is great advice for the non-technical QA / User Experience Tester. Someone who likes IT, but can't be bothered to learn can stack their resume by contributing in this manner (and let the real workers get to it...)

Re:The most needed thing... (1)

cpu6502 (1960974) | more than 2 years ago | (#39330153)

You can list "Uncovered and documented bugs on Firefox" on your resume? I thought only paid work experience applied.

Oh my, no. (3, Insightful)

Esther Schindler (16185) | more than 2 years ago | (#39330377)

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.

Re:The most needed thing... (5, Insightful)

petdance (2588887) | more than 2 years ago | (#39330581)

You can list "Uncovered and documented bugs on Firefox" on your resume? I thought only paid work experience applied.

You can put anything on your resume that you want. There is no Resume Police. You should put on your resume anything that will make the reader say "Hey, I need to bring this person in for an interview." Conversely, you should not put anything on your resume that does NOT make the reader say that. Your two summers at McDonald's? Don't bother, even though it's paid work experience. Blog post on the topic: Should I put _____ on my resume? [petdance.com] .

With any experience on a resume, you'll want to quantify it as much as possible. Compare: "Uncovered and documented bugs on Firefox" with "Uncovered and documented 47 bugs in Firefox over a six month period." The latter gives the reader a better idea what it is you've done. More on using numbers in your resume: Numbers and resumes [petdance.com] .

Where did you get the idea that it could only be paid experience? Did something tell you that? If so, I'd love to find out what book or blog told you so that I can bookmark it as bad advice.

Re:The most needed thing... (3, Informative)

AdrianKemp (1988748) | more than 2 years ago | (#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

Re:The most needed thing... (2)

David Gerard (12369) | more than 2 years ago | (#39330759)

Or, to put it another way, employers love someone who shows actual evidence they will work for their pay without being a whiny little bitch with first-world problems.

Re:The most needed thing... (1)

gorzek (647352) | more than 2 years ago | (#39330895)

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.

Re:The most needed thing... (1)

David Gerard (12369) | more than 2 years ago | (#39330709)

I wrote large chunks of the Mozilla 1.0 FAQ [mozilla.org] . You bet I listed it on my CV. This is back when no-one outside open-source circles had heard of it and IE's usage was 96%.

Re:The most needed thing... (2)

baenpb (1343241) | more than 2 years ago | (#39329605)

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!"

Re:The most needed thing... (4, Interesting)

JoeMerchant (803320) | more than 2 years ago | (#39329863)

Yeah, man, like we're a semi-pro-football club, members have all been playing for 10+ years and we've all been on the team together for 3 or more, and there's lots of people who want to play with us because we totally kick ass, and man like, thanks for showing up, you know, why don't you start off our next game?

If you want to contribute code quickly, think about joining a smaller project, or even reviving an interesting looking dead one.

If you want to be a part of something big and high profile, be prepared to work the bottom of the bug list, or do some documentation.

Re:The most needed thing... (5, Insightful)

Anonymous Coward | more than 2 years ago | (#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.

Re:The most needed thing... (2)

csumpi (2258986) | more than 2 years ago | (#39334155)

Attitude like yours is probably why many programmers are deterred from contributing.

I mean nothing like submitting a patch that you worked hard on, tested, documented, just to be completely ignored. Or being told that you are a moron, your patch is not in line with the "semi-pro-football club"'s ways or some other bullshit.

Re:The most needed thing... (0)

Anonymous Coward | more than 2 years ago | (#39334307)

I think the parent was paraphrasing GPs post.

Re:The most needed thing... (0)

Anonymous Coward | more than 2 years ago | (#39330099)

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.

Re:The most needed thing... (1)

cpu6502 (1960974) | more than 2 years ago | (#39330395)

Testing and documenting the flaws isn't that bad. It frees you up to listen to news, college lectures, or audiobooks (since testing doesn't require a lot of mental concentration). And if you are getting paid 50-60 an hour, the testing is even less of a chore.

Re:The most needed thing... (2)

gorzek (647352) | more than 2 years ago | (#39330971)

Welcome to the rest of the software industry. Guess what "junior" developers are hired to do? They get stuck with the crap no one else wants to bother with, and once they prove themselves, they get to move up the food chain (either within the company, or having gained enough experience to bail for a better job.)

Re:The most needed thing... (0)

Anonymous Coward | more than 2 years ago | (#39334383)

Yeah that's great if you're paying for the contribution.

Re:The most needed thing... (2)

jank1887 (815982) | more than 2 years ago | (#39329697)

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.

Re:The most needed thing... (4, Insightful)

utkonos (2104836) | more than 2 years ago | (#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.

Re:The most needed thing... (1)

AdrianKemp (1988748) | more than 2 years ago | (#39330595)

It's because so few people use versioning systems as versioning systems. Many use it as a method for control first and everything else a distant second.

Not that there's anything wrong with exerting control over a repository, it's just silly that it tends to come at the cost of actually using the functionality of a repository.

Re:The most needed thing... (2)

tibit (1762298) | more than 2 years ago | (#39330623)

Avoiding repository churn is an euphemism for being change averse as a way of life, no matter what. It's a negative personality trait. I wouldn't loudly proclaim it.

I mean, what the heck, do they worry that they'll overflow the revision counter in subversion of something? What kind of idiocy is that ... I'm glad nobody has ever told me not to submit something just to prevent "repository churn". I hope it's not some wider-reaching phenomenon...

Re:The most needed thing... (1)

gorzek (647352) | more than 2 years ago | (#39331021)

I commit frequently. I'm a bit perturbed by people who don't.

(Of course, I use git, so I can do local commits as often as I want, and only push when I'm confident what I'm sharing isn't a broken mess.)

Re:The most needed thing... (1)

tibit (1762298) | more than 2 years ago | (#39332147)

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

Re:The most needed thing... (1)

Xtifr (1323) | more than 2 years ago | (#39330899)

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 [chronicle.com] 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. :)

Re:The most needed thing... (1)

Hentes (2461350) | more than 2 years ago | (#39329877)

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

Re:The most needed thing... (1)

tuffy (10202) | more than 2 years ago | (#39330293)

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.

Re:The most needed thing... (1)

BattleApple (956701) | more than 2 years ago | (#39330811)

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.

Re:The most needed thing... (5, Informative)

ProppaT (557551) | more than 2 years ago | (#39329919)

I think this is everyone's biggest issue with Open Source. It also seems to be the "least wanted" by programmers working on the projects.

As a professional tech writer, I've offered my services to a few open source projects that I'm a fan of but feel have a major lack of documentation. In each case I've been rejected. I've basically been told, "Our programmers write all of our documentation." The existing documentation in each case might as well say "just figure it out." I've offered GUI design in the past as well. Lets just say this didn't go over well at all.

It seems that Open Source is a programmers club more than anything. It's a real shame. There's so much talented work going into the development of the software that it would be nice if the rest of the work (documentation, gui design, graphic design, etc) was doled out to the experts. There's nothing wrong with admitting that you're not super talented at everything.

Re:The most needed thing... (1)

oneiros27 (46144) | more than 2 years ago | (#39330469)

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.

Re:The most needed thing... (3, Insightful)

AdrianKemp (1988748) | more than 2 years ago | (#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.

Re:The most needed thing... (2)

spasm (79260) | more than 2 years ago | (#39331507)

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.

Re:The most needed thing... (1)

Elrond, Duke of URL (2657) | more than 2 years ago | (#39332475)

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

Re:The most needed thing... (1)

spasm (79260) | more than 2 years ago | (#39334711)

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.

Re:The most needed thing... (2)

serviscope_minor (664417) | more than 2 years ago | (#39331545)

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.

Re:The most needed thing... (1)

haemish (28576) | more than 2 years ago | (#39335291)

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.

Re:The most needed thing... (1)

kefkahax (915895) | more than 2 years ago | (#39330339)

Thanks! Write documentation, help with technical support and educate your friends on why open source is important. We'll love you long time, baby!

Re:The most needed thing... (1)

hendrikboom (1001110) | more than 2 years ago | (#39331715)

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

My favourite is bug reports. (0)

Anonymous Coward | more than 2 years ago | (#39329459)

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

Anonymous Coward | more than 2 years ago | (#39329505)

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

Re:Better options (1)

Noughmad (1044096) | more than 2 years ago | (#39329807)

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.

Re:Better options (1)

TheRaven64 (641858) | more than 2 years ago | (#39330063)

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.

Re:Better options (0)

Anonymous Coward | more than 2 years ago | (#39330101)

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.

This post... (-1)

Anonymous Coward | more than 2 years ago | (#39329539)

... is relevant to my interests.

Redial (0)

Anonymous Coward | more than 2 years ago | (#39329545)

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 (3, Interesting)

i.r.id10t (595143) | more than 2 years ago | (#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 (4, Informative)

gmuslera (3436) | more than 2 years ago | (#39329561)

Localization is always needed, either correcting, improving or adding translations for an open source project.

Doing themes, skins, plugins, macros, whatever is around it that is not specifically programming and could need less or different skills than programming.

Also actually using it and being vocal about that fact, the social component make people aware that exist that software, that have users that you know, and that there is a point of contact with the community behind it.

Documentation, and everything around documentation (i.e. putting in your blog or in a comment how to do x with that software)

Re:A few easy ones (2)

houghi (78078) | more than 2 years ago | (#39330075)

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.

Re:A few easy ones (2)

David Gerard (12369) | more than 2 years ago | (#39330853)

What is needed is people who know nothing to do beta-testing. Sure, feedback is appreciated from people who know how to code, what is needed is feedback from those pesky users.

This. Get in there and break shit.

Or even just a 'thank you' to the makers, so the makers will be motivated to go on. An email saying something like "Thanks for making this program. Keep up the good work. I really like it." will be great to programmers.

And this. Debian reportbug even has a "--kudos" option for the purpose :-)

Re:A few easy ones (2)

grumbel (592662) | more than 2 years ago | (#39330263)

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.

Re:A few easy ones (1)

gmuslera (3436) | more than 2 years ago | (#39330927)

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 (3, Interesting)

Anonymous Coward | more than 2 years ago | (#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.

Re:Test new releases on your platform (1)

cpu6502 (1960974) | more than 2 years ago | (#39330283)

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 (3, Interesting)

Anonymous Coward | more than 2 years ago | (#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.

Open Source doesn't have bugs (0)

Anonymous Coward | more than 2 years ago | (#39329653)

If there was a bug, someone would fix it. Therefore Open Source does not have bugs. This article is Microsoft FUD.

Also... (5, Insightful)

SomePgmr (2021234) | more than 2 years ago | (#39329711)

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

Re:Also... (0)

Anonymous Coward | more than 2 years ago | (#39330791)

Like when you've got cancer?

New feature review (4, Insightful)

greg1104 (461138) | more than 2 years ago | (#39329879)

Speaking as someone who contributes to PostgreSQL, one of the projects mentioned in TFA, the easiest way to contribute something useful to that project while having some fun too is to test out new features. Reviewing a patch [postgresql.org] that hasn't been committed yet is part of the community process for validating what features get committed. And testing recently committed features is useful too, to help flush out bugs in them before release. Working on new features seems to be more attractive to new contributors than trying to fix old problems, and good reviewing skills flow naturally into becoming a code contributor too.

Why I hesitate (1)

Compaqt (1758360) | more than 2 years ago | (#39329903)

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

Anonymous Coward | more than 2 years ago | (#39330295)

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.

Re:Why I hesitate (1)

tqk (413719) | more than 2 years ago | (#39331093)

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

Re:Why I hesitate (3, Informative)

grumbel (592662) | more than 2 years ago | (#39332465)

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

Then when you want to compile/run anything depending on the installed library:

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.

Just be a fanboi (-1)

Anonymous Coward | more than 2 years ago | (#39330019)

Make your contribution by talking up how great Linux/Android/Raspberry Pi is without ever using them. You'll get modded up and you can use your mod points to mod up other Open Source gurus who've obviously never used the software.
For bonus points you can rant against free markets even if the market you're discussing is heavily regulated by the federal government. People around here just love that kind of crap.

Rock Star Programmers? (4, Insightful)

davevr (29843) | more than 2 years ago | (#39330047)

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

Re:Rock Star Programmers? (0)

Anonymous Coward | more than 2 years ago | (#39331703)

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!

Unix Philosophy (3, Interesting)

Anonymous Coward | more than 2 years ago | (#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.

Support (2)

gedeco (696368) | more than 2 years ago | (#39330195)

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.

"Programming"? (-1)

Anonymous Coward | more than 2 years ago | (#39330261)

Rock Stars sell iPhones.

Hermits write code.

Bug replication (2)

grumbel (592662) | more than 2 years ago | (#39330401)

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

Anonymous Coward | more than 2 years ago | (#39330505)

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

SoftwareArtist (1472499) | more than 2 years ago | (#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 (4, Informative)

David Gerard (12369) | more than 2 years ago | (#39330673)

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.

Re:Things I do (0)

Anonymous Coward | more than 2 years ago | (#39334547)

I'm a sysadmin and totally not a coder.

Sounds like an oxy-moron.

Artists and musicians needed a lot too. (1)

jackpot777 (1159971) | more than 2 years ago | (#39330809)

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 involved in multi-participant submissions [aegidian.org] and developing planets like you're Slartibartfast [aegidian.org] ...

Where to find help? (0)

Anonymous Coward | more than 2 years ago | (#39331739)

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?

Tickets (2)

Dennis Sheil (1706056) | more than 2 years ago | (#39331979)

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

Anonymous Coward | more than 2 years ago | (#39332123)

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.

Adopt a core library module (3, Informative)

doom (14564) | more than 2 years ago | (#39332327)

"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 (0)

Anonymous Coward | more than 2 years ago | (#39332349)

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

oyenamit (2474702) | more than 2 years ago | (#39332559)

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 software application. IMO, this is an invaluable experience and insight for any programmer developing any kind of application.

What else is there? (1)

chrismcb (983081) | more than 2 years ago | (#39332883)

Maintenance of code and the systems surrounding the code often are neglected in the rush to create new features and to fix bugs. Look to these areas as an easy way to get your foot into a project. Most projects have a publicly visible trouble ticket system

Maintenance of the code IS bug fixing, or adding a new feature to old code. From a programming standpoint, what else is there? What is in your trouble ticket system that is NOT a bug of a new feature?

Re:What else is there? (1)

sidthegeek (626567) | more than 2 years ago | (#39335329)

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

gravis777 (123605) | more than 2 years ago | (#39335301)

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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account