3 ms·

> I think you've now answered your "is this hard to do?"... Did i buy the product "as is"? If it is an open source product then i agree with you, the product i

> I think you've now answered your "is this hard to do?"... Did i buy the product "as is"? If it is an open source product then i agree with you, the product is provided as is. However, in my mind this is not the case with a commerical products. When I buy something, whether it is software, a car or a a washing machine i have a contract that outlines what i am buying. If the product contains bugs/manufacturing defects/etc. then i expect the manufacturer to either fix those or refund me. In many countries this might even be legally required (Look for Gewährleistung/Produkthaftung in German speaking countries). I am not asking for features. I am not asking you to make the product better than what I bought. I discovered a defect that was caused by the manufacturer, not obvious at the time of purchase and as such the product does not match what i ordered from the manufacturer. I am asking you to provide to me exactly on what we agreed upon in our contract. If a developer cannot handle that and wants to distribute their software "as is" that's fine, but that will result in my willingness to pay being lower. If I buy a product I expect that product to perform as was promised. If it does not and the manufacturer refuses to work with me then it's a breach or contract.

mbesto 4y ago
> If the product contains bugs/manufacturing defects/etc. then i expect the manufacturer to either fix those or refund me. This analogy doesn't work with software. If you put your fridge in your house and your power goes out, you can very clearly see that your fridge is inoperable because of your power, not the fridge. Now let's try this with software: - The software you buy supports Linux v16 but not v18. You upgrade to v18 not knowing and not your software is broken. But the software was sold to you to support v16 and not v18. - The software you buy supports API connections to Twilio. In the docs it says "easy to use extensible API for all SMS providers". Twilio discontinues its v1 API endpoint but your software only supports v1 and not v2. You decide to migrate to Plivo and everything works except for one API call that is used once every 3 months. And on and on and on...see the point? > I am asking you to provide to me exactly on what we agreed upon in our contract. Great, now the developer not only has to be a "good developer" but also an expert in contract writing (or has a lawyer that is). Or worse, the lawyer and developer must be completely and harmoniously in sync about product functionality and the contractually nature that you, the client, originally decided to sign the contract with. Note - In case you are unaware, software contracts are notoriously difficult to do well (see Google/Oracle debacle). > If I buy a product I expect that product to perform as was promised. If it does not and the manufacturer refuses to work with me then it's a breach or contract. I think you're going to find the more and more you explain your position the more and more you'll see that "why is this so hard" is truly...hard.
- 7steps2much 4y ago
  Those aren't manufacturing defects. They are all changes of dependencies that should be made clear in the contract anyways. I have to admit that i am not too familiar with how Linux versioning works (more of a windows environment guy), but if I buy software that was developed for windows 7, that stops working on windows 10 then it's obviously not a manufacturing defect. That's me changing to OS to a none supported one. I believe that "System Requirements" is a fair section for software to have. And assuming that i was informed before hand that the software depends on Twilio API version X.Y i won't see those changes as a manufacturing defect either. In my opinion, manufacturing defects are things such as: - the software corrupting data during normal operation - the software behaving differently than specified in the documentation - the software not handling edge cases correctly > easy to use extensible API for all SMS providers Don't ever use that language within your technical/legal documents. It's fine for marketing, but when it comes to specifications always be specific. If you write something like this, but not what Providers/API in particular you are using/offering then don't be surprised if I am annoyed when your software stops working. After all I literally had no way of knowing what you supported, you didn't give me that very specific information.
  - mbesto 4y ago
    I don't understand why you responded to those two specific examples, I simply made them up because they were two plausible cases for "the environment changes and your contract needs a whole bunch of if/then statements to allow for them under the rules you've created to be successful and find so simple". I'm still amazed your not getting the point yet, which is: - Think really hard about every possible permutation license software could encounter and then multiply that by 100x and that's how you would need to structure this imaginary contract you keep referring to. - Said contract would be expensive and require a very technically knowledgable lawyer (see my reference to Google/Oracle which you conveniently glossed over). In case you are unaware: https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_.... It's mind boggling to me that software developers (which, based on your language, I presume you are) understand the intricacies and complexities of software development, yet are so hand wavy about the realities of busy "see its just so easy...".

mbesto 4y ago

> If the product contains bugs/manufacturing defects/etc. then i expect the manufacturer to either fix those or refund me. This analogy doesn't work with software. If you put your fridge in your house and your power goes out, you can very clearly see that your fridge is inoperable because of your power, not the fridge. Now let's try this with software: - The software you buy supports Linux v16 but not v18. You upgrade to v18 not knowing and not your software is broken. But the software was sold to you to support v16 and not v18. - The software you buy supports API connections to Twilio. In the docs it says "easy to use extensible API for all SMS providers". Twilio discontinues its v1 API endpoint but your software only supports v1 and not v2. You decide to migrate to Plivo and everything works except for one API call that is used once every 3 months. And on and on and on...see the point? > I am asking you to provide to me exactly on what we agreed upon in our contract. Great, now the developer not only has to be a "good developer" but also an expert in contract writing (or has a lawyer that is). Or worse, the lawyer and developer must be completely and harmoniously in sync about product functionality and the contractually nature that you, the client, originally decided to sign the contract with. Note - In case you are unaware, software contracts are notoriously difficult to do well (see Google/Oracle debacle). > If I buy a product I expect that product to perform as was promised. If it does not and the manufacturer refuses to work with me then it's a breach or contract. I think you're going to find the more and more you explain your position the more and more you'll see that "why is this so hard" is truly...hard.

7steps2much 4y ago
Those aren't manufacturing defects. They are all changes of dependencies that should be made clear in the contract anyways. I have to admit that i am not too familiar with how Linux versioning works (more of a windows environment guy), but if I buy software that was developed for windows 7, that stops working on windows 10 then it's obviously not a manufacturing defect. That's me changing to OS to a none supported one. I believe that "System Requirements" is a fair section for software to have. And assuming that i was informed before hand that the software depends on Twilio API version X.Y i won't see those changes as a manufacturing defect either. In my opinion, manufacturing defects are things such as: - the software corrupting data during normal operation - the software behaving differently than specified in the documentation - the software not handling edge cases correctly > easy to use extensible API for all SMS providers Don't ever use that language within your technical/legal documents. It's fine for marketing, but when it comes to specifications always be specific. If you write something like this, but not what Providers/API in particular you are using/offering then don't be surprised if I am annoyed when your software stops working. After all I literally had no way of knowing what you supported, you didn't give me that very specific information.
- mbesto 4y ago
  I don't understand why you responded to those two specific examples, I simply made them up because they were two plausible cases for "the environment changes and your contract needs a whole bunch of if/then statements to allow for them under the rules you've created to be successful and find so simple". I'm still amazed your not getting the point yet, which is: - Think really hard about every possible permutation license software could encounter and then multiply that by 100x and that's how you would need to structure this imaginary contract you keep referring to. - Said contract would be expensive and require a very technically knowledgable lawyer (see my reference to Google/Oracle which you conveniently glossed over). In case you are unaware: https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_.... It's mind boggling to me that software developers (which, based on your language, I presume you are) understand the intricacies and complexities of software development, yet are so hand wavy about the realities of busy "see its just so easy...".