5 ms·

>From there it typically derails into a whiny tirade about me being a crappy two bit developer who doesn’t give a shit about his code (which is ridiculous, sinc

by eznzt 6y ago

>From there it typically derails into a whiny tirade about me being a crappy two bit developer who doesn’t give a shit about his code (which is ridiculous, since, professional pride aside, I have every incentive to fix bugs, to prevent my inbox from getting flooded) and just wants to rip off his users. If you really cared about fixing bugs then you'd take bug reports. Taking a bug report does not mean you are forced to fix it (which is work, which costs money), but at least you'd be aware about the existence of the bug. So, charging for bug fixes, okay. But if you don't even want to be aware of bugs, then yes, you are a crappy maintainer.

deleted 6y ago
[deleted]
scarygliders 6y ago
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.
ddevault 6y ago
Wrong on all counts here. The author (and most FOSS maintainers), as they explicitly called out in their article, are making the software for themselves, and making it open source because it's the nice thing to do. It follows that any bug that doesn't personally affect them is not something they need to care about. There's no greater good of "caring about fixing bugs" here. To quote the MIT license: the software is provided “as is”, without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and noninfringement. You were warned.
- pseudalopex 6y ago
  I don't think maintainer is the right word for someone who isn't interested in maintenance. The long tail of FOSS projects might be things people wrote just for themselves. The most used projects aren't. Most of the projects most people use aren't. Almost all software has a warranty disclaimer. It would be irrational to assume it means the software is unsupported.
lloydatkinson 6y ago
What part of accepting bugs means you have to accept abuse?

by eznzt 6y ago

deleted 6y ago

[deleted]

scarygliders 6y ago

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.

ddevault 6y ago

Wrong on all counts here. The author (and most FOSS maintainers), as they explicitly called out in their article, are making the software for themselves, and making it open source because it's the nice thing to do. It follows that any bug that doesn't personally affect them is not something they need to care about. There's no greater good of "caring about fixing bugs" here. To quote the MIT license: the software is provided “as is”, without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and noninfringement. You were warned.

pseudalopex 6y ago
I don't think maintainer is the right word for someone who isn't interested in maintenance. The long tail of FOSS projects might be things people wrote just for themselves. The most used projects aren't. Most of the projects most people use aren't. Almost all software has a warranty disclaimer. It would be irrational to assume it means the software is unsupported.

lloydatkinson 6y ago

What part of accepting bugs means you have to accept abuse?