6 ms·

But that ignores what the author said after that... > Here’s the thing: I write open source software to solve my problem. I let you use my solutions because th

But that ignores what the author said after that... > Here’s the thing: I write open source software to solve my problem. I let you use my solutions because that comes at zero cost for me (well, almost, I still have to pay for the website, you are downloading from.

eznzt 6y ago
If I had written some code to solve a problem of mine, I'd want to know that it contains bugs; I would not want to wait until those bugs blew my systems up. Even if it was past code that has run its course and I no longer use, if the code is posted somewhere such as github, future users might want to read the list of bugs reported by others to be aware of them (and to see workarounds potentially posted by others).
- zimbatm 6y ago
  Not all bugs are created equal. Some bugs are due to an esoteric setup of the user. There in a quasi infinite variation of those in the Linux world. Generally, supporting them makes the software more robust, but it's also very likely that you would never encounter that bug yourself. Some bugs are just support requests. The user didn't understand how to use the software and is confused. Generally the report is quite lacking and it takes a few back and forth to get somewhere. Some bugs are genuine logic bugs. I'm sure there are more variations..
  - webmaven 6y ago
    > The user didn't understand how to use the software and is confused. This can be treated as a bug in the documentation.
    - zimbatm 6y ago
      That's true to some extent. If you see a lot of users having the same issue it might be the case. Sometimes it's also people not bothering to read the documentation. As a maintainer it's also your right to develop a tool just for yourself, and share it for the world. In which case, documentation is not necessarily the priority. And it's fine.
      - webmaven 6y ago
        > Sometimes it's also people not bothering to read the documentation. Yes, sometimes it is. > As a maintainer it's also your right to develop a tool just for yourself, and share it for the world. In which case, documentation is not necessarily the priority. And it's fine. Absolutely fine. Although I'll point out that it is usually a lot easier to get documentation PRs contributed than code PRs.
    - webmaven 6y ago
      I'm being downvoted, but I don't understand why. I said it CAN be treated as a bug in the documentation, not that it SHOULD or MUST be. Edit: more downvotes, on this comment asking for feedback, rather than providing feedback. O_o
antisol 6y ago
So there's a 0% chance that I might find an issue that affects the author's usage somehow? There's absolutely no possibility that I might notice some detail on some edge case that the author hasn't noticed and which affects his own use in some way? The author is infallible and has validated 100% if his use cases to 100% certainty? Because if he's not infallible, he should want to at least be aware of bugs in the software. Not wanting to know about bugs is exactly equivalent to not being interested in the quality of your work. If you're not interested in the quality of your work, then I don't want to use your software. And I'd hate to inadvertently cost you a tenth of a cent by downloading your crap, so please shut down your webserver and don't release any new versions publicly - save yourself the money and save everybody the time and effort of having to interact with you and your shitty software.

eznzt 6y ago

If I had written some code to solve a problem of mine, I'd want to know that it contains bugs; I would not want to wait until those bugs blew my systems up. Even if it was past code that has run its course and I no longer use, if the code is posted somewhere such as github, future users might want to read the list of bugs reported by others to be aware of them (and to see workarounds potentially posted by others).

zimbatm 6y ago
Not all bugs are created equal. Some bugs are due to an esoteric setup of the user. There in a quasi infinite variation of those in the Linux world. Generally, supporting them makes the software more robust, but it's also very likely that you would never encounter that bug yourself. Some bugs are just support requests. The user didn't understand how to use the software and is confused. Generally the report is quite lacking and it takes a few back and forth to get somewhere. Some bugs are genuine logic bugs. I'm sure there are more variations..
- webmaven 6y ago
  > The user didn't understand how to use the software and is confused. This can be treated as a bug in the documentation.
  - zimbatm 6y ago
    That's true to some extent. If you see a lot of users having the same issue it might be the case. Sometimes it's also people not bothering to read the documentation. As a maintainer it's also your right to develop a tool just for yourself, and share it for the world. In which case, documentation is not necessarily the priority. And it's fine.
    - webmaven 6y ago
      > Sometimes it's also people not bothering to read the documentation. Yes, sometimes it is. > As a maintainer it's also your right to develop a tool just for yourself, and share it for the world. In which case, documentation is not necessarily the priority. And it's fine. Absolutely fine. Although I'll point out that it is usually a lot easier to get documentation PRs contributed than code PRs.
  - webmaven 6y ago
    I'm being downvoted, but I don't understand why. I said it CAN be treated as a bug in the documentation, not that it SHOULD or MUST be. Edit: more downvotes, on this comment asking for feedback, rather than providing feedback. O_o

antisol 6y ago

So there's a 0% chance that I might find an issue that affects the author's usage somehow? There's absolutely no possibility that I might notice some detail on some edge case that the author hasn't noticed and which affects his own use in some way? The author is infallible and has validated 100% if his use cases to 100% certainty? Because if he's not infallible, he should want to at least be aware of bugs in the software. Not wanting to know about bugs is exactly equivalent to not being interested in the quality of your work. If you're not interested in the quality of your work, then I don't want to use your software. And I'd hate to inadvertently cost you a tenth of a cent by downloading your crap, so please shut down your webserver and don't release any new versions publicly - save yourself the money and save everybody the time and effort of having to interact with you and your shitty software.