13 ms·

> Having a project maintainer then call those patches boring or otherwise disregard them? That's childish So what? Along the same lines, it's not a maintainer'

> Having a project maintainer then call those patches boring or otherwise disregard them? That's childish So what? Along the same lines, it's not a maintainer's responsibility to follow best-practices, respond to feedback/PRs, or respond in any coherent way to anything asked of them. The fact that you call them childish for not acting they way you want them to makes me think you are the childish one. With those PRs written, _anyone_ on the internet can apply them and use them in their software. I agree with GP, you aren't owed anything, and that extends to any form of social behaviors online. And let's not forget that even the most 'perfect' maintainer still deals with shit on a regular basis from the masses of people demanding features as if they got paid to write the free software people are using. This expectation of being served high-quality open-source software for free, and then outrage when it isn't, is absolutely ridiculous and will make people not want to maintain software.

rckoepke 7y ago
> it's not a maintainer's responsibility to follow best-practices, respond to feedback/PRs, or respond in any coherent way to anything asked of them. I mean, I'd say that it is a maintainer's responsibility to do some of these things. If they can't, they should allow another interested&qualified person to be the maintainer instead. I understand that it's their right to abdicate these responsibilities. It's not illegal or anything. They can choose to be irresponsible, yes. But personally, I think that maintaining the repo is the maintainer's responsibility. And I think the responsible way to do that involves "following best-practices, responding to feedback/PRs, or responding in any coherent way to anything asked of them." I'm NOT saying a maintainer should have to add features to satiate the masses. I'm merely saying that a "maintainer" has some small duty to "maintain" a product, and also acknowledging that they have a legal right to abdicate that responsibility. I'm not sure anyone should be immune from social criticism. They can always make someone else the maintainer and avoid any future work/limelight/criticism. I won't touch the childish vs. adult debate as it pertains to abdicating one's responsibilities. I am also NOT saying that people should "expect to be be served high-quality open-source software for free, and then outrage when it isn't." But it seems like it's a maintainer's responsibility to allow (and maybe even facilitate) competent, motivated individuals to contribute to their open-source project. I also don't know exactly what the reddit brigading involved, this is the first time I've heard of this story. Harassment obviously is not okay and, not coincidentally, is illegal.
- cycloptic 7y ago
  Not everyone who uploads an open source project to some random cloud hosting service (i.e. Github) is qualified or wants to be a maintainer. Remember that being a maintainer is equivalent to project management. A lot of people publishing open source code don't seem to care about this and just want to write interesting programs. And that's fine. I personally have sent patches to lots of people who just never responded and their activity trailed off. Doesn't bother me in the slightest, that's what the "fork" button is for. You also say "legal right" but it's incredibly vague what this is supposed to mean. Nobody cares about this stuff unless the project reaches a certain level of popularity. So once you get over 1000 github stars, should github force you to sign a contract saying you'll respond to emails in a timely manner or they take away your stars? I don't think I need to explain why that doesn't make any sense.
  - rckoepke 7y ago
    No, no, no - none of this is about legality. Just sometimes people bring it up as a framework for determining responsibilities, so I addressed it ahead of time. I don't think (legal requirements) == (responsibilities). The sets may have some overlap but clearly they are not identical. Instead, I am just saying that if I upload a "cool tool" to github, and I notice that it has become super popular, and I don't have time/interest/inclination to maintain it --- I would personally feel a RESPONSIBILITY, and probably social obligation (not a legal obligation) to either put a note saying "this is not actively maintained, please find an up-to-date fork. user/cooltool seems to have community support but I can't personally endorse it." or simply make some other people additional/replacement maintainers for the project which I'm not interested in maintaining anymore.
    - cycloptic 7y ago
      Maybe you do, I'm sure people would appreciate that, but it's not necessary. The nature of these things is that the users are already "following the herd" to a degree. So if the maintainer becomes inactive and a fork picks up the interest, they will just move to that. No ceremony required.
- 7y ago
pdimitar 7y ago
You are correct in general. I'll just add the nuance that when an open-source project gets beyond a certain popularity and usage threshold I'd expect the project's governance to take a stance that's more responsive to PRs. That doesn't include any money incentives and that is likely the problem here. Maybe `actix-web`'s author should apply for GitHub sponsorship. Maybe small sums of money every month will motivate him to take PRs more seriously.
logophobia 7y ago
It was advertised as a production-ready web-framework, and it was very popular. When do people get to complain? "Oh, my credit card information was stolen due to memory issues in this web-service, it's fine though, we didn't pay the guy, so we can't blame him.". Web-frameworks are cornerstones for security, and if you write one, advertise one, you need to care about security. Features, code-style, ad-hoc PRs, bug-fixes: little responsibility there, but security is something that can hurt a lot of people if done wrong. The use-after-free bug this was about could've been exploited in the right circumstances. If I build a playground for free and it gets popular in my neighbourhood, and then collapses on some poor kid, I'm still responsible, even if I did it for free. The way it was handled was definitely NOT productive though, the guy didn't deserve the flames.
- zzzcpan 7y ago
  Everything you ever used in production is "production-ready". The bar is super low, there is no deception here. The security thing is particularly interesting here. If you care about security even a little bit, you absolutely cannot rely on a random third party to provide timely updates or at all, especially for free. A lot of software doesn't even provide basic security necessities to the point, where OS packages may have to include such patches themselves, effectively always being forks, never using vanilla upstream code. But this is only if you care about security a bit. If you just install from language package managers into prod, you obviously do not care about security even a little bit.
  - ambrice 7y ago
    So, your advice is that if you care about security even a little bit, you should write all your software from scratch yourself?
    - TuringNYC 7y ago
      I think his advice is to purchase a licensed product with a paid support package if you need an SLA.
kllrnohj 7y ago
> it's not a maintainer's responsibility to follow best-practices, respond to feedback/PRs, or respond in any coherent way to anything asked of them. It is when they setup an open source project that has that appearance and is framed as being such a project. It is entirely the maintainer's responsibility to establish the type of open source project it is. If it was just a toy hobby project and that's all it was meant to be then it should have been framed as such (such as by being in a personal repo for starters). This project promoted itself for production usage, requested feedback & patches on its project page, and had a github setup that gave an appearance of being, for lack of a better word, professional. That's entirely the fault of the maintainer. They set all that up. They established the expectations of the project. None of that at all forgives the name calling & mud slinging they were subject to, of course. Two wrongs don't make a right. But the maintainer was still also "in the wrong" here. They needed to hand off the project much sooner than they did when they realized they were not at all prepared or ready to handle what they promoted the project as being.
- Touche 7y ago
  Read the license, it frames the project exactly.
  - rakoo 7y ago
    The license is to a project's readme what patent claims are to the rest of the patent document: when there is a conflict, it's the one thing both sides can agree on. However professional and well-presentend the project is, at the end of the day maintainers are doing this primarily because they like it. If they don't like doing something related to the project then no one can blame them for that.
  - kllrnohj 7y ago
    The license only frames the projects legal responsibilities. It is entirely unrelated in every way to how the project is run on a day to day basis. Alternatively if we're going to just go strictly by the license then the maintainer deserved all the flames & flak he got. After all, it wasn't against the license, therefore he cannot complain about it. Just like that idea is unreasonable, so too is trying to hide behind the license in this case.
deleted 7y ago
[deleted]
lanstin 7y ago
Seriously, you can just fork the source repo and do what ever you want with them, and pull from your repo.
zzzeek 7y ago
if a maintainer is a jerk to their contributors, that is of course their right, but...they are being childish.
ljm 7y ago
This is quite an unusual topic but I find myself in agreement. But that's mostly because I don't agree with the general expectation that everything has to be a 'community', that the maintainer now has stewardship over. And the community is almost impossible to please as it grows larger and makes greater demands. At one point it would have been code that anyone was free to use, before it becomes distorted as some bizarre social endeavour, and then people who've never used the software find themselves part of this 'community' and start to weigh in to add social pressure. Use the software or don't; if the patches are rejected, fork it and go that way. If the maintainer won't merge the patches, because he has his own vision, you are perfectly welcome to branch out and follow your own. Or just use something else. Having a maintainer adhere to a set of standards that only start to apply once 'the community' get involved and take control, is super unfair to the maintainer.

rckoepke 7y ago

> it's not a maintainer's responsibility to follow best-practices, respond to feedback/PRs, or respond in any coherent way to anything asked of them. I mean, I'd say that it is a maintainer's responsibility to do some of these things. If they can't, they should allow another interested&qualified person to be the maintainer instead. I understand that it's their right to abdicate these responsibilities. It's not illegal or anything. They can choose to be irresponsible, yes. But personally, I think that maintaining the repo is the maintainer's responsibility. And I think the responsible way to do that involves "following best-practices, responding to feedback/PRs, or responding in any coherent way to anything asked of them." I'm NOT saying a maintainer should have to add features to satiate the masses. I'm merely saying that a "maintainer" has some small duty to "maintain" a product, and also acknowledging that they have a legal right to abdicate that responsibility. I'm not sure anyone should be immune from social criticism. They can always make someone else the maintainer and avoid any future work/limelight/criticism. I won't touch the childish vs. adult debate as it pertains to abdicating one's responsibilities. I am also NOT saying that people should "expect to be be served high-quality open-source software for free, and then outrage when it isn't." But it seems like it's a maintainer's responsibility to allow (and maybe even facilitate) competent, motivated individuals to contribute to their open-source project. I also don't know exactly what the reddit brigading involved, this is the first time I've heard of this story. Harassment obviously is not okay and, not coincidentally, is illegal.

cycloptic 7y ago
Not everyone who uploads an open source project to some random cloud hosting service (i.e. Github) is qualified or wants to be a maintainer. Remember that being a maintainer is equivalent to project management. A lot of people publishing open source code don't seem to care about this and just want to write interesting programs. And that's fine. I personally have sent patches to lots of people who just never responded and their activity trailed off. Doesn't bother me in the slightest, that's what the "fork" button is for. You also say "legal right" but it's incredibly vague what this is supposed to mean. Nobody cares about this stuff unless the project reaches a certain level of popularity. So once you get over 1000 github stars, should github force you to sign a contract saying you'll respond to emails in a timely manner or they take away your stars? I don't think I need to explain why that doesn't make any sense.
- rckoepke 7y ago
  No, no, no - none of this is about legality. Just sometimes people bring it up as a framework for determining responsibilities, so I addressed it ahead of time. I don't think (legal requirements) == (responsibilities). The sets may have some overlap but clearly they are not identical. Instead, I am just saying that if I upload a "cool tool" to github, and I notice that it has become super popular, and I don't have time/interest/inclination to maintain it --- I would personally feel a RESPONSIBILITY, and probably social obligation (not a legal obligation) to either put a note saying "this is not actively maintained, please find an up-to-date fork. user/cooltool seems to have community support but I can't personally endorse it." or simply make some other people additional/replacement maintainers for the project which I'm not interested in maintaining anymore.
  - cycloptic 7y ago
    Maybe you do, I'm sure people would appreciate that, but it's not necessary. The nature of these things is that the users are already "following the herd" to a degree. So if the maintainer becomes inactive and a fork picks up the interest, they will just move to that. No ceremony required.
7y ago

pdimitar 7y ago

You are correct in general. I'll just add the nuance that when an open-source project gets beyond a certain popularity and usage threshold I'd expect the project's governance to take a stance that's more responsive to PRs. That doesn't include any money incentives and that is likely the problem here. Maybe `actix-web`'s author should apply for GitHub sponsorship. Maybe small sums of money every month will motivate him to take PRs more seriously.

logophobia 7y ago

It was advertised as a production-ready web-framework, and it was very popular. When do people get to complain? "Oh, my credit card information was stolen due to memory issues in this web-service, it's fine though, we didn't pay the guy, so we can't blame him.". Web-frameworks are cornerstones for security, and if you write one, advertise one, you need to care about security. Features, code-style, ad-hoc PRs, bug-fixes: little responsibility there, but security is something that can hurt a lot of people if done wrong. The use-after-free bug this was about could've been exploited in the right circumstances. If I build a playground for free and it gets popular in my neighbourhood, and then collapses on some poor kid, I'm still responsible, even if I did it for free. The way it was handled was definitely NOT productive though, the guy didn't deserve the flames.

zzzcpan 7y ago
Everything you ever used in production is "production-ready". The bar is super low, there is no deception here. The security thing is particularly interesting here. If you care about security even a little bit, you absolutely cannot rely on a random third party to provide timely updates or at all, especially for free. A lot of software doesn't even provide basic security necessities to the point, where OS packages may have to include such patches themselves, effectively always being forks, never using vanilla upstream code. But this is only if you care about security a bit. If you just install from language package managers into prod, you obviously do not care about security even a little bit.
- ambrice 7y ago
  So, your advice is that if you care about security even a little bit, you should write all your software from scratch yourself?
  - TuringNYC 7y ago
    I think his advice is to purchase a licensed product with a paid support package if you need an SLA.

kllrnohj 7y ago

> it's not a maintainer's responsibility to follow best-practices, respond to feedback/PRs, or respond in any coherent way to anything asked of them. It is when they setup an open source project that has that appearance and is framed as being such a project. It is entirely the maintainer's responsibility to establish the type of open source project it is. If it was just a toy hobby project and that's all it was meant to be then it should have been framed as such (such as by being in a personal repo for starters). This project promoted itself for production usage, requested feedback & patches on its project page, and had a github setup that gave an appearance of being, for lack of a better word, professional. That's entirely the fault of the maintainer. They set all that up. They established the expectations of the project. None of that at all forgives the name calling & mud slinging they were subject to, of course. Two wrongs don't make a right. But the maintainer was still also "in the wrong" here. They needed to hand off the project much sooner than they did when they realized they were not at all prepared or ready to handle what they promoted the project as being.

Touche 7y ago
Read the license, it frames the project exactly.
- rakoo 7y ago
  The license is to a project's readme what patent claims are to the rest of the patent document: when there is a conflict, it's the one thing both sides can agree on. However professional and well-presentend the project is, at the end of the day maintainers are doing this primarily because they like it. If they don't like doing something related to the project then no one can blame them for that.
- kllrnohj 7y ago
  The license only frames the projects legal responsibilities. It is entirely unrelated in every way to how the project is run on a day to day basis. Alternatively if we're going to just go strictly by the license then the maintainer deserved all the flames & flak he got. After all, it wasn't against the license, therefore he cannot complain about it. Just like that idea is unreasonable, so too is trying to hide behind the license in this case.

deleted 7y ago

[deleted]

lanstin 7y ago

Seriously, you can just fork the source repo and do what ever you want with them, and pull from your repo.

zzzeek 7y ago

if a maintainer is a jerk to their contributors, that is of course their right, but...they are being childish.

ljm 7y ago

This is quite an unusual topic but I find myself in agreement. But that's mostly because I don't agree with the general expectation that everything has to be a 'community', that the maintainer now has stewardship over. And the community is almost impossible to please as it grows larger and makes greater demands. At one point it would have been code that anyone was free to use, before it becomes distorted as some bizarre social endeavour, and then people who've never used the software find themselves part of this 'community' and start to weigh in to add social pressure. Use the software or don't; if the patches are rejected, fork it and go that way. If the maintainer won't merge the patches, because he has his own vision, you are perfectly welcome to branch out and follow your own. Or just use something else. Having a maintainer adhere to a set of standards that only start to apply once 'the community' get involved and take control, is super unfair to the maintainer.