Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: