Thanks for the report of the typo, I fixed it and appreciated it even if you didn't send a patch to my post.
What you said reads like "it's the same amount of work to identify a bug as it is to fix it" and I doubt that's what you intended.
No it isn't. Adding new features a user wants, providing a way to test them and confirm they build and do what they're supposed to in different platforms is a huge amount of work that needs deep specific knowledge of how the app works and what is maintainable.
Reporting problems is useful and necessary. But don't compare it to actually contributing to the app.
I sometimes receive patches where the contributor just tried to shoehorn the feature they wanted in the codebase; they didn't understand the project architecture, just found a way to get it working.
And I may receive a bug report where the user bisected the history to find which commit introduced the bug, and provide me with all inputs to confirm the issue and reproduce it myself.
Even if the latter contribution doesn't fix the bug, it will end up being merged: they found an issue, dug to find it; but they don't how to fix it while keeping in line with the library's internals.
In other words: the more a contributor tries to understand your goals and design as a project maintainer, and respects them, the more valuable their contribution — be it bug reports, documentation improvements, blog posts, or patches.
Nor is it comparable to the maintainer stopping what they are doing to sit there and provide the feature as if their time was worth less than that of the paid dev who wants to consume it.
If the feature request includes, for example, technical architecture and product design analysis, and illustrates that it has considered various other options, it could be highly valuable.
A bug report could have involved significant debugging to identify approximate causes, affected versions, and potentially-related commits that introduced/regressed the bug.
All of the above applies to documentation and support commentary too. There is a spectrum with any contribution from 'minimal' to 'thorough', and there's not necessarily a causal link between high-value contributions and paid work.
On many projects the mantainers ask way to much of the submitter in following some guidelines. I feel they think they should not "steal" the submit from the submitter or something becouse fixing stuff for them would equal the work of commenting it.
Then they could be treated rather like automated crash reports: you could mine them to see if a problem is common, or if someone reports a strange problem you might be able to see whether anyone else had seen it and look for common factors.
Seems hard to make it work in practice without it turning into a place where people would just rant. Maybe if you make the reports readable only by the project's maintainers?
That's a really tricky technical problem to achieve, since many bug reports depend on the user's local environment in order to reproduce the problem, and that could conflict with anonymization.
Making problems public creates incentives for the project to fix issues (since they can't hide their existence) and also provides opportunities and information for contributors to help resolve them (including for purely selfish reasons, to fix issues that affect their own systems too).
> If the guys deploying it have skin the game and you don't, your helping out encourages the dynamic that FOSS author time is worth less than paid dev time, that rather than send patches just complain and let the little people take care of those details. For free.
A good bug-report isn't merely whining, it's a contribution to the quality of the project. It takes some amount of time and effort to file a decent bug-report, and it helps the project better achieve its goal. It's less valuable than a good quality pull-request to fix the issue, but it still counts. (The same is true of good quality feature-requests, but to a much lesser extent in my view.)
That's different from someone having a sense of entitlement. Unless you're on their payroll, you aren't obliged to prioritise their bug. More generally, you aren't obliged to continue your involvement in the project in any way.
The OSS authors who are successful are also paid, of course: but at that point they've "made it" and no longer have the same concerns (e.g. paying bills) that the 99.999% of other OSS developers have.
Waiting tables in the movie business feels more like a hustle; people do it so they can live in LA or Vancouver while they seek fame and fortune.
I have seen a trend of fame/fortune-seeking in OSS recently, but it seems more like a toxic offshoot than the norm.
The best OSS projects are still made by people who are genuinely trying to share solutions to common problems. Maybe they "make it" financially, but that is orthogonal to OSS contribution.
copywriting
> But if you recognize that somebody is talking you about something that is, really, a defect in your software, don’t do the error of reducing the interaction to a vile matter of money. You are doing work for free, they are risking their asses deploying what you wrote, you both care about quality.
In the end the fact you're there making time for any interaction requires some money to be entering the system somewhere, to pay the rent. If the guys deploying it have skin the game and you don't, your helping out encourages the dynamic that FOSS author time is worth less than paid dev time, that rather than send patches just complain and let the little people take care of those details. For free.