5 ms·

A maintainer position for a software project is like any position or role, in say, a charity. You aren’t technically forced to do the work, but the charity ann

by teddyh 3y ago

A maintainer position for a software project is like any position or role, in say, a charity. You aren’t technically forced to do the work, but the charity announces publicly (on its web site, for instance) that the work will be done, and people expect it to be done. If you do not feel up to doing it anymore, you owe it to other people (who expect the work to be done) to announce your retirement and hand the position over to new people. Any project which is not a going concern should: A: Not, IMHO, be called a ”project” B: Be clearly labelled, in its public-facing information, as being offered as-is, without any implied updates or future development.

candiddevmike 3y ago
> B: Be clearly labelled, in its public-facing information, as being offered as-is, without any implied updates or future development. Pretty sure every open source license includes this in the warranty line...
- teddyh 3y ago
  No, that’s the legal warranty disclaimer. It has nothing to do with support, security fixes, or future development.
  - candiddevmike 3y ago
    What do you think a warranty is?
    - teddyh 3y ago
      A warranty is about the code which already exists, and whether the code is fit for a particular purpose, etc. (all legal terms). The warranty disclaimer in free software licences all say basically “Although this specific version of the software is meant to be helpful to you for a certain purpose, you can’t sue the developer if there’s a bug or an omitted feature, since we don’t make any guarantee that it will work.” But this is not what I was talking about. I was talking about disclaiming any implied support, security bugfixes, and future development, all three of which are usually heavlily implied (or outright stated) to be available in official project information (such as on an official web site).
      - simbolit 3y ago
        You are saying I should add, to my free lemonade stand, a disclaimer: I will not help you with drinking the free lemonade; if the lemonade is too sour for you I will not be providing extra sugar; and I will not make free lemonade tomorrow. Can you give me one or two examples of official OSS websites where these are heavily implied or outright stated? Do you mean anything beyond a roadmap?
        teddyh 3y ago
        You don’t need a disclaimer for something which nobody reasonably expects. Although an “available today only” notice might be useful, since people might reasonably expect a lemonade stand to be available the next day. Regarding examples, basically any software project web site which talks about the project as an ongoing thing, gives links to where “new releases” will be available. Stuff like that. All that implies that the software is actively developed and will be developed for at least the near future.
        simbolit 3y ago
        Let's look at one of my favorite open source projects: https://github.com/gorhill/uBlock https://github.com/gorhill/uBlock Does gorhill need a disclaimer, as you propose? If so, please tell me specifically, where you are reading any "implied support, security bugfixes, and future development". I am not purposefully complicated, I just feel your "implied" is doing a lot of work, and I want to see what that really means. I don't see the implication, but perhaps I am blind. So please enlighten me. (If ublock doesn't fit your argument, please give another example of your liking.).
        teddyh 3y ago
        Firstly, uBlock doesn’t really talk about its own updates, since all the frequent updates it needs are provided by its filter lists. It’s basically an app store, a little bit like F-Droid. And you’re right, I can find no explicit language that either states or implies any of the things i listed. But think of it this way. There is a prominent link to their list of releases, <https://github.com/gorhill/uBlock/releases https://github.com/gorhill/uBlock/releases>. From what I can tell, the releases vary from a few days apart to maybe a month apart, with the most recent release being yesterday. What would you think if, say, six months from now, there still wasn’t a new release? No bugs fixed? And, when asked about the absence of these things, if the developer’s answer would be “You’re whiny and entitled, I have no legal obligation to do anything, read the license LOL.”? I mean, he’d be technically correct, it would be legal for him to do this. But would it be OK? What I am arguing is that it would not be OK, and that users do have legitimate reasonable expectations of any project that presents itself as being active; i.e. fixing bugs, security holes, and implementing new features. Users are not “entitled” when expecting these things.
- deleted 3y ago
  [deleted]
growse 3y ago
> B: Be clearly labelled, in its public-facing information, as being offered as-is, without any implied updates or future development. So if I had a text file in the root of my repo that said: THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. Would that be sufficient?
- teddyh 3y ago
  That text does not disclaim support, security bugfixes, and future development. On the contrary, all three of those things are probably either heavlily implied or outright stated to be available on the project web site.
  - growse 3y ago
    You and I are reading "SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION." very differently.
    - teddyh 3y ago
      At best, that only covers bug fixes. And, as I said, bug fixes are usually implied to be available in future releases.
      - andrewjl 3y ago
        > At best, that only covers bug fixes. And, as I said, bug fixes are usually implied to be available in future releases Can you explain how you got to that interpretation from that phrasing? > SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. And how is future development and / or support not covered under servicing of that clause?
sublimefire 3y ago
This is ridiculous because there is no legal or moral obligation from the creator to say anything except maybe adding the license. You as a user can use the given software and probably modify yourself at will due to the permissive license which is the main advantage of OSS. When I get stuff from the charity I do not expect them to provide a return policy and customer service, your analogy is moronic because the thing was done already and you can come back and get a newer thing if it is ready. The problem is that the barrier to use any software is so low that it attracts people who have no clue and demand support. I am not talking about you, even the larger companies always mention a wish to force smaller developers to patch security issues for free, this is an issue in supply chain security at the moment. The gist is that you can fix it yourself.
- teddyh 3y ago
  To use any software in these modern times, it’s not enough to simply get a snapshot and use that forever. That time has long gone. Users need updates for whenever the inevitable incompatibilities arise, and since switching to some other software is a lot of work, users need to be able to depend on regular, timely updates. Indeed, many people choose what software they use solely on that basis. Therefore, any software project which presents itself as usable is implying that the project will provide these things. (This is a bit like how a stable economy depends on there being a crucial threshold number of long-term, high-trust relationships. You cannot have a functioning economy when everybody is always backstabbing everybody else. Similarly, you arguably cannot have a functioning Open Source ecosystem if everybody is just throwing code over the wall all the time.) > The problem is that the barrier to use any software is so low that it attracts people who have no clue and demand support. I think this phenomenon is caused by: 1. Some users being a bit whiny and entitled, just like some people are rude to waiters. Some have been taught and brought up to behave this way, and others have just gotten into bad habits. 2. Many developers being overly defensive when presented with legitimate complaints from users. This is just human nature, harmful as it may be. 3. Due to 2., users exaggerate and act rudely when reporting complaints, because they expect pushback from developers. This then exacerbates 2. again, leading to a vicious cycle. Some developers who are burnt out by 1., and are not realizing what is going on, are, as a way of psychological self-defense, adopting an attitude of “I don’t care about you users, you’ll get nothing and you’ll ******* like it.” This then necessitates the same developers to argue that all users who expect anything are merely “entitled”, because if any user’s expectations would be reasonable, then the developer’s attitude would be unwarranted, and the developers feel that they need that attitude for their own well-being. None of this is new; the old jargon word “lusers” was frequently used in ages past with contempt and disdain for users.
jjav 3y ago
> Be clearly labelled, in its public-facing information, as being offered as-is If you read the license (for most licenses anyway), that info is clearly right there.

by teddyh 3y ago

candiddevmike 3y ago

> B: Be clearly labelled, in its public-facing information, as being offered as-is, without any implied updates or future development. Pretty sure every open source license includes this in the warranty line...

teddyh 3y ago
No, that’s the legal warranty disclaimer. It has nothing to do with support, security fixes, or future development.
- candiddevmike 3y ago
  What do you think a warranty is?
  - teddyh 3y ago
    A warranty is about the code which already exists, and whether the code is fit for a particular purpose, etc. (all legal terms). The warranty disclaimer in free software licences all say basically “Although this specific version of the software is meant to be helpful to you for a certain purpose, you can’t sue the developer if there’s a bug or an omitted feature, since we don’t make any guarantee that it will work.” But this is not what I was talking about. I was talking about disclaiming any implied support, security bugfixes, and future development, all three of which are usually heavlily implied (or outright stated) to be available in official project information (such as on an official web site).
    - simbolit 3y ago
      You are saying I should add, to my free lemonade stand, a disclaimer: I will not help you with drinking the free lemonade; if the lemonade is too sour for you I will not be providing extra sugar; and I will not make free lemonade tomorrow. Can you give me one or two examples of official OSS websites where these are heavily implied or outright stated? Do you mean anything beyond a roadmap?
      - teddyh 3y ago
        You don’t need a disclaimer for something which nobody reasonably expects. Although an “available today only” notice might be useful, since people might reasonably expect a lemonade stand to be available the next day. Regarding examples, basically any software project web site which talks about the project as an ongoing thing, gives links to where “new releases” will be available. Stuff like that. All that implies that the software is actively developed and will be developed for at least the near future.
        simbolit 3y ago
        Let's look at one of my favorite open source projects: https://github.com/gorhill/uBlock https://github.com/gorhill/uBlock Does gorhill need a disclaimer, as you propose? If so, please tell me specifically, where you are reading any "implied support, security bugfixes, and future development". I am not purposefully complicated, I just feel your "implied" is doing a lot of work, and I want to see what that really means. I don't see the implication, but perhaps I am blind. So please enlighten me. (If ublock doesn't fit your argument, please give another example of your liking.).
        teddyh 3y ago
        Firstly, uBlock doesn’t really talk about its own updates, since all the frequent updates it needs are provided by its filter lists. It’s basically an app store, a little bit like F-Droid. And you’re right, I can find no explicit language that either states or implies any of the things i listed. But think of it this way. There is a prominent link to their list of releases, <https://github.com/gorhill/uBlock/releases https://github.com/gorhill/uBlock/releases>. From what I can tell, the releases vary from a few days apart to maybe a month apart, with the most recent release being yesterday. What would you think if, say, six months from now, there still wasn’t a new release? No bugs fixed? And, when asked about the absence of these things, if the developer’s answer would be “You’re whiny and entitled, I have no legal obligation to do anything, read the license LOL.”? I mean, he’d be technically correct, it would be legal for him to do this. But would it be OK? What I am arguing is that it would not be OK, and that users do have legitimate reasonable expectations of any project that presents itself as being active; i.e. fixing bugs, security holes, and implementing new features. Users are not “entitled” when expecting these things.
deleted 3y ago
[deleted]

growse 3y ago

> B: Be clearly labelled, in its public-facing information, as being offered as-is, without any implied updates or future development. So if I had a text file in the root of my repo that said: THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. Would that be sufficient?

teddyh 3y ago
That text does not disclaim support, security bugfixes, and future development. On the contrary, all three of those things are probably either heavlily implied or outright stated to be available on the project web site.
- growse 3y ago
  You and I are reading "SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION." very differently.
  - teddyh 3y ago
    At best, that only covers bug fixes. And, as I said, bug fixes are usually implied to be available in future releases.
    - andrewjl 3y ago
      > At best, that only covers bug fixes. And, as I said, bug fixes are usually implied to be available in future releases Can you explain how you got to that interpretation from that phrasing? > SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. And how is future development and / or support not covered under servicing of that clause?

sublimefire 3y ago

This is ridiculous because there is no legal or moral obligation from the creator to say anything except maybe adding the license. You as a user can use the given software and probably modify yourself at will due to the permissive license which is the main advantage of OSS. When I get stuff from the charity I do not expect them to provide a return policy and customer service, your analogy is moronic because the thing was done already and you can come back and get a newer thing if it is ready. The problem is that the barrier to use any software is so low that it attracts people who have no clue and demand support. I am not talking about you, even the larger companies always mention a wish to force smaller developers to patch security issues for free, this is an issue in supply chain security at the moment. The gist is that you can fix it yourself.

teddyh 3y ago
To use any software in these modern times, it’s not enough to simply get a snapshot and use that forever. That time has long gone. Users need updates for whenever the inevitable incompatibilities arise, and since switching to some other software is a lot of work, users need to be able to depend on regular, timely updates. Indeed, many people choose what software they use solely on that basis. Therefore, any software project which presents itself as usable is implying that the project will provide these things. (This is a bit like how a stable economy depends on there being a crucial threshold number of long-term, high-trust relationships. You cannot have a functioning economy when everybody is always backstabbing everybody else. Similarly, you arguably cannot have a functioning Open Source ecosystem if everybody is just throwing code over the wall all the time.) > The problem is that the barrier to use any software is so low that it attracts people who have no clue and demand support. I think this phenomenon is caused by: 1. Some users being a bit whiny and entitled, just like some people are rude to waiters. Some have been taught and brought up to behave this way, and others have just gotten into bad habits. 2. Many developers being overly defensive when presented with legitimate complaints from users. This is just human nature, harmful as it may be. 3. Due to 2., users exaggerate and act rudely when reporting complaints, because they expect pushback from developers. This then exacerbates 2. again, leading to a vicious cycle. Some developers who are burnt out by 1., and are not realizing what is going on, are, as a way of psychological self-defense, adopting an attitude of “I don’t care about you users, you’ll get nothing and you’ll ******* like it.” This then necessitates the same developers to argue that all users who expect anything are merely “entitled”, because if any user’s expectations would be reasonable, then the developer’s attitude would be unwarranted, and the developers feel that they need that attitude for their own well-being. None of this is new; the old jargon word “lusers” was frequently used in ages past with contempt and disdain for users.

jjav 3y ago

> Be clearly labelled, in its public-facing information, as being offered as-is If you read the license (for most licenses anyway), that info is clearly right there.