4 ms·

While you have a point about behavior, let’s not forget that the library is _free_. Maintaining such projects is often a hard, thankless job. The only obligati

by d4mi3n 7y ago

While you have a point about behavior, let’s not forget that the library is _free_. Maintaining such projects is often a hard, thankless job. The only obligation any maintainer has is to abide by whatever terms they release their code under. I don’t think it’s reasonable to expect professional support from any project maintained by a single individual.

geofft 7y ago
I don't think that's the only obligation. The other major obligation of a maintainer is to not hurt or impede others in the progress. Hurting others (which, to be clear, I'm not claiming has happened here) is pretty easy to do. For instance, someone opens a request, you say "Patches welcome," they spend time writing a long implementation, and you say "Never mind, I don't like this feature." You're wasting their time, and had you just not said anything, they would have been in a better place. Writing software with backdoors, or recklessly writing software in a way that makes it prone to vulnerabilities, also hurts people. Impeding others is a softer form of this. There isn't the ability for five hundred Python dependency management projects to all exist and be successful. If you get your project listed as the standard recommendation https://packaging.python.org/guides/tool-recommendations/ https://packaging.python.org/guides/tool-recommendations/ , you are effectively promising that it is suitable for people who need a tool like it, and in turn that you have both the willingness and time to make it happen. You don't have to get it so listed. (You can also, of course, change your mind and de-list it.) You can absolutely say, this is a project for my own needs and I don't want to accept support requests at all. Then, at least, someone else can create a similar tool - either their own, or based on your open-source code (and abiding by your license). But if you're signed up to be the standard tool, you're impeding others who actually do have the time and bandwidth for improvements and would be willing to make a competing tool if you're not able to stand by your commitments.
- d4mi3n 7y ago
  Excellent points I had not considered. If as you say, somebody released code saying that it was something they were willing to support, it’s reasonable to expect said author to stand by their statements. That said, this seems like it would be a more implicit expectation than an explicit agreement in many cases. How could a community enforce good behavior in this regard? Going by your previous example, would it be reasonable for the recommended list of libraries to be more carefully curated for people on such a way that only stable _and_ well supported libraries are put forward? Putting hard requirements on official recommendations seems like it’s be a fairly simple way to avoid such situations.
ijpoijpoihpiuoh 7y ago
> The only obligation any maintainer has is to abide by whatever terms they release their code under. That's not actually true, right? The obligation flows the other direction. People who receive the code are obligated to abide by the terms. The author does not have to do anything except follow the law. They are not bound by the terms under which they are distributing their code.
- d4mi3n 7y ago
  I worded that poorly. I meant “terms” in the general sense, as some sort of agreement between two parties, but you are absolutely correct.
kamyarg 7y ago
True, I agree with how hard it is, but if users say a feature that is an integral part of the tool is broken, that should be priority or if you don't have time/interest just give it to people that can take care of it. I am not talking about a company asking for a new feature, I am asking for a bug that makes your popular PSF-recommended tool do unexpected stuff. (see the https://github.com/pypa/pipenv/issues/1554 https://github.com/pypa/pipenv/issues/1554 as an example)

by d4mi3n 7y ago

geofft 7y ago

I don't think that's the only obligation. The other major obligation of a maintainer is to not hurt or impede others in the progress. Hurting others (which, to be clear, I'm not claiming has happened here) is pretty easy to do. For instance, someone opens a request, you say "Patches welcome," they spend time writing a long implementation, and you say "Never mind, I don't like this feature." You're wasting their time, and had you just not said anything, they would have been in a better place. Writing software with backdoors, or recklessly writing software in a way that makes it prone to vulnerabilities, also hurts people. Impeding others is a softer form of this. There isn't the ability for five hundred Python dependency management projects to all exist and be successful. If you get your project listed as the standard recommendation https://packaging.python.org/guides/tool-recommendations/ https://packaging.python.org/guides/tool-recommendations/ , you are effectively promising that it is suitable for people who need a tool like it, and in turn that you have both the willingness and time to make it happen. You don't have to get it so listed. (You can also, of course, change your mind and de-list it.) You can absolutely say, this is a project for my own needs and I don't want to accept support requests at all. Then, at least, someone else can create a similar tool - either their own, or based on your open-source code (and abiding by your license). But if you're signed up to be the standard tool, you're impeding others who actually do have the time and bandwidth for improvements and would be willing to make a competing tool if you're not able to stand by your commitments.

d4mi3n 7y ago
Excellent points I had not considered. If as you say, somebody released code saying that it was something they were willing to support, it’s reasonable to expect said author to stand by their statements. That said, this seems like it would be a more implicit expectation than an explicit agreement in many cases. How could a community enforce good behavior in this regard? Going by your previous example, would it be reasonable for the recommended list of libraries to be more carefully curated for people on such a way that only stable _and_ well supported libraries are put forward? Putting hard requirements on official recommendations seems like it’s be a fairly simple way to avoid such situations.

ijpoijpoihpiuoh 7y ago

> The only obligation any maintainer has is to abide by whatever terms they release their code under. That's not actually true, right? The obligation flows the other direction. People who receive the code are obligated to abide by the terms. The author does not have to do anything except follow the law. They are not bound by the terms under which they are distributing their code.

d4mi3n 7y ago
I worded that poorly. I meant “terms” in the general sense, as some sort of agreement between two parties, but you are absolutely correct.

kamyarg 7y ago

True, I agree with how hard it is, but if users say a feature that is an integral part of the tool is broken, that should be priority or if you don't have time/interest just give it to people that can take care of it. I am not talking about a company asking for a new feature, I am asking for a bug that makes your popular PSF-recommended tool do unexpected stuff. (see the https://github.com/pypa/pipenv/issues/1554 https://github.com/pypa/pipenv/issues/1554 as an example)