1. 55
  1.  

  2. 24

    I don’t agree with the author’s opinion, because he paints bug reports as singular. However, you can have really bad bug reports, merely stating the problem with zero effort on their behalf, or really good ones with logs, extensive background and maybe also with a patch, where you see that the person spent their time to investigate such that the maintainer/developer saves as much time as possible with the given fix (and bugs need to be fixed at some point, imho).

    We do it differently at suckless: Unless we see that someome is overwhelmed by the complexity of the problem, we ask them to send a patch. This person then can either spend the time writing one or even ask/pay somebody else to do it. People don’t have the right to demand “customer support”, but if they do the work for you (and bug-hunting is mostly testing and lottle coding), you miss a huge opportunity ignoring them. This insistence on patches is even stricter with quality-of-life change requests, and looser if someone reports an actual bug or security flaw. Overall, the system works very well.

    Even though there is no fundamental flaw in the author’s reasoning, I wouldn’t want him to face a situation where a 0-day or major security issue is found in his software. I’d be very pissed to find his payment-bug-model out at the point when I’ve finished a bug-hunt. On the other hand, maybe the author doesn’t have much experience with projects that have actual security relevance.

    1. 30

      From what I can gather, the type of software this user writes mostly deals with non-technical users; it’s kind of a different thing than suckless, where people usually know at least roughly what they’re doing (well, mostly anyway … I’ve seen some folk on /r/suckless…) Suckless is a rather special project as it’s explicitly aimed at expert users; if you don’t know at least the basics of C then you probably won’t have a good time using suckless tools (which, IMHO, is probably its biggest selling point, rather than the minimalism).

      This APK downloading thingy he makes sits in this kind of weird space where it’s a little bit technical but not too much, and in my experience this attracts a certain type of person. Let call them, ehm … “wanna-be power user”? That is, someone who wants to do all sorts of stuff with their computer (cool!) but also doesn’t really want to spend any time on learning anything (less cool) and crowdsources the actual legwork to various strangers on the internet (very uncool).

      One of the big problems is that it’s very hard to distinguish the “interested user who wants to learn” and the “wannabe power user” from a single data point. I read a bit through his issue tracker when he posted his blog last time, there doesn’t seem to be that much activity there[1], but in one of the issues he mentioned that he just removed the CLI because he was tired of teaching people CLI fundamentals. Even if all these people were “interested user who wants to learn” (they almost certainly weren’t) it gets rather tedious quickly.


      I’d expect the author will fix serious bugs and 0-days, but there’s a large class of bugs of the order “will only happen on Windows 10 patch 6316, if Firefox and Chrome and both installed, if it rains, and if Beyoncé released a new single in the last 4 months”. Fixing those tends to be where the time-consuming work is, with comparatively little benefit for the vast majority of users.

      At the end of the day it’s all about expectations: I have a few projects where I work on in my spare time for my own purposes, and I’ve very clearly said “Thanks for the bug report, I’ll fix it when I feel like it” on a number of occasions (in pretty much those words, with a little bit of context). Sometimes I feel like it the next day, sometimes much later. Sometimes never. On other projects expectations are a bit higher: one of my projects is paying the bills right now.

      I’ve recently come to think that we just need new terms for this; “Open Source” or “Free Software” (whatever you prefer) just doesn’t capture any of this. Most projects fall in three categories: a business who open source something, someone who makes something in their spare time and puts it online “because why not?”, and people work on it in their spare time and really like being maintainers for these kind of things (rather than just working on it for their own purposes).

      There’s some overlap: I tend to write READMEs and docs and worry about backwards compatibility even if I work on it on my own purposes, and the “business open sources something” can be subdivided in various categories, but those seem to be the rough outlines.


      [1]: Which is normal for non-tech open source projects, by the way. The most “popular” project I made for years was a little video downloader for the Dutch public broadcast service, and it has very little GitHub issues/stars, but I had quite a lot of emails with questions, bug reports, or just “thank you”s.

      1. 7

        Even though there is no fundamental flaw in the author’s reasoning, I wouldn’t want him to face a situation where a 0-day or major security issue is found in his software. I’d be very pissed to find his payment-bug-model out at the point when I’ve finished a bug-hunt. On the other hand, maybe the author doesn’t have much experience with projects that have actual security relevance.

        This is speculative. The author’s commits suggest that they treat minor security issues as standard bugs and fix them promptly. There do not appear to be any outstanding CVEs for their project; in fact, there don’t appear to have been any CVEs ever filed for their project. It is premature to sneer at a project for failed security practices when they have not had an opportunity to fail, and misleading to sneer at a project which has no evidence of failed security practices.

        More importantly, you’ve confused the emotions on two sides of a multi-agent interaction. As the user, you might be pissed, but as the developer, why are you required to establish empathy with folks who you’ve already reasoned to be behaving detrimentally to you and the software being maintained? And on the other side, nobody should want to face a situation where their software has a 0-day exploit; it’s a hassle even if there are existing processes for developing and testing and deploying the fix.

        On the gripping hand, isn’t it kind of asking for security vulnerabilities when you’ve chosen C as your implementation language, rather than the memory-safe Java chosen by the author? Your approach to security is going to be different, because your implementation choices inherently lead to more security problems in supposedly-bug-free code.

        I think that your final paragraph could have been written more simply as:

        there is no fundamental flaw in the author’s reasoning

        1. 1

          It’s kind of an “inverse effort law”. The more effort the code owner has to go through to make sense of a submitted PR/bug/issue, the less likely they are to address it in a timely fashion (if at all).

        2. 17

          The OP’s position has some validity to it — their policy isn’t that different from some companies with open source products, such as my employer — although refusing to even read bug reports seems extreme.

          But validity aside, man does their tone come across as hostile! I realize they’re responding to a bunch of flames, but my emotional reaction to that post is “wow, this person is either a real asshole, or is nearing a breakdown from stress.” Neither of which makes using their software seem attractive.

          1. 12

            I recall several times when I’ve added OSX or Windows compatibility to projects. Every time, it was due to the desires of folks who ultimately never ended up contributing, and in most cases did not become regular members of the community.. They wanted to test out the software, because they didn’t know whether they even wanted to use it, but the presence of the feature was not enough to guarantee commitment.

            I think that it is this lack of buy-in which the author aims to address. If we imagine taking the user at their word when, in the first post, they say:

            User: Hi, I’d like to report a bug in your application.

            Do they really want to report a bug? No, they want to see a bug be fixed. These are two different things. The formeris an innocuous update of ambient information, and the latter is a request for action:

            User: I just want to tell you that your app is broken, so you can fix it.

            I ponder whether we could require users to understand what they’re doing. When I learned woodworking as a child, I was required to carefully examine each tool and understand how it worked before I was allowed to use it. And some tools, despite being relatively simple, were off-limits; I was not allowed to use table saws. None of this was because I was inherently irresponsible or incapable, but because it was likely that I would injure myself if I did not have a full understanding of my actions.

            This isn’t just an idle bit of patrician pedagogy, either. Software is a series of artifacts which we produce in service of our existing understanding of the problems that we wish to solve. As has been debunked many times, algorithm fishing is futile; if one does not know how to solve their problem in principle, then they will not magically discover the solution just by writing some code.

            What the author is getting at, then, is that the user also will not magically discover the solution just by running some code. Perhaps reading code can give answers, but in that case, no new software needs to be written. And the author is not tone-deaf or lazy, either; they’ve produced a manual for their software, replete with instructions for installation, common usage, and even debugging common problems.

            1. 4

              I recall several times when I’ve added OSX or Windows compatibility to projects. Every time, it was due to the desires of folks who ultimately never ended up contributing, and in most cases did not become regular members of the community.

              I’ve done Windows support at the request of people who were building commercial products and were willing to fund the development but otherwise my experience mirrors yours. Interestingly, I’m now seeing roughly the same thing with Linux: The ratio of developers to users is dropping sharply and you need a lot of users on Linux to get one contributor. It’s making me a lot more interested in supporting minority platforms. I don’t use Haiku at all, but my experience so far is that Haiku has basically no users who are not also developers. If you’re willing to accept patches for Haiku support and maintain them, you get a small number of users on Haiku, all of whom are likely to submit useful patches.

              My vague intuition here is that, as an open source project, there is far more value in supporting niche platforms than popular ones, in terms of conversion rate from users to developers and that this conversion rate is inversely proportional to the popularity of the platform.

              1. 1

                Do they really want to report a bug? No, they want to see a bug be fixed.

                I don’t necessarily agree. I don’t know if I am able to make myself clear, but I usually try to give some context, like “Hi, I just installed this for the first time and X happened” or “was just trying this application and Y happened” - but I think the mutual understanding between is usually not demanding a bug fix, but maybe my view as a maintainer myself is skewed and I should add some nicely phrased “fix it or don’t, I don’t care, was just an FYI”.

                But also this is because if I test something and it doesn’t work at all, I usually try to take the 5 minutes to file a bug report, because I am glad if someone takes their time to do this for my projects. It doesn’t mean it will be fixed asap or at all, but it’s always good to know.

              2. 10

                While I agree that the writer follows a certain logic and it makes sense in their world view, I think there’s one important thing missing: The copy-left and free software part of open source always was more than just “this needs to work well in the established system”, it had a more revolutionary part that made it so interesting. It tried to build an alternative to the capitalist way of working and paying for work, because software and digital content (being copyable) is fundamentally different to physical goods and services. The free software people tried to apply new ways of thinking about those new goods. This is why it was frowned upon in the early days by entepreneurs, and it was completely unthinkable that something like Linux will work somehow. This part can’t be grasped by the logic the author uses.

                1. 11

                  To add to that a little: the kind of friction that the author mentions became more or less inevitable once FOSS expanded past the community of dogfooding enthusiasts, and it comes from both sides.

                  I.e. for a long time, it wasn’t uncommon for people to show up not just with bug reports, but also with a patch. Some communities still see this as natural (FRIGN mentions it in another comment here re. suckless, but they aren’t the only ones), and facilitate this in every possible way (I haven’t contributed anything to suckless projects but reading their mailing lists it’s clear that they’re really cool about it).

                  But it was inevitable that, as FOSS adoption grew, it would eventually grow to include people who lack the expertise to modify the tools they use, people who are simply forced to use them at work and so on. I mean, 20 years ago, lots of people who used Linux in enterprise settings were trying to get the higher-ups to approve using Linux on white boxes instead of Sun’s expensive stuff, and they had a lot of stakes in the game. Lots of people using it today are junior devops who inherited the Linux shop set up 20 years ago. They have no stakes in it, and there aren’t any Sun salesmen to yell at, either, so of course they get yelled at and then show up demanding bugfixes from the same people who showed up at FOSDEM encouraging others to adopt their tools. I’m not saying they’re right, just that I understand why they do it.

                  There’s some friction at the other end, too. E.g. sometimes you unwittingly end up working around a bug that you have a patch for, but the fix will never get in because the project – while FOSS in terms of license – is effectively a corporate playground, and maintainers will (understandably) prioritize their colleagues’ fixes over yours, assuming you can even get them to look at yours, that is.

                  1. 5

                    RMS always stressed that he is a capitalist, not a communist. I guess the revolutionary part is that he wants to eradicate proprietary software, which would mean changing the business models of large parts of the software industry, but you can still pay people to work on free software.

                    1. 1

                      Then he’s not a capitalist. Capitalism is about earning dividends from property (ie software you’ve written or bought using capital), not from work.

                      1. 2

                        He believes in a capitalist system of production, which existed before software and could continue without proprietary software (in principle if not in practice).

                    2. 4

                      The copy-left and free software part of open source always was more than just “this needs to work well in the established system”, it had a more revolutionary part that made it so interesting. It tried to build an alternative to the capitalist way of working and paying for work

                      While many choose to approach free software in this way, this mischaracterises the philosophy of the free software movement at least as RMS and the FSF established it. They have never been shy about authors charging money for free software - whether it’s your own or somebody else’s!

                      Actually, we encourage people who redistribute free software to charge as much as they wish or can. If a license does not permit users to make copies and sell them, it is a nonfree license. (https://www.gnu.org/philosophy/selling.en.html)

                      To me, the author’s approach seems very consistent with what FSF advocates.

                      1. 1

                        From the GNU Manifesto:

                        We must distinguish between support in the form of real programming work and mere handholding. The former is something one cannot rely on from a software vendor. If your problem is not shared by enough people, the vendor will tell you to get lost.

                      2. 3

                        The guy explicitly points out that submitting a bug report is for the benefit of the whole community of users, yet still tells you to get fucked for sending him one. If you actually dony care about your users, don’t make an advertising site for your software.

                        1. 6

                          The whole community - every user with an ongoing interest - benefits when the maintainer earns enough to keep showing up, too.

                          1. 1

                            Maybe charging people money to do tedious grunt work for you (reporting bugs) works for that. I hope not.

                        2. 3

                          I often submit bug reports to FOSS projects, without expecting an immediate fix on my behalf, and with the belief that my reports are a net benefit to the author(s). However, that ignores some aspects of the ecosystem:

                          • When reviewing potential tools on Github, one sign of project health I use is “how many open vs. closed issues are there?”. In other words, I downgrade projects which don’t respond to bug reports.
                          • Not everyone is as intelligent and thoughtful as me ;). So, projects must deal with lots of low-quality and spurious bug reports, especially when their tools are meant for general use (as are the OP’s).
                          • It takes time and energy to review bug reports, even if no action is likely to be taken. This gets magnified by self-entitled users, again especially those of general-use tools.

                          Topics like this are more subjective than they seem. The costs and benefits depend greatly on the project, the developers, the audience, and many other dimensions, not all of which are apparent to bystanders. Conclusion: although I wouldn’t choose the OP’s approach to the problem, I can’t say that it’s the Wrong Thing To Do.

                          1. 3

                            I guess it’s a rather radical measure, and I feel sorry for the author that they felt forced to do that. I like the statement though, because nobody simply has the right to demand that you work on something in your own time, and there appear to be a lot of people who don’t get that.

                            1. 2

                              I think this is quite reasonable. I’m very sympathetic to people trying to minimize the amount of worry and care in their lives, and responding to bug reports is certainly a source of worry. At least this guy gets to feel like he’s earning something by submitting himself to this. I’m sure that not only is a strong motivation to fix reported bugs, but also makes it a lot more fun to do so.

                              1. 1

                                Pretty rough post. What I would do, is create a sticky issue (on github or similar) and just say that, you can create an issue (bug/improvement/etc) but maintainers may never reply to it.

                                Not exactly related, but I like how sqlite went about contributions, they simply don’t accept those (can’t find the link now), this also I think helps with saving maintenance time.