4 ms·

> I said their READMEs should accurately represent the state of the project. The state of expectations is usually in the LICENSE file, not in the README. But i

by jjav 6mo ago

> I said their READMEs should accurately represent the state of the project. The state of expectations is usually in the LICENSE file, not in the README. But it's there in the repository, in most cases. I do agree that some maintainers forget to include the LICENSE file (or equivalent), which is a mistake. The terms of use are quite important.

hnlmorg 6mo ago
> The state of expectations is usually in the LICENSE file, not in the README. No it’s not. LICENSE tells you what you can do with the code. It doesn’t tell you the state of code. Again, I need to reiterate my point that I’m talking about whether the code is beta, tested, etc. It costs nothing for a maintainer to specify how complete a code base is. It’s then up to the consumers of that package to decide if they want to use it, contribute back or just fork it. All I’m saying is too many GitHub repos are written for CVs; as if they’re meant to be consumed by Google. If something is a weekend project then just be honest and say “this is a weekend project written to solve my specific use case but PRs are welcome”. Thats better than having long blurbs that refer to the solo developer as “we” and all the other BS people stick into their READMEs to try and make their project sound better than it actually is. All I’m asking for is a little more pragmatism and honesty in READMEs. It’s no extra effort. It’s no extra cost. And I shouldn’t have to donate to projects just to ensure they don’t lie to me.
- jjav 6mo ago
  It is interesting how every time this topic comes up it ends up with people for the most part in one of two camps: either the license is meant to be taken literally, or those who believe otherwise. Of all the files in a repo, the LICENSE file is the one most important to take literally since it is a legal document. So when it says something like (this from 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. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. That is actually exactly what it means. There is specifically not even an implied suggestion that the software is suitable for your use. If you want any kind of guarantee of the code being of any use to you, sign a contract and pay for it. Unless you pay for that contract, nobody owes you any kind of hint as to whether the code is useful for anything. It very clearly says so in the LICENSE file.
  - deleted 6mo ago
    [deleted]
  - hnlmorg 6mo ago
    It really isn’t much to ask people not to bullshit in their own README. That’s literally all I’m asking for. If you don’t want to offer software guarantees then don’t write your README like you offer it. It’s really that simple. And your comment that I should pay every…single…maintainer of every…single…project on GitHub, just for them to disclose whether or not their project is experimental… well that’s just insane and completely misses the point of open source. If we are talking about businesses relying on open source libraries then that would be a different matter. But not ever fscking thing being built is a VC-backed startup. I say all of this as an open source maintainer. Just be honest in your READMEs. A little honesty in the README costs nothing and we should be expecting more of it. And suggesting we lock that honesty behind a paywall is possibly the worst idea for open source imaginable. That simply isn’t the right way to monetise open source. Edit: just to add, even if we were talking about software quality (which we wasn’t) paying for software doesn’t guarantee to you a better product. I could name a multitude of commercial solutions that I gave up on because the open source alternative was at least equivalent. But often even superior. And that’s before we talk about then enshitification phenomena. Edit 2: sorry for all the edits. I should have just waited until I had proper time to reply calmly rather than commenting while doing chores and stuff around the house. My bad.
    - jjav 6mo ago
      I'm not suggesting honesty should be behind a paywayll. Honesty should be upfront and it already is, in the license. The license (most, anyway) clearly state the software is not necessarily suitable for any purpose and that's all you get. If you require a higher level of confidence than none, then you should be paying for a support contract. All I can say without being repetitive is that if you expect more than nothing when the license specifically says all you can expect is nothing, you might be disappointed more often than not.
      - hnlmorg 6mo ago

by jjav 6mo ago

hnlmorg 6mo ago

> The state of expectations is usually in the LICENSE file, not in the README. No it’s not. LICENSE tells you what you can do with the code. It doesn’t tell you the state of code. Again, I need to reiterate my point that I’m talking about whether the code is beta, tested, etc. It costs nothing for a maintainer to specify how complete a code base is. It’s then up to the consumers of that package to decide if they want to use it, contribute back or just fork it. All I’m saying is too many GitHub repos are written for CVs; as if they’re meant to be consumed by Google. If something is a weekend project then just be honest and say “this is a weekend project written to solve my specific use case but PRs are welcome”. Thats better than having long blurbs that refer to the solo developer as “we” and all the other BS people stick into their READMEs to try and make their project sound better than it actually is. All I’m asking for is a little more pragmatism and honesty in READMEs. It’s no extra effort. It’s no extra cost. And I shouldn’t have to donate to projects just to ensure they don’t lie to me.

jjav 6mo ago
It is interesting how every time this topic comes up it ends up with people for the most part in one of two camps: either the license is meant to be taken literally, or those who believe otherwise. Of all the files in a repo, the LICENSE file is the one most important to take literally since it is a legal document. So when it says something like (this from 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. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. That is actually exactly what it means. There is specifically not even an implied suggestion that the software is suitable for your use. If you want any kind of guarantee of the code being of any use to you, sign a contract and pay for it. Unless you pay for that contract, nobody owes you any kind of hint as to whether the code is useful for anything. It very clearly says so in the LICENSE file.
- deleted 6mo ago
  [deleted]
- hnlmorg 6mo ago
  It really isn’t much to ask people not to bullshit in their own README. That’s literally all I’m asking for. If you don’t want to offer software guarantees then don’t write your README like you offer it. It’s really that simple. And your comment that I should pay every…single…maintainer of every…single…project on GitHub, just for them to disclose whether or not their project is experimental… well that’s just insane and completely misses the point of open source. If we are talking about businesses relying on open source libraries then that would be a different matter. But not ever fscking thing being built is a VC-backed startup. I say all of this as an open source maintainer. Just be honest in your READMEs. A little honesty in the README costs nothing and we should be expecting more of it. And suggesting we lock that honesty behind a paywall is possibly the worst idea for open source imaginable. That simply isn’t the right way to monetise open source. Edit: just to add, even if we were talking about software quality (which we wasn’t) paying for software doesn’t guarantee to you a better product. I could name a multitude of commercial solutions that I gave up on because the open source alternative was at least equivalent. But often even superior. And that’s before we talk about then enshitification phenomena. Edit 2: sorry for all the edits. I should have just waited until I had proper time to reply calmly rather than commenting while doing chores and stuff around the house. My bad.
  - jjav 6mo ago
    I'm not suggesting honesty should be behind a paywayll. Honesty should be upfront and it already is, in the license. The license (most, anyway) clearly state the software is not necessarily suitable for any purpose and that's all you get. If you require a higher level of confidence than none, then you should be paying for a support contract. All I can say without being repetitive is that if you expect more than nothing when the license specifically says all you can expect is nothing, you might be disappointed more often than not.
    - hnlmorg 6mo ago