4 ms·

He has no obligation to do anything about bugs, but open source projects whose developers listen to bug reports is so common that if he doesn't, he should expli

by Jiro 5y ago

He has no obligation to do anything about bugs, but open source projects whose developers listen to bug reports is so common that if he doesn't, he should explicitly say "I don't take bug reports" in a reasonably obvious place, out of common courtesy. Failing to do so is the equivalent of having a deliberately misleading user interface.

chiefalchemist 5y ago
Yes and no. The issue seems to be, these aren't true bug reports but support tickets pretending to be otherwise. The creator also mentions docs. If people try to save time (i.e., time is money) and don't read the docs but they want support. Well, there should be a fee for that. As we all know, ultimately, nothing is free.
- hackerfromthefu 5y ago
  Maybe the default, or at least a common mode, for open source should be user pays for support time. This includes lodging a ticket at $50 or whatever (for time for triage) - and then developers can add a price to action a ticket if they choose. The developer could also refund the ticket fee if it's a truly valuable bug reports. Github UI should make this as frictionless as possible. This would make it alright for users wanting support rather that adding bug reports, plus provide the much lamented missing income stream for open source. It would also have the effect of winnowing the incredible bulk of open source to emphasize truly useful projects, that people are willing to pay some dollars for. Obviously there's issues, such as not all economic level countries could participate, and surely others. Yet it seems to be a solution for multiple of of the commonly expressed pain points around open source.
massysett 5y ago
This attitude is why I don’t share much software anymore, even if I spent a lot of time developing it and someone else might find it useful. All it takes is someone claiming I’m being “deliberately misleading” (even though the license explicitly says “this software is provided as is without warranty of any kind, express or implied”) and for that someone to hire a lawyer. At that point I’ve lost. It doesn’t matter that the claim is baseless. This only saddens me a bit because there are so many people out there sharing software that nowadays my meager contributions won’t be missed. However I do wonder how much truly useful software does not get shared due to these liability concerns. A corporation has to weigh the goodwill they get from sharing software versus the potential ire of angry self-entitled people who think they are entitled to free support and extra disclaimers beyond those in the license. Why bother?
- scarygliders 5y ago
  When I embarked on my 3rd party application for Elite: Dangerous, I made the decision very early on, not to open source it, even though I use Python libraries etc. which are. It also uses PySide under the LGPL. The reason I did that was because I did not want the extra overhead which comes with "running a software project". I do, however, run a Discord "server" which serves as both a news channel and a bug reporting and support channel. However, that has actually helped control the amount of demands I receive and by now users are aware that "I wrote Captain's Log for myself. It's useful to me and I package it for others to download and use too if they want to." - and that's the basis on which I release that application. I'll also take note of suggestions on the "#wishlist" channel and if I agree that a particular "wish" is something I'd like to see in the application then it may eventually get added. All the above, including the time I spend on looking at the Discord stuff, I provide on my time. I receive very little donations and only on a once in a blue moon basis.
- Jiro 5y ago
  All I said is that, since most projects accept bug reports, if you don't, you should say "this project doesn't accept bug reports" rather than complaining that people have expectations that after all, are correct for the vast majority of projects. Is that really so hard?
  - deleted 5y ago
    [deleted]
scarygliders 5y ago
>he should explicitly say "I don't take bug reports" in a reasonably obvious place, out of common courtesy. He did. In two very good and explanatory blog posts. The software license also states that there is no warranty implied etc. etc. If that's not enough information then I don't know what is.
- Jiro 5y ago
  I went to his download page. It doesn't say "we don't take bug reports". If he only wants to prevent bug reports from people who read his blog, saying it in the blog may be useful. But he probably wants to prevent bug reports from everyone who downloads it, in which case common sense says to put it on the downloads page. >The software license also states that there is no warranty implied etc. etc. The vast majority of open source projects have this in their license and they still take bug reports. The point is that his project is different from the default way in which most open source projects behave. People are inherently going to assume his project is typical, because most projects are typical. The fact that people do this doesn't mean they're clueless; it means that he isn't communicating well. He shouldn't expect other people to treat his project like an atypical one unless he says, front and center, that it's atypical.

by Jiro 5y ago

chiefalchemist 5y ago

Yes and no. The issue seems to be, these aren't true bug reports but support tickets pretending to be otherwise. The creator also mentions docs. If people try to save time (i.e., time is money) and don't read the docs but they want support. Well, there should be a fee for that. As we all know, ultimately, nothing is free.

hackerfromthefu 5y ago
Maybe the default, or at least a common mode, for open source should be user pays for support time. This includes lodging a ticket at $50 or whatever (for time for triage) - and then developers can add a price to action a ticket if they choose. The developer could also refund the ticket fee if it's a truly valuable bug reports. Github UI should make this as frictionless as possible. This would make it alright for users wanting support rather that adding bug reports, plus provide the much lamented missing income stream for open source. It would also have the effect of winnowing the incredible bulk of open source to emphasize truly useful projects, that people are willing to pay some dollars for. Obviously there's issues, such as not all economic level countries could participate, and surely others. Yet it seems to be a solution for multiple of of the commonly expressed pain points around open source.

massysett 5y ago

This attitude is why I don’t share much software anymore, even if I spent a lot of time developing it and someone else might find it useful. All it takes is someone claiming I’m being “deliberately misleading” (even though the license explicitly says “this software is provided as is without warranty of any kind, express or implied”) and for that someone to hire a lawyer. At that point I’ve lost. It doesn’t matter that the claim is baseless. This only saddens me a bit because there are so many people out there sharing software that nowadays my meager contributions won’t be missed. However I do wonder how much truly useful software does not get shared due to these liability concerns. A corporation has to weigh the goodwill they get from sharing software versus the potential ire of angry self-entitled people who think they are entitled to free support and extra disclaimers beyond those in the license. Why bother?

scarygliders 5y ago
When I embarked on my 3rd party application for Elite: Dangerous, I made the decision very early on, not to open source it, even though I use Python libraries etc. which are. It also uses PySide under the LGPL. The reason I did that was because I did not want the extra overhead which comes with "running a software project". I do, however, run a Discord "server" which serves as both a news channel and a bug reporting and support channel. However, that has actually helped control the amount of demands I receive and by now users are aware that "I wrote Captain's Log for myself. It's useful to me and I package it for others to download and use too if they want to." - and that's the basis on which I release that application. I'll also take note of suggestions on the "#wishlist" channel and if I agree that a particular "wish" is something I'd like to see in the application then it may eventually get added. All the above, including the time I spend on looking at the Discord stuff, I provide on my time. I receive very little donations and only on a once in a blue moon basis.
Jiro 5y ago
All I said is that, since most projects accept bug reports, if you don't, you should say "this project doesn't accept bug reports" rather than complaining that people have expectations that after all, are correct for the vast majority of projects. Is that really so hard?
- deleted 5y ago
  [deleted]

scarygliders 5y ago

>he should explicitly say "I don't take bug reports" in a reasonably obvious place, out of common courtesy. He did. In two very good and explanatory blog posts. The software license also states that there is no warranty implied etc. etc. If that's not enough information then I don't know what is.

Jiro 5y ago
I went to his download page. It doesn't say "we don't take bug reports". If he only wants to prevent bug reports from people who read his blog, saying it in the blog may be useful. But he probably wants to prevent bug reports from everyone who downloads it, in which case common sense says to put it on the downloads page. >The software license also states that there is no warranty implied etc. etc. The vast majority of open source projects have this in their license and they still take bug reports. The point is that his project is different from the default way in which most open source projects behave. People are inherently going to assume his project is typical, because most projects are typical. The fact that people do this doesn't mean they're clueless; it means that he isn't communicating well. He shouldn't expect other people to treat his project like an atypical one unless he says, front and center, that it's atypical.