Hacker News Reader

>In the case of software like Redis, pretty much everyone reporting a bug is also qualified to fix that bug, so it works particularly well.

There are a good bunch of people who have never written any C and even more people who have no idea about the internals of Redis, yet they are Redis users and they do find bugs. I wouldn't expect those users to write a patch for every bug they find to be honest.

I think the idea is that given enough users, the bugs who will be encountered by non-fixers will also be encountered by fixers so they'll be fixed, otherwise they are so rare as to not be worth the effort of wasting time with useless non-fixer reports to find the useful non-fixer ones.

I'm not sure how i feel about that TBH, personally i'd like to know about bugs even if they do not come with patches but at the same time i understand not wanting to be bothered by wading through useless reports.

Perhaps there should be end user oriented bugtrackers that look more similar to something like a hybrid between a forum and a reddit/HN post with voting (no downvotes though, kinda like GOG's wishlists) so that developers will have a rough idea where to focus next and "locked" (but perhaps visible, at least for FOSS projects) traditional bugtrackers where end user entries migrate (and linked to) once developers decide that this will be worked on.

It wont solve all issues, especially with people potentially going "why aren't you fixing that bug-but-really-a-feature-that-requires-rearchitecting-the-entire-thing that has 897482959204 votes and instead work on whatever-else that Nobody Asked For(tm)?", but i guess you can't fix entitlement with technical means.

All properly filled bug reports are useful.

This mentality that only writing code matters needs to stop. Open source projects (or any project for that matter) is way more than just writing code and the people doing the "other" work need to be recognized and encouraged to continuing that.

The lack of such people is exactly the major cause of burnout from maintainers who just want to code.

Not replying to all your points directly, just making a general statement about this whole thread.

If you aren't replying to my points why are you making a reply to my comment?

Yes, all properly filled bugs reports are useful. The important part here is that "properly" word though and on a popular project they can be hard to find. What is worse, this incentivizes people to file the same or similar bugs twice (or more) since they can't find the duplicate (in which case, properly or not doesn't matter, you already demonstrated your belief that your time is more important than whoever will have to wade through the bugs to find your duplicate).

Also while code isn't the only thing that matters, it is the thing that matters the most - the software doesn't exist without code, but it can exist without everything else - and the programmers who write the code are those who make the final decision on what ends up in the software (assuming FOSS made by volunteers here, of course, not FOSS or closed source software made by employees - although even in that case, often the developer who writes the code is the one making the decision anyway).

It's always an option to go the proprietary route and release your code as shareware. It worked for a long time. Why bother to release the source if it's such a hassle?

Sadly it worked until users were taught to expect everything for free (see how every single time someone posts something here or on Reddit that costs money, there is at least one post - often more - with free "alternatives" upvoted near the top) and other developers spreading FUD against you if you do not release the code - even if you give your software away for free.

Of course if you are going to receive harassment either way, might as well get paid for it.

Anyone who can write code can learn C, and be proficient enough to fix their bug in a few hours - or at least proficient enough to ask the right questions. The biggest barrier is unwillingness to try.

I've seen this played out a dozen times. My projects are often many people's first exposure to C, ever.

I'm interested in your approach here because I generally disagree with ignoring bug submissions from "drive-by"s.

As a developer, I might have the time to investigate and submit a bug for your code, but at the end of the day, is probably just one more bug in 100 other pieces of code preventing me from writing the code I need to.

Getting familiar with the code of a project you're using, to the extent that your can submit a reasonable PR is a not-insignificant time dedication.

I've found a variety of attitudes from upstream code I've reported to, ranging from "you're wrong" to the bug being fixed and pushed to master within an hour.

I've formed an opinion, amongst the projects I work with, about whom I should give more of my (professional) time to, that usually begins with how receptive they are to a perfectly good bug report which I don't have the (professional) time to fix.

The ones that have proven "pleasant" to work with have made it much easier for me to convince my bosses that their money is well spent giving back.

So that is why so many OSS projects are full of bugs and horrible usability. In the past, I have tried to help with clear, reproducible bug reports. Quite often I spent an hour tracking down a bug, writing up why it matters, and then got ignored or dismissed.

Those OSS projects that deliver a quality product, also took my bug reports seriously (and sometimes disagreed).

> So that is why so many OSS projects are full of bugs and horrible usability.

Possibly, but not necessarily. What is certain is that no developer who gives you free stuff has any obligation to fix bugs nor to submit themselves to any low-key bullying from users of said free stuff about how to spend their time and develop the software they decide to share with others.

I agree! But let’s not discount the value being provided by bug reporters who give a superb description and excellent reproducibility. They just wrote a codeable test case, which is valuable free stuff, ie like for like.

TL;DR;

FOSS Zeolots: everyone should use FOSS! Micro$oft is evil!

Also FOSS Zeolots: Oh you have a bug? Screw you. You're getting it for free. Stop complaining. I'm busy making a new icon.

OSS is great. But until this attitude is killed, it will continue to hover just above "who gives a shit" for anything other than developers

FWIW i am not a FOSS zealot. If anything some of the software i find enjoyable to use is not FOSS (but sadly a lot of it is older software, largely because of user hostile modern trends - see Electron, phone-home DRM, adware, etc - but also because newer versions or alternatives simply have worse UX and/or bloated to almost unusability) and really my comments come more from a "you are entitled to what you pay for" stance.

I certainly won't disagree with hostile modern software trends. I just think if FOSS maintainers are accepting the responsibility of maintaining the project, they should accept the responsibility of taking bug reports seriously. Everyone knows they are no fun. And everyone knows they aren't flashy. And the maintainers are more than welcome to ignore them. But in doing so, they can't complain about people not accepting consumer facing FOSS. It's a package deal.

People are not a hive mind, some developers may ignore bugs, others may complain about end user oriented FOSS acceptance and perhaps some do both, but chances are these two groups are separate (and in larger projects you may even have people under more than one of these groups).

Also unless someone has explicitly expressed they are taking such a responsibility you describe, such a responsibility only exists in some people's minds. A lot of programmers want to share free stuff they made and stop there.

Your claim is common, but wrong. Approximately none of the major technology companies do more than rudimentary call-center service for bug reports from consumers.

If anything, the entitlement you express is counterproductive, because sometimes people like you convince open-source developers that their time is better spent catering to your sense of entitlement instead of their software.

My claim is common bc it's the truth.

Source: I am a maintainer of several projects. Some that are used extensively. And I take bug reports seriously, even if I can't always get to them right away.

"it's free, go away" is a real problem. Denying it won't make anything any better or help FOSS get adopted for anything other than servers.

I have experienced it many times before, and almost every time I've gone back to propriety software and breathed a sigh of relief.

> "it's free, go away" is a real problem.

Characterizing this as a problem is like accepting free candies from someone and then complaining that you were not given more candies.

No, it's like telling the candy maker that their candy made them sick or otherwise left something to be desired. If the candy maker cares about making good candy, that can be useful information, even if they may not have time to do something about it. If the candy maker cares about making mediocre-to-bad candy freely available, then they will say "it's free, go away."

No, it is exactly as i wrote above, the idea isn't to complain back, it is that you get shit for free and you have no standing to demand for anything more than what you got. If free candy makes you sick maybe next time do not accept free candy from strangers, hm?

(of course i knew someone would try to reply with a "No, it is like <insert post ignoring the point here>" but decided to go with it anyway)

Where did 'StaticRedux say anything about demanding anything?

It's perfectly possible to report a bug without demanding that it be fixed.

Your source is inapplicable. You are not a statistical universe.

Also, "it's free, go away" is a straw man, because the "go away" part is also nearly universal within proprietary software. Try opening a ticket regarding a bug in Word, or AutoCAD, or so on.

The real difference? Those closed products also have closed bug trackers, so you don't get to see all the times users were ignored or told to pound sand.

This "real problem" exists entirely in your head.

If you do write a clear bug report, with a stack trace (with symbols) and reproduction steps and such, then a developer is much more likely to give your bug the time of day. In the end, though, a patch is worth a thousand tickets.

I found the writings of Peter Hintjens (creator of ZeroMQ) very inspiring, where he describes the merits of Optimistic merging (OM). Quoting at length from http://hintjens.com/blog:106:

Standard practice (Pessimistic Merging, or PM) is to wait until CI is done, then do a code review, then test the patch on a branch, and then provide feedback to the author. The author can then fix the patch and the test/review cycle starts again. At this stage the maintainer can (and often does) make value judgments such as "I don't like how you do this" or "this doesn't fit with our project vision."

In the worst case, patches can wait for weeks, or months, to be accepted. Or they are never accepted. Or, they are rejected with various excuses and argumentation.

PM is how most projects work, and I believe most projects get it wrong. Let me start by listing the problems PM creates:

    It tells new contributors, "guilty until proven innocent," which is a negative message that creates negative emotions. Contributors who feel unwelcome will always look for alternatives. Driving away contributors is bad. Making slow, quiet enemies is worse.

    It gives maintainers power over new contributors, which many maintainers abuse. This abuse can be subconscious. Yet it is widespread. Maintainers inherently strive to remain important in their project. If they can keep out potential competitors by delaying and blocking their patches, they will.

    It opens the door to discrimination. One can argue, a project belongs to its maintainers, so they can choose who they want to work with. My response is: projects that are not aggressively inclusive will die, and deserve to die.

    It slows down the learning cycle. Innovation demands rapid experiment-failure-success cycles. Someone identifies a problem or inefficiency in a product. Someone proposes a fix. The fix is tested and works or fails. We have learned something new. The faster this cycle happens, the faster and more accurately the project can move.

    It gives outsiders the chance to troll the project. It is a simple as raising an objection to a new patch. "I don't like this code." Discussions over details can use up much more effort than writing code. It is far cheaper to attack a patch than to make one. These economics favor the trolls and punish the honest contributors.

    It puts the burden of work on individual contributors, which is ironic and sad for open source. We want to work together yet we're told to fix our work alone.

Now let's see how this works when we use Optimistic Merge. To start with, understand that not all patches nor all contributors are the same. We see at least four main cases in our open source projects:

    Good contributors who know the rules and write excellent, perfect patches.
    Good contributors who make mistakes, and who write useful yet broken patches.
    Mediocre contributors who make patches that no-one notices or cares about.
    Trollish contributors who ignore the rules, and who write toxic patches.

PM assumes all patches are toxic until proven good (4). Whereas in reality most patches tend to be useful, and worth improving (2).

Let's see how each scenario works, with PM and OM:

    PM: depending on unspecified, arbitrary criteria, patch may be merged rapidly or slowly. At least sometimes, a good contributor will be left with bad feelings. OM: good contributors feel happy and appreciated, and continue to provide excellent patches until they are done using the project.
    PM: contributor retreats, fixes patch, comes back somewhat humiliated. OM: second contributor joins in to help first fix their patch. We get a short, happy patch party. New contributor now has a coach and friend in the project.
    PM: we get a flamewar and everyone wonders why the community is so hostile. OM: the mediocre contributor is largely ignored. If patch needs fixing, it'll happen rapidly. Contributor loses interest and eventually the patch is reverted.
    PM: we get a flamewar which troll wins by sheer force of argument. Community explodes in fight-or-flee emotions. Bad patches get pushed through. OM: existing contributor immediately reverts the patch. There is no discussion. Troll may try again, and eventually may be banned. Toxic patches remain in git history forever.

In each case, OM has a better outcome than PM.

In the majority case (patches that need further work), Optimistic Merge creates the conditions for mentoring and coaching. And indeed this is what we see in ZeroMQ projects, and is one of the reasons they are such fun to work on.

Broken quotes reformatted for readability:

----

> It tells new contributors, "guilty until proven innocent," which is a negative message that creates negative emotions. Contributors who feel unwelcome will always look for alternatives. Driving away contributors is bad. Making slow, quiet enemies is worse.

> It gives maintainers power over new contributors, which many maintainers abuse. This abuse can be subconscious. Yet it is widespread. Maintainers inherently strive to remain important in their project. If they can keep out potential competitors by delaying and blocking their patches, they will.

> It opens the door to discrimination. One can argue, a project belongs to its maintainers, so they can choose who they want to work with. My response is: projects that are not aggressively inclusive will die, and deserve to die.

> It slows down the learning cycle. Innovation demands rapid experiment-failure-success cycles. Someone identifies a problem or inefficiency in a product. Someone proposes a fix. The fix is tested and works or fails. We have learned something new. The faster this cycle happens, the faster and more accurately the project can move.

> It gives outsiders the chance to troll the project. It is a simple as raising an objection to a new patch. "I don't like this code." Discussions over details can use up much more effort than writing code. It is far cheaper to attack a patch than to make one. These economics favor the trolls and punish the honest contributors.

> It puts the burden of work on individual contributors, which is ironic and sad for open source. We want to work together yet we're told to fix our work alone.

----

> Good contributors who know the rules and write excellent, perfect patches.

> Good contributors who make mistakes, and who write useful yet broken patches.

> Mediocre contributors who make patches that no-one notices or cares about.

> Trollish contributors who ignore the rules, and who write toxic patches.

----

> PM: depending on unspecified, arbitrary criteria, patch may be merged rapidly or slowly. At least sometimes, a good contributor will be left with bad feelings. OM: good contributors feel happy and appreciated, and continue to provide excellent patches until they are done using the project.

> PM: contributor retreats, fixes patch, comes back somewhat humiliated. OM: second contributor joins in to help first fix their patch. We get a short, happy patch party. New contributor now has a coach and friend in the project.

> PM: we get a flamewar and everyone wonders why the community is so hostile. OM: the mediocre contributor is largely ignored. If patch needs fixing, it'll happen rapidly. Contributor loses interest and eventually the patch is reverted.

> PM: we get a flamewar which troll wins by sheer force of argument. Community explodes in fight-or-flee emotions. Bad patches get pushed through. OM: existing contributor immediately reverts the patch. There is no discussion. Troll may try again, and eventually may be banned. Toxic patches remain in git history forever.

The purported benefits of Optimistic Merge appear entirely unrelated to the merging strategy used. The scenarios could easily unfold completely differently:

> PM: depending on unspecified, arbitrary criteria, patch may be merged rapidly or slowly. At least sometimes, a good contributor will be left with bad feelings.

> OM: good contributors feel happy and appreciated, and continue to provide excellent patches until they are done using the project.

alternatively:

PM: The patch is merged as soon as CI passes, unless code review uncovers any serious issues. Good contributors feel happy and appreciated.

OM: depending on unspecified, arbitrary criteria, patch may be reverted or modified to suit the tastes of the project maintainer. At least sometimes, a good contributor will be left with bad feelings.

> PM: contributor retreats, fixes patch, comes back somewhat humiliated.

> OM: second contributor joins in to help first fix their patch. We get a short, happy patch party. New contributor now has a coach and friend in the project.

alternatively:

PM: second contributor notices the CI failure, joins in to help first fix their patch. We get a short, happy patch party. New contributor now has a coach and friend in the project.

OM: the patch breaks master, someone posts an angry rant, contributor retreats, fixes patch, comes back somewhat humiliated.

> PM: we get a flamewar and everyone wonders why the community is so hostile.

> OM: the mediocre contributor is largely ignored. If patch needs fixing, it'll happen rapidly. Contributor loses interest and eventually the patch is reverted.

alternatively:

PM: the mediocre contributor is largely ignored. Contributor loses interest and eventually the PR is closed.

OM: the patch breaks master, someone posts an angry rant, we get a flamewar and everyone wonders why the community is so hostile.

> PM: we get a flamewar which troll wins by sheer force of argument. Community explodes in fight-or-flee emotions. Bad patches get pushed through.

> OM: existing contributor immediately reverts the patch. There is no discussion. Troll may try again, and eventually may be banned. Toxic patches remain in git history forever.

alternatively:

PM: existing contributor immediately closes the PR. There is no discussion, because comments are disabled. Troll may try again, and eventually may be banned. Toxic patches don't ever make it into git.

OM: we get a flamewar which troll wins by sheer force of argument. Community explodes in fight-or-flee emotions. Bad patches get pushed through and remain in git history forever.

My takeaway is that you need to have a great community and everything will work out in the end.