A short list of tips and recommendations, for those who use OSS and/or want to contribute to it.
- Give feedback
Before I get into the wrong ways to give feedback, let me be clear: the worst thing you can do is give no feedback at all.
Filing an issue on your internal company bugtracker, fixing the issue in a private fork, and then never committing it back upstream might help you in the short run, but it hurts the community of people using the library.
Furthermore, it's a fragile solution, because your own co-workers might not understand your fork, or what you were trying to solve. Then when you get several versions behind the main repo, someone might just opt to throw away your changes entirely.
Commits that are made in the open are much more likely to be tested and documented, because they have a larger audience. This is the point of open-source.
- Don't just say "it doesn't work"
You might not believe it, but I see plenty of issues on Github where someone just says, "It doesn't work." Another good one is, "It doesn't work on Windows Phone." OK great, what if I don't have a Windows Phone? Or they might paste a big snippet of code, without much explanation.
Code snippets are better than nothing, but the most helpful thing is a live working demo. In JavaScript, this is as simple as a JSBin/JSFiddle/what have you. It really doesn't take that much time to set up. And even with projects that aren't web-based, you can still provide a Github repo with steps to run the code.
Here's an example: I filed this issue on the Crosswalk project, complete with a concise description, a video showing the bug (!), and a full Android project that you can run with a few simple commands.
A bug report like this is a godsend for developers, because they can spend less time trying to guess what you meant, and more time fixing your bug.
- Send pull requests
A reproducible test case is the best kind of bug report, but you know what's even better? Pull requests.
To be clear, there is a difference between a good pull request and a bad one. The kind of PR that I, as an open-source maintainer, am likely to ignore include:
- Debug statements still strewn throughout the code, or commented out.
- Poor code style (which is why I add JSHint as part of the build step).
- Unrelated changes all bundled up in the same PR ("I fixed this critical bug, but I also didn't like the color of the widget, so I changed that too").
- No tests.
The most damning problem is the last one. If you don't have any tests in your commit, then I can't be sure you fixed anything at all. So I have to go in and run your code manually and see if it really fixes what you say it fixes (without breaking anything else). This brings us back to the guessing game described in #2.
On the other hand, PRs that contain a short, concise fix with a working test case are very likely to get insta-merged. In fact, when someone gives me a PR like that, I usually grant them collaborator privileges on the spot.
- Give positive feedback
As an open-source maintainer, I see a daily stream of bug reports, requests for missing features, and confused Stack Overflow questions. My inbox is a flood of negativity.
On the other hand, I know that there must be some people out there who benefit from my libraries, because I see lots of downloads from NPM. But I rarely hear about the success cases, because those people have no problems, and therefore nothing to report.
On the other hand, when I do get positive feedback, it's really awesome. One of my favorite comments about PouchDB was this one:
PouchDB will be soon running on all Chilean industrial fishing ships, in accomplishment with the new Chilean fishing law :-)
Comments like this make me realize the impact I'm having, and they give me motivation to keep going. So the next time you find a project that you really like, let the owner know! Give them a shout-out on Twitter, or just file a Github issue to say "thank you." (Trust me, we would appreciate it!)
Ultimately, open-source is a two-way street. When you give back, you accrue benefits beyond what you might expect from such an "altruistic" action.
I do open-source because it gives me satisfaction to help out other developers, while solving cool problems in the process. I also find that my open-source code tends to be higher-quality than my closed-source code, because I'm forced to tidy up the documentation, write more tests, and clarify my thoughts about what I'm trying to accomplish, because I'm putting it out there for a wider audience. A lot of companies have realized the value of open-source, too, which is why you see so many of them contributing to it.
The true spirit of open-source is best captured by the immortal words of Paul McCartney:
In the end, the love you take is equal to the love you make.
So too with open-source.
Wonderful and true. Keep your spirit :-)