5 ms·

I use a lot of open source packages, and I’m immensely grateful to anyone who maintains one. I also want to mention that I donate whenever the option is availa

I use a lot of open source packages, and I’m immensely grateful to anyone who maintains one. I also want to mention that I donate whenever the option is available. However, here is my personal opinion that will most likely get downvoted to oblivion: if you are putting a tool out there for others to use (not just software but any tool), then you are responsible for its wellbeing and maintenance, regardless of whether you charge money for it. In my opinion, it is irresponsible to release something, anything, and then abandon it. If you don’t want to be responsible for it, for example if it’s a hobby project or something, keep the repo private. If you release it with the intention of maintaining it, and your circumstances change later, do your best to find another maintainer. If you want to charge money for it, do that. But if your attitude is gonna be “I’ll work on this when I want, however much I want, and you should just be grateful for what you get and deal with it” then, well, that’s where my sympathy and respect for you ends.

username223 8y ago
> if you are putting a tool out there for others to use (not just software but any tool), then you are responsible for its wellbeing and maintenance, regardless of whether you charge money for it. I think there's also room for software that's dumped on the internet like a free couch left on the sidewalk, but it should be treated similarly: probably full of bugs and not worth your time. I agree that software maintainers shouldn't feel entitled to gratitude without obligation.
detaro 8y ago
So the article writer became "maintainer" by virtue of being something like "the only person that currently cares". Should they have rejected access to the code and ceased contributions at that point, to not be irresponsible years later?
- teddyh 8y ago
  They might have taken over the role of maintainer, but if the level of involvment which the project required was too much for them, it would have been their duty as maintainer to declare the project moribund until a more active maintainer could be found. To keep the project active and looking alive is to mislead users and implicitly promise a level of support and development which they know they cannot uphold.
  - deleted 8y ago
    [deleted]
  - deleted 8y ago
    [deleted]
webmaven 8y ago
This really shouldn't be downvoted, as it is a valid stance (one I don't share, BTW, or not much). Human social instincts strongly push toward this position, informed (largely) by metaphors and similies rooted in excludable goods even when nonrivalrous (eg. the prototypical Commons). Software, though - and most especially Free Software - is part of another realm entirely, or at least verges on it: Things that largely grow, proliferate, and spread themselves, even if they do it through coopting human agency. Examples are stories, families, communities, ideologies, movements, hobbies, cultures, and most importantly, individual humans themselves. "If you save a life you become responsible for it" is one of the few succinct ways this has been expressed, which of course doesn't do much to delineate the obligation or its limits. But the sentiment is clear. To what extent can an author (of fiction or non-fiction) disclaim responsibility for their work if it takes on a quasi-life of its own? An artist for a work that is misappropriated? How difficult is it to disavow a family that you have broken with? An embarrassing ancestor who accumulated the family fortune through unsavory means? A child that has grown to become a notorious public enemy? Can a founder of a movement disavow its extremist fringes? Does a celebrity actually have any responsibility at all toward their fans? How difficult is it (or should it be) for a hobbyist to avoid being associated with those who share their hobby, but who also make the hobby unwelcoming to the Other? By now you must have a dozen objections to this post, of all the ways writing software is not like these things I've mentioned, but there is also something deeply similar, though it is difficult to articulate exactly what that is. An author of software, and more precisely a maintainer of software, is responsible in some sense for the nebulous thing that the group of people that software draws together is, even while also being a member of that same group. That the responsibility does not necessarily create much of an attendant obligation is not necessarily clear, when so many social customs are predicated on such obligations being implicit (at least). Even less clear is the extent to which such obligations, when voluntarily assumed, can then be discarded. An analogy may be helpful here: Having moved to a new city, and subsequent to joining some existing social group or club, you volunteered to take care of some aspect of a shared recreation (to bring the salad for a weekend picnic, for example), but you then discover that there are additional logistical and even financial costs involved that you didn't anticipate (the picnic starts much earlier than you're used to, the group includes many vegetarians and vegans who are used to having an extensive variety of salads at such occasions, etc.). So, having voluntarily assumed this obligation, but not having given what could be objectively called fully informed consent, to what extent are you still responsible for addressing the expectations of this group (as a group, and also as individuals) you're now disappointing? And how do the analogous obligations change (and grow) when you are (effectively) the founder of the group? This morass of interpersonal relationships is the sort of thing that being a software maintainer requires navigating, and the situation isn't made simpler just because the central artefact the group revolves around is some non-excludable, non-rivalrous software that is being created and maintained, especially when the name attached to the software is just such a rivalrous good. Disavowal of otherwise implicit responsibilities and obligations is something that seems to crop up more often in recent decades than previously, from IANAL and TINLA (or even IAAL, But Not Your Lawyer), to the increasingly commonplace "I Do Not Speak For My Employer". Such disavowals being (apparently) necessary, authoring and maintaining software clearly also strongly implies at least some responsibilities and obligations, at least as a great many humans perceive things, and it is worth discussing just what those are, as well as when and how to effectively disavow them when not appropriate. As I said at the outset, I personally feel the set of those obligations is smaller than the parent post states (neither software nor the community that forms around it is something that you are obliged to actively nurture), but my disagreement doesn't imply a downvote. It is a valid contribution to the debate on this topic.
jryb 8y ago
I don't understand the downvotes for this. I feel that by making something public and open source, there is an implicit assumption (unless otherwise stated) that the software is worth sharing. The problem is that this puts what I consider the right amount of responsibility squarely in the middle of a continuum: library authors shouldn't be totally free of obligations to others, but the insane abuse that people level against open source maintainers is also obviously unacceptable.
- watwut 8y ago
  This rule accepted in general would mean that all students who put their homework on github are doing something wrong. Or that all professionals who just play around technology or mini projects are required to keep them secret until they are totally sure they will maintain it forever. That is just not workable and overly limited. While owner can not expect gratitude, the "I’ll work on this when I want, however much I want, and you should just take it or leave it" is absolutely fine and should be fine. Just because it exists on the internet does not entitle the rest of the world to anything.
  - teddyh 8y ago
    Unlike what you seem to indicate, projects do imply a level of expected support and continual development by their projected image as given by their web pages, documentation, etc. If a developer/maintainer does not uphold this implied promise, users have a right to feel bamboozled.
  - enraged_camel 8y ago
    Students putting their homework on github is totally fine as long as they clearly state that in the readme.
    - watwut 8y ago
      So maybe assume no maintenance unless stated in readme.
- detaro 8y ago
teddyh 8y ago
I think I understand you completely, but I also think I know why you were downvoted. The problem is the implied promise of having a software project page on something like GitHub with descriptions, documentation, etc. This, in my mind, and probably yours too, implies a promise of future development, maintenance or at least security bug fixes. When such things are not forthcoming in a manner one might reasonably expect, we feel as though we have been cheated out of something we (rightly or wrongly) feel was promised to us. Maybe what would be useful would be some standard (and required!) marking for all software projects on what the current level of maintenance is. Is it Level 0. I wrote this in an afternoon and have no plans to ever look at it again — use at your own risk. all through Level X. This project is under active development and also has maintainers for a stable branch, which also receives security bug fixes in a timely manner. In short, what I think is actually irresponsible is for projects to look like they are close to level X but then have maintainers behave like they are at a much lower level, and who think that any level of behavior is OK since they don't get paid and haven't personally promised anything. It would be better for all involved if the expected (approximate, of course) level of maintenance could be explicitly announced – this might make it clear to users what level they can expect, and make it clear to maintainers what level of involvment is expected of them to be able to call themselves “maintainers”.
- deleted 8y ago
  [deleted]
cerberusss 8y ago
Sometimes I open source small libraries. When I get feature requests, I have replied that "if you have a budget, then I'm willing to talk about the price for this feature". Does that fit the level of responsibility you require?
- webmaven 8y ago
  How about bug reports?
  - cerberusss 8y ago
    I haven't gotten those. I don't think my stuff is heavily used :D However, I think that bugs would annoy me enough so I'd fix those. But I don't feel obligated. Nowhere do I state any level of support.

username223 8y ago

> if you are putting a tool out there for others to use (not just software but any tool), then you are responsible for its wellbeing and maintenance, regardless of whether you charge money for it. I think there's also room for software that's dumped on the internet like a free couch left on the sidewalk, but it should be treated similarly: probably full of bugs and not worth your time. I agree that software maintainers shouldn't feel entitled to gratitude without obligation.

detaro 8y ago

So the article writer became "maintainer" by virtue of being something like "the only person that currently cares". Should they have rejected access to the code and ceased contributions at that point, to not be irresponsible years later?

teddyh 8y ago
They might have taken over the role of maintainer, but if the level of involvment which the project required was too much for them, it would have been their duty as maintainer to declare the project moribund until a more active maintainer could be found. To keep the project active and looking alive is to mislead users and implicitly promise a level of support and development which they know they cannot uphold.
- deleted 8y ago
  [deleted]
- deleted 8y ago
  [deleted]

webmaven 8y ago

This really shouldn't be downvoted, as it is a valid stance (one I don't share, BTW, or not much). Human social instincts strongly push toward this position, informed (largely) by metaphors and similies rooted in excludable goods even when nonrivalrous (eg. the prototypical Commons). Software, though - and most especially Free Software - is part of another realm entirely, or at least verges on it: Things that largely grow, proliferate, and spread themselves, even if they do it through coopting human agency. Examples are stories, families, communities, ideologies, movements, hobbies, cultures, and most importantly, individual humans themselves. "If you save a life you become responsible for it" is one of the few succinct ways this has been expressed, which of course doesn't do much to delineate the obligation or its limits. But the sentiment is clear. To what extent can an author (of fiction or non-fiction) disclaim responsibility for their work if it takes on a quasi-life of its own? An artist for a work that is misappropriated? How difficult is it to disavow a family that you have broken with? An embarrassing ancestor who accumulated the family fortune through unsavory means? A child that has grown to become a notorious public enemy? Can a founder of a movement disavow its extremist fringes? Does a celebrity actually have any responsibility at all toward their fans? How difficult is it (or should it be) for a hobbyist to avoid being associated with those who share their hobby, but who also make the hobby unwelcoming to the Other? By now you must have a dozen objections to this post, of all the ways writing software is not like these things I've mentioned, but there is also something deeply similar, though it is difficult to articulate exactly what that is. An author of software, and more precisely a maintainer of software, is responsible in some sense for the nebulous thing that the group of people that software draws together is, even while also being a member of that same group. That the responsibility does not necessarily create much of an attendant obligation is not necessarily clear, when so many social customs are predicated on such obligations being implicit (at least). Even less clear is the extent to which such obligations, when voluntarily assumed, can then be discarded. An analogy may be helpful here: Having moved to a new city, and subsequent to joining some existing social group or club, you volunteered to take care of some aspect of a shared recreation (to bring the salad for a weekend picnic, for example), but you then discover that there are additional logistical and even financial costs involved that you didn't anticipate (the picnic starts much earlier than you're used to, the group includes many vegetarians and vegans who are used to having an extensive variety of salads at such occasions, etc.). So, having voluntarily assumed this obligation, but not having given what could be objectively called fully informed consent, to what extent are you still responsible for addressing the expectations of this group (as a group, and also as individuals) you're now disappointing? And how do the analogous obligations change (and grow) when you are (effectively) the founder of the group? This morass of interpersonal relationships is the sort of thing that being a software maintainer requires navigating, and the situation isn't made simpler just because the central artefact the group revolves around is some non-excludable, non-rivalrous software that is being created and maintained, especially when the name attached to the software is just such a rivalrous good. Disavowal of otherwise implicit responsibilities and obligations is something that seems to crop up more often in recent decades than previously, from IANAL and TINLA (or even IAAL, But Not Your Lawyer), to the increasingly commonplace "I Do Not Speak For My Employer". Such disavowals being (apparently) necessary, authoring and maintaining software clearly also strongly implies at least some responsibilities and obligations, at least as a great many humans perceive things, and it is worth discussing just what those are, as well as when and how to effectively disavow them when not appropriate. As I said at the outset, I personally feel the set of those obligations is smaller than the parent post states (neither software nor the community that forms around it is something that you are obliged to actively nurture), but my disagreement doesn't imply a downvote. It is a valid contribution to the debate on this topic.

jryb 8y ago

I don't understand the downvotes for this. I feel that by making something public and open source, there is an implicit assumption (unless otherwise stated) that the software is worth sharing. The problem is that this puts what I consider the right amount of responsibility squarely in the middle of a continuum: library authors shouldn't be totally free of obligations to others, but the insane abuse that people level against open source maintainers is also obviously unacceptable.

watwut 8y ago
This rule accepted in general would mean that all students who put their homework on github are doing something wrong. Or that all professionals who just play around technology or mini projects are required to keep them secret until they are totally sure they will maintain it forever. That is just not workable and overly limited. While owner can not expect gratitude, the "I’ll work on this when I want, however much I want, and you should just take it or leave it" is absolutely fine and should be fine. Just because it exists on the internet does not entitle the rest of the world to anything.
- teddyh 8y ago
  Unlike what you seem to indicate, projects do imply a level of expected support and continual development by their projected image as given by their web pages, documentation, etc. If a developer/maintainer does not uphold this implied promise, users have a right to feel bamboozled.
- enraged_camel 8y ago
  Students putting their homework on github is totally fine as long as they clearly state that in the readme.
  - watwut 8y ago
    So maybe assume no maintenance unless stated in readme.
detaro 8y ago

teddyh 8y ago

I think I understand you completely, but I also think I know why you were downvoted. The problem is the implied promise of having a software project page on something like GitHub with descriptions, documentation, etc. This, in my mind, and probably yours too, implies a promise of future development, maintenance or at least security bug fixes. When such things are not forthcoming in a manner one might reasonably expect, we feel as though we have been cheated out of something we (rightly or wrongly) feel was promised to us. Maybe what would be useful would be some standard (and required!) marking for all software projects on what the current level of maintenance is. Is it Level 0. I wrote this in an afternoon and have no plans to ever look at it again — use at your own risk. all through Level X. This project is under active development and also has maintainers for a stable branch, which also receives security bug fixes in a timely manner. In short, what I think is actually irresponsible is for projects to look like they are close to level X but then have maintainers behave like they are at a much lower level, and who think that any level of behavior is OK since they don't get paid and haven't personally promised anything. It would be better for all involved if the expected (approximate, of course) level of maintenance could be explicitly announced – this might make it clear to users what level they can expect, and make it clear to maintainers what level of involvment is expected of them to be able to call themselves “maintainers”.

deleted 8y ago
[deleted]

cerberusss 8y ago

Sometimes I open source small libraries. When I get feature requests, I have replied that "if you have a budget, then I'm willing to talk about the price for this feature". Does that fit the level of responsibility you require?

webmaven 8y ago
How about bug reports?
- cerberusss 8y ago
  I haven't gotten those. I don't think my stuff is heavily used :D However, I think that bugs would annoy me enough so I'd fix those. But I don't feel obligated. Nowhere do I state any level of support.