Are you using open source software for free? Do you wish you could contribute, but don’t have the time to learn how a new developer community works?
Giving cash donations is not necessarily the best way to give back to an open source community. Instead, try channeling any frustration you may feel with open source software and help with testing. It’s good for your blood pressure and good for the rest of the users of the code!
If you’re accustomed to commercial software, it’s easy to make the mistake of feeling entitled to perfection and cursing its absence, as you do with the proprietary software you may use. Maybe you go online and complain about bugs and crashes. Maybe you go looking for a way to shout at the developers. Neither are likely to result in a good outcome. Chipping in is vastly more productive.
Community motivations
Open source software is not a product. It's a shared commons of code developed collaboratively by the people who choose to participate. They choose to do so because of motivations outside the scope of the project -- usually, but not always, associated with employment and/or compensation.
I call these “extrinsic motivations.” While there will be a good-sized group of people whose extrinsic motivation is in fact philanthropy, most are not there for your benefit; they are serving those extrinsic motivations. If their extrinsic motivation happens to include “helping random strangers,” then you are in luck ... but don’t rely on it.
If you enter a community of open source collaborators and present them with demands unrelated to their motivations, you'll get nowhere fast. In fact, ranting about how terrible they are because they won't prioritize your personal needs will get you banned. However, if you can assist in their collaboration and make contributions that lead to them being more effective for less effort, you will gain influence and quite possibly get what you want.
I’ve found this approach worth my time in several projects. Unlike with proprietary software, where I can never remember seeing a bug I encountered fixed in response to my comments, actual results follow. I have frequently seen bugs I have documented to the best of my abilities fixed within a short time.
That’s because testing is often the red-headed stepchild in open source communities. While automated testing is now the norm -- especially as a part of a continuous build process -- even commercial developers can rarely test every combination of possible circumstances. That’s especially true of large projects and user-oriented projects.
For proprietary software, the only option is to suck it up and hope your vendor will fix problems with a future release. But with open source software, there’s another way: Become a tester instead of a user.
Ready, set, test
The key skill of a tester is not only to find bugs, it’s to report reproducible problems. Make sure every statement you make in your bug report can be validated, as you would expect for any other assertion of fact (think Wikipedia editing). If you can’t explain what’s wrong in a way that allows another person like you to validate your concern, don’t try to report a bug.
This doesn’t mean using a bug tracker to ask for support. Many open source projects have underdeveloped infrastructure, so there’s a belief that the developers’ tools are there for users. They aren’t. Complaining they aren’t suited to user issue reporting is a mistake, and abusing them actually makes things worse for developers, not better.
Users who post problems to bug trackers sometimes complain that developers don’t respond seriously to their feature requests and bug complaints. They should stop and remember they're not dealing with a proprietary product. That’s why if I find using developer-oriented reporting channels too hard, I post as constructively as I can to a forum or user support site like the one LibreOffice runs.
When I post to a user-oriented venue for a project to report a problem I’m having -- in a way that makes it reproducible by another person like me -- it's frequently picked up and turned into a bug report by another community volunteer who has more experience with the developers’ bug tracker. This approach also means I’ll learn if there’s a work-around or if I've simply failed to understand what I am doing.
Developers seldom frequent user forums -- which is another reason why they're a good place to go with naive questions. They tend to be populated by people with sufficient technical experience to triage issues, and if you're not part of the developer community, they're probably your best bet for reporting bugs. Your problem report is far more likely to get addressed eventually if you start there.
If you have spare time over the holidays, help out by being a tester in your favorite open source project. Find the things you think are wrong, discuss them on a user forum, and build a test case for them. Write instructions and post the test case to the project bug tracker. If there’s no decent user forum, maybe volunteer to install Askbot for the project.
This year, make some developers happy with a few well-documented test cases instead of complaints! In the end, everyone benefits.