Well I am not a programmer and I don't really want to be, it's just too messy for me. But I try to promote FOSS when and wherever I can - installed a few Ubuntu's on a few friend's pc's that were using Windows. Now they are more than satisfied customers. Also heavily using open source apps and try to make some helpful suggestions whenever I can to at least improve the product a bit like that.
If you think that proprietary code is more understandable than open source code you have probably been very lucky in what companies you have worked for. My impression is that at least the major open source projects have better code. That said, the quality varies a lot and we should certainly try to lower the barriers to contributing as much as possible.
People need to learn that code is FIRST a story about how something works that is meant to be read by another human being. Only SECOND is it instructions to the computer.
Well, I'm not experienced C programmer although I understand it well. The problem is not only with knowing C as it is getting familiar with the codebase. Not often but sometimes I'm forced to dive into a source because of an API break and to chase the function that replaced the deprecated one. Usually the maintainer of that code is working on a patch but when you try to revive an abandoned peace of code that wasn't worked on for a long time - then you're in a world of problems. Poorly documented source with no comments or useless ones, chasing wich header to include that provides the function you need etc...
So I'm doing what I can do - beta testing. Not for distributions - cause I'm no distrohopper, I use Arch because it's vanilla as it gets and pretty close to upstream. I'm always lurking for regressions for Intel IGP's in the kernel and X and I'm always using the RC's. That's not an easy job also, cause sometimes bugs are difficult to trigger manualy and can't be reproduced that easily, so bisecting can be difficult or almost imposible.
Great documentation is what every programmer needs, if there isn't one available, well the project is the one that suffers...
Well, what it takes for me to contribute is to have an itch, like ESR says. If there's something bothering me enough in something that I use, that's reason enough to fix it and send upstream.
So far I haven't come against a legal waiver, but I guess that would stop me. A language isn't that much a barrier, nor is code quality.
I agree that if you have working code, it's likely to get accepted even if it isn't (yet) beautiful.
With that mindset, only software that bothers people will get contributions. Usually, software the bothers people ends up not being used rather than getting contributions...
Originally Posted by curaga
I lack focus in every aspect of life, limiting my progress in learning to code and how likely I am to participate. I'm also not much of a 'team player'. I file bug reports and occasionally sift through a source tarball or two, to make my bug reports an easier and more likely fix.
I also occasionally find myself adopting the circular logic that I don't file/fix bugs/feature requests because I don't use the application and I don't use the application because of bug/missing feature X.
By far the biggest barrier, however, is all the signing up and navigating my way around often awkward bugzilla/trac sites. It's the same reason I pirate media and still go to actual stores, rather than use ebay/steam/etc. The project I've contributed the most to (Pragha), happens to be one that just uses a wiki for keeping track of bugs and feature requests. While such a scheme wouldn't work for a popular project, being able to just jot down my complaints/ideas casually, has been great.
I used to contribute to many projects but just don't have the time anymore. Kids, work, sleep, etc.
Me neither. That's why I don't code on FOSS projects, but instead translate the GUI, keep some of their Wikipedia entries up to date, report bugs, etc.
Originally Posted by LinuxID10T
On average, I spend only a few minutes per day on FOSS contributions. That's not much, but it adds up if done somewhat regularly.
I've tried to contribute a few times to the KDE project and I have found the following:
1) Its like trying to jump onto a moving train. A fast moving train. On the one occasion I managed to complete a patch, the patch was already obsolete by the time I submitted it!
2) Time. It may be distasteful to many people here, but I work full time as a Windows developer. I don't get that much time to contribute.
3) I'd love to move to a company that worked with opensource technologies - but its a chicken and egg situation: I can't get an opensource job because I don't have the experience (at least on my CV), and I can't get the experience because my current employer would not even consider open source technologies. I have to confess that part of my motivation for trying to contribute to KDE was to get some stuff to put on my CV, as well as to become more familiar with Qt and associated technologies.
P.S. First post :-D