4 ms·

The first example is so much cringe that had to stop reading. Just because you made your source code available does not mean I'll do your QA for free. I might,

The first example is so much cringe that had to stop reading. Just because you made your source code available does not mean I'll do your QA for free. I might, if I think it's worth it... but if you haven't made it worth it, just forget it.

esquire_900 6y ago
I had the almost complete opposite reaction: the user is telling something isn't working, the author interprets that he needs to fix something for the specific use case of the user. The user might have found a bug or edge case that's useful for the authors own usage. Perhaps even something the user doesn't need to function, but just stumbled upon. Not saying that this is often the case or the author should dive into every question (the author doesn't have any obligations at all) - there are just too many ungrounded assumptions in the interpretation.
fxtentacle 6y ago
I don't see that part in the article.
mschuster91 6y ago
> Just because you made your source code available does not mean I'll do your QA for free Personally, I distinguish between projects by individuals running it as a hobby/side project and projects run by big organizations for profit. If it's something like Docker, DC/OS or Kubernetes and elementary functionality is borked / documentation is flat out wrong/outdated, yes I'll rise a stink because obviously you managed to fuck up on QA and expect that the open-source community will find and even fix your most egregious bugs for free. For individual projects I may if I have the time actually do a deep dive into an issue because it's likely that whatever I'm hitting is because I'm using the project in a manner that the original author doesn't and therefore if I want to get it running I can either pay the author a couple of beers or get a somewhat reasonable patch together so the author can either take it as-is or adapt to their coding style but at least doesn't have to think about the issue and its cause.
- watwut 6y ago
  If you are raising stint (as opposed to politely report bug as most people do), you are in fact creating culture where people act the same way everywhere. Because other people see what you do and who imitate it. And developers of something like docker are less free to answer in kind.
  - mschuster91 6y ago
    Since the advent of fast Internet, software quality has gone so far downhill it hurts. Unlike almost all current graduates I'm old enough to know the "old world" - back when I had my first computer, patches were either unheard of at all (cartridges with mask ROM programming) or had to be distributed on CD-ROMs - so software vendors were all but forced by the realities of the market to do proper QA and deliver a product / game that was reasonably bug-free. These days? It's usual to have games that require multi-GB patches upon release day and for weeks if not months afterwards. It's common wisdom to avoid new OS X releases for at least half a year until Apple and the software vendors (Adobe!) ironed out the worst critical bugs - and that's despite many months of pre-release collaboration between Apple and the biggest vendors. The entire culture of making and delivering software is rotten because QA is seen as a pure "cost center" instead of avoiding actual cost of shipping physical replacement items to angry customers. Sorry, but without raising a stink when corporate entities fail at basic QA the situation won't ever change and I'm sick of playing the free beta tester for multi billion dollars worth corporations that could afford proper QA.
    - watwut 6y ago
      1.) Corporate entities don't care about your stint in issue tracker system. One small individual programmers do. 2.) Not a single massive game you mention is open source or have public issues tracker. 3.) You should know full well that multi GB of anything is all about art work and pretty pictures gamer dudebros pay for.
onion2k 6y ago
The author isn't asking you to QA his app. He's saying that if the app doesn't work for you then you need to incentivize him to look at why and to change it so that it does. You're very welcome to just not use the app instead, or to fix it yourself. I admire the principle behind his stance, because supporting people for free is horrible. I'm not sure I'd ever have the guts to do it myself though.
einpoklum 6y ago
> Just because you made your source code available does not mean I'll do your QA for free. I wrote some software to address a need; and made the source available. I made some effort to make it usable to others - but not a huge amount of it. Now, it's your turn to do some free QA to make that software usable for you, and more-usable in general. So the motivations here are: 1. Your own need / self-interest. 2. The public benefit.
- AntiImperialist 6y ago
  OR, you wrote the software that you don't need or use it yourself specifically with the intention to make money selling support and customization and released it as open source because you want to get users who use it for free to do the QA, Development and marketing for you for free. I, as a random user, can't know which is which or care and most of the time can't be bothered.
  - einpoklum 6y ago
    You're right that the developer should make it clearer which case it is.

esquire_900 6y ago

I had the almost complete opposite reaction: the user is telling something isn't working, the author interprets that he needs to fix something for the specific use case of the user. The user might have found a bug or edge case that's useful for the authors own usage. Perhaps even something the user doesn't need to function, but just stumbled upon. Not saying that this is often the case or the author should dive into every question (the author doesn't have any obligations at all) - there are just too many ungrounded assumptions in the interpretation.

fxtentacle 6y ago

I don't see that part in the article.

mschuster91 6y ago

> Just because you made your source code available does not mean I'll do your QA for free Personally, I distinguish between projects by individuals running it as a hobby/side project and projects run by big organizations for profit. If it's something like Docker, DC/OS or Kubernetes and elementary functionality is borked / documentation is flat out wrong/outdated, yes I'll rise a stink because obviously you managed to fuck up on QA and expect that the open-source community will find and even fix your most egregious bugs for free. For individual projects I may if I have the time actually do a deep dive into an issue because it's likely that whatever I'm hitting is because I'm using the project in a manner that the original author doesn't and therefore if I want to get it running I can either pay the author a couple of beers or get a somewhat reasonable patch together so the author can either take it as-is or adapt to their coding style but at least doesn't have to think about the issue and its cause.

watwut 6y ago
If you are raising stint (as opposed to politely report bug as most people do), you are in fact creating culture where people act the same way everywhere. Because other people see what you do and who imitate it. And developers of something like docker are less free to answer in kind.
- mschuster91 6y ago
  Since the advent of fast Internet, software quality has gone so far downhill it hurts. Unlike almost all current graduates I'm old enough to know the "old world" - back when I had my first computer, patches were either unheard of at all (cartridges with mask ROM programming) or had to be distributed on CD-ROMs - so software vendors were all but forced by the realities of the market to do proper QA and deliver a product / game that was reasonably bug-free. These days? It's usual to have games that require multi-GB patches upon release day and for weeks if not months afterwards. It's common wisdom to avoid new OS X releases for at least half a year until Apple and the software vendors (Adobe!) ironed out the worst critical bugs - and that's despite many months of pre-release collaboration between Apple and the biggest vendors. The entire culture of making and delivering software is rotten because QA is seen as a pure "cost center" instead of avoiding actual cost of shipping physical replacement items to angry customers. Sorry, but without raising a stink when corporate entities fail at basic QA the situation won't ever change and I'm sick of playing the free beta tester for multi billion dollars worth corporations that could afford proper QA.
  - watwut 6y ago
    1.) Corporate entities don't care about your stint in issue tracker system. One small individual programmers do. 2.) Not a single massive game you mention is open source or have public issues tracker. 3.) You should know full well that multi GB of anything is all about art work and pretty pictures gamer dudebros pay for.

onion2k 6y ago

The author isn't asking you to QA his app. He's saying that if the app doesn't work for you then you need to incentivize him to look at why and to change it so that it does. You're very welcome to just not use the app instead, or to fix it yourself. I admire the principle behind his stance, because supporting people for free is horrible. I'm not sure I'd ever have the guts to do it myself though.

einpoklum 6y ago

> Just because you made your source code available does not mean I'll do your QA for free. I wrote some software to address a need; and made the source available. I made some effort to make it usable to others - but not a huge amount of it. Now, it's your turn to do some free QA to make that software usable for you, and more-usable in general. So the motivations here are: 1. Your own need / self-interest. 2. The public benefit.

AntiImperialist 6y ago
OR, you wrote the software that you don't need or use it yourself specifically with the intention to make money selling support and customization and released it as open source because you want to get users who use it for free to do the QA, Development and marketing for you for free. I, as a random user, can't know which is which or care and most of the time can't be bothered.
- einpoklum 6y ago
  You're right that the developer should make it clearer which case it is.