Hacker News Reader

Comment by outsomnia | Hacker News Reader

> and not when doing copyrighting work for a well known company

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.

View on HN

Signaling bugs is as much work as it is to send a patch. Sometimes is even better work. For instance a bug report that is the fruit of a deep investigation is worth a lot more than a weak patch that is fixing the problem in the wrong way, often because of lack of understanding of the system. I don't agree there is a clear distinction of patches and bug reports in which one is work donated to the project and the other is not.

Thanks for the report of the typo, I fixed it and appreciated it even if you didn't send a patch to my post.

> Signaling bugs is as much work as it is to send a patch.

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.

It depend on the actual patch, and bug report.

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.

It seems we agree eg, a paid dev's feature request is not comparable to the paid dev contributing the feature itself via discussion with the maintainer.

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.

Regardless of whether the contributor is paid, I think that feature requests and bug reports can be compared to feature implementations.

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.

A quick fix is a great way to describe a bug for the person that understands the system.

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.

Highly depends IMHO. A good bug report that doesn't just says "X happens sometimes" but figures out when and why, or provides in-depth reasoning for what the behavior should be, can be a lot more work than the code fix, or a new feature.

But you would want the "it doesn't work sometimes" bug reports too so you can keep your eyes open for it.

It might be a nice to have a place where people can file low-effort bug reports, or perhaps "symptom reports", where there's no expectation that a maintainer will respond or even look at them.

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?

It's a bit of an unusual idea, but I'd suggest that making symptom reports more public would help -- as long as they are anonymized and opt-in.

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

That's what user forums are for, like uservoice or reddit.

I programmed quite a lot of C/C++/Java code in my life (looking back at it, close to 3 million lines), and I consider good, reproducible bug reports an important contribution. An app full of new features that the users want is still unusable if it crashes often or mutilates stored data.

I think perhaps here you mean that "signaling bugs is work, just the same as sending a patch is work".

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.

At the risk of mirroring antirez's response, and on top of that I suspect I might be misreading you, but still:

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

I've come to view OSS as the software industry's inferior analog to waiting tables in the movie business. It's inferior because at least waiters are paid for their labor.

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.

That's an interesting take; I view OSS as an act of generosity. It's a gift given by the author, without any expectation of reward.

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.

Reply on news.ycombinator.com