11 ms·

> No one expects you to write perfect code, but we do expect you to fix flaws when you learn about them. It's not like he was getting paid to work on this, was

> No one expects you to write perfect code, but we do expect you to fix flaws when you learn about them. It's not like he was getting paid to work on this, was it? And people do have a life beyond open source. People could have forked and worked on the issues themselves, but that's asking too much. Why do the hard work when you can just write a comment/tweet blaming someone else, right? Your comment is precisely what entitlement looks like.

deleted 7y ago
[deleted]
adar 7y ago
From what sklabnik's post says, patches were submitted but the author wasn't really receptive to them.
- jwlake 7y ago
  I honestly dont understand people being mad at this. Every dependancy I use I don't like 100% I fork and modify and then upstream changes, and if they never get merged, who cares? If there was a big user community that wanted different things, fork and have a seperate maintainer structure. Why drama?
  - boutad 7y ago
    Then you might end up with a bunch of different forks each with different fixes applied.
    - pfortuny 7y ago
      And?
      - boutad 7y ago
        Wouldn't it be better if there was one repo that had all of the fixes?
    - jwlake 7y ago
      A huge number of npm dependancies I use are basically unmaintained, have tons of forks and multiple PRs with the same fixes. I choose the one I like and move on, the magic of github!
      - svick 7y ago
        Are you saying that that's a good thing?
- jessaustin 7y ago
  In that case, you clone and fork. If you're just trying to get your stuff working, your fork is private. If instead you're trying to enjoy publicity, you publicize your fork. In neither case is it necessary to annoy someone who has already done a lot of free work for you.
  - jimbokun 7y ago
    Reporting bugs is annoying? I want people to point out bugs in my code, so both my code and me as a developer can improve.
    - jessaustin 7y ago
      This isn't a serious response. As amply demonstrated in TFA and elsewhere, the harassment was far more than "reporting bugs". And, anyway, yes, reporting bugs can be extremely annoying. Different devs respond to this annoyance differently. npm devs, for example, have decided not to pay too much attention to bugs reported by the public. [0] [0] https://npm.community/c/bugs https://npm.community/c/bugs
      - Razengan 7y ago
        > And, anyway, yes, reporting bugs can be extremely annoying. I would never touch the product of someone who found bug reports annoying.
        lenkite 7y ago
        Strangely, I would rather deal with developers who find bug reports annoying than folks who simply ignore them. The former have a touch of pride and you have a chance to get them to see your point of view. Better that than speaking to a black-hole.
        jessaustin 7y ago
        That's a good policy, both for you and for them.
jsjohnst 7y ago
I don’t have the full picture here, but the source article implies that folks weren’t just complaining, but also offering PRs to fix the issues, which were rejected. That feels less like entitlement to me and more like bad stewardship of the project, but again, most of my info is biased by source article.
- manish_gill 7y ago
  This is why I wrote "forked". They do have the right to not accept PRs for their own project, no? Sure, someone can be a bad steward, or maybe just opinionated. Doesn't give anyone the right to be mean to the point of making them quit their own project.
  - jimbokun 7y ago
    All of this is second hand, where are the mean comments "making" this person quit their own project? Were they actual personal attacks, or just criticism of the code? If you can't accept legitimate criticism of your work, that shows a real lack of maturity. (The article didn't give concrete examples, so I don't know which is the case here.)
    - steveklabnik 7y ago
      Here is an example of an actual comment. I believe the thread is deleted now: > "seriously? Please just stop writing Rust. You do not respect semver, you do not respect soundness, so why are you using a language predominantly based around doing these things right?" This is what I was thinking of when I wrote "far, far over the line."
      - jeltz 7y ago
        Yes, that comment was not ok but as far as I have seen that is the only comment which keeps getting quoted. All but a handful of people seem to have been civil.
        7y ago
jimbokun 7y ago
Ok, so here is the article Klabnik cites, comparing various Rust HTTP clients: https://medium.com/@shnatsel/smoke-testing-rust-http-clients-b8f2ee5db4e6 https://medium.com/@shnatsel/smoke-testing-rust-http-clients... Skimming this, the author doesn't really like any of them. Note, however, the long list of issues reported at the end of the article. Here is the first one I clicked on: https://github.com/algesten/ureq/issues/24 https://github.com/algesten/ureq/issues/24 The maintainer is happy to get the report, and has an exchange with the reporter acknowledging the bug and how to fix it. This all seems a very civil, mature way to address issues with open source software. Accept actionable criticism of your code, and strive to make it better. As a developer, I know having other people test my code and report problems back to me is one of the best ways for them to help me and my code improve! I think identifying to your code to the point where you consider criticism of your code an attack on your personal identity demonstrates a real lack of maturity.
- jasonlotito 7y ago
  You might have missed a couple lines. It's easy to miss as it's right below the quote from the article mentioned: "This causes the now-usual Reddit uproar. It’s extra nasty this time. Some people go far, far, far over the line." The issue isn't the article or the bug reports. It's the uproar from Reddit, and the extra nasty comments. "Some people go far, far, far over the line." There is a reason HN has guidelines for how to approach communication. It's because if we "go far, far, far over the line" and get "extra nasty" things devolve and this place becomes far worse. Rather than "toughen up" or "just not taking things personally," HN realizes that words matter. Like I said, a couple lines easily missed or forgotten. It's not the bug reports. It's the extra nasty comments.
  - timjver 7y ago
    This could very well be thanks to the moderators, but I hardly saw any nasty comments on r/rust. People were critical of the actix maintainer, sure, but I didn't see anything that crossed the line. Some comments in the GitHub issues were indeed nasty, but those were actually called out on the subreddit. There's no way for me to know for sure, but it seems as though Klabnik was exaggerating here.
AnonymousPlanet 7y ago
> It's not like he was getting paid to work on this, was it? That is completely beside the point. Do the Debian maintainers that were responsible for famous security slipups regarding SSH keys got paid? No. Would the backlash if they had been unwilling to fix the issues been warranted? Absolutely. Once you are a part of people's infrastructure and these people rely on you to not be irresponsible, you can't afford to play the but-I-dont-get-paid-card. You can resign gracefully and let other people take over. If you put up a tantrum, you probably get your reputation burnt faster than a Google project gets when they suddenly pull the plug. Open source is not some backyard game anymore. It involves companies and their commitment in form of infrastructure and participation. Open source is like capitalism. But a project's success is measured in commitment instead of capital.
- Uehreka 7y ago
  I’d argue that if a company has a larger than normal dependency on keeping a project running (like a cloud provider with 1 million VMs running Debian or Debian-based OSes) they should hire a full time employee whose sole job is to work on it. I think the basic rules still apply: You’re getting this software for free rather than paying for something expensive. Though you deal in the software, you get no guarantee of its fitness for any purpose. If you want a better guarantee of its fitness, either pay the current maintainers or hire someone good who can become a maintainer. OR choose open source projects where a BigCo like Microsoft or Google has hired people to work on it full time.
  - AnonymousPlanet 7y ago
    > You’re getting this software for free rather than paying for something expensive. So open source is free as in beer, not free as in speech after all. And the reason a company might choose to use open source is solely because it's free, not because they can see the source code or alter it? Because that is why companies are in it, not because they were cheap for the small cash of a paid version. And they're in it because they can watch and choose those projects that are well maintained. If the maintainer pulls a tantrum and acts unreliable that kills the project from the point of view of any serious user. Until someone else takes over maintenance or it is forked. This "it's free so you get what you paid for, and if it's shit don't complain because it was free" really rubs me the wrong way. It's a very capitalist mindset that measures everything in money. If there is no money, there is probably no worth, so don't expect any. Accomplishment, dependability, positive net effect? No money, so don't expect it?
vunie 7y ago
No demand for work is being made here. I'm simply saying a project that isn't a toy project will be criticized if it doesn't behave according to community standards. I'd consider it to be social norms. It certainly isn't entitlement.
tomjakubowski 7y ago
Nikolay works for Microsoft, who use actix-web internally. He was putting in 12 hour days for 3 weeks porting the project to async/await, so I sure hope that Microsoft was paying him for it!
- pgeorgi 7y ago
  So he was paid by Microsoft to handle their pain points. How much did any of the reddit guerilla pay him to be able to make similar demands?
pcr910303 7y ago
Okay, I massaged the GitHub API logs[0] with jq to make a readable version of the issue history[1]. I was firstly (based on the blog post) feeling bad about the maintainer... but after reading the issue report, it turns out multiple people were working on the issue and the author responded... 'this patch is boring'. That's... certainly not good to people who are trying to resolve the issue. He even goes to threatening to delete the organization if people talk about the issue. [0] https://gist.github.com/bb010g/705c8ffe4b9db9550a7782d25e5a53be https://gist.github.com/bb010g/705c8ffe4b9db9550a7782d25e5a5... [1] https://gist.github.com/pcr910303/d7722a26499d0e9d2f9034a06f2433b4 https://gist.github.com/pcr910303/d7722a26499d0e9d2f9034a06f...
- mratsim 7y ago
  Thank you very much. Are there some deleted comments that might have been missed? If not the conversation was civil until the maintainer refused a patch for a "boring" reason.
  - steveklabnik 7y ago
    As I mentioned in the post, this situation has been going on for a long time. You'd need to read a few dozen pages to get the full context here.
  - Izkata 7y ago
    Not quite correct. That patch was never intended to be merged as-is in the first place: > As a PoC > Presumably this requires benchmarking/more exhaustive testing which I don't have time to do, but if someone wants to take the patch and get it merged feel free Keeping that in mind, the "boring" comment comes off differently to me, like they got sidetracked from the original issue and he didn't feel like continuing - which is nearly the confirmation given in the second issue.
CydeWeys 7y ago
From a pragmatic point of view, it's very bad to have widely used libraries that are poorly maintained and that have unaddressed security issues. It's not entitled to not want that situation to exist. If you create a project that ends up becoming such a security risk, you really should be doing something to address it, for the good of everyone. This could be as simple as adding more maintainers with commit access who will address the issues.
cthalupa 7y ago
>People could have forked and worked on the issues themselves, but that's asking too much. Forking projects should be a last resort. This is the "Taking my ball and going home" approach, and now we're splitting development efforts, potentially ending up with very different code paths where improvements can't be merged from one to another, etc. It might be the right thing to do in this situation - but people wanting to avoid it want to avoid it for good reason. It's a big hammer and not the first one you want to pull out of your tool bag. >Why do the hard work when you can just write a comment/tweet blaming someone else, right? Except, as the article mentions, the author wasn't interested in detailed bug reports or PRs that had code that fixed it. This wasn't a case of people just being nasty - the maintainer wasn't interested in people doing work to fix it, either. >Your comment is precisely what entitlement looks like. This isn't someone asking for a feature request or minor bug to be resolved and whining when it didn't happen. This is a security vulnerability in a popular package where detailed reports are provided and the maintainer has a history of not accepting feedback, PRs, etc. on similar issues in the past. Security vulnerabilities are a big deal: They have implications for not just the user or company that is making use of the software, but also potentially any end users. This is a web framework - a good portion of projects using it are going to be public facing. A good portion of those are going to be storing user accounts and information about the users. A security vulnerability puts all of those people at risk too. I maintain that any project that you make publicly available you have a moral obligation to resolve security issues if it is at all within your power, and to disclaim them prominently if it isn't. If I've got a free lemonade stand, but every glass contains a toxic chemical that will activate in my body if a malicious person sprays me in the face with another chemical, people sure as hell can bitch about my free lemonade, even if they could go run it through a filter and remove the toxic chemical.
- ncmncm 7y ago
  No. Fork anytime you want to use something in production and don't consider it right. Post pull requests if you care to, and post your fork, too, if you like, being careful to keep clear that it is a different project. Some forks wither, some surge, some re-merge. It's all part of the dance. Any of it is better than flaming somebody who makes a thing and offers it.
- 7y ago
tunesmith 7y ago
If you make your project public, does it by definition mean you are open to other people using your release? I think there's a difference between "Hey, use this project of mine," and "If you use this project, you're on your own..." I think a lot of these debates come down to this confusion. Some people assume the former (and expect some level of response), some the latter (and say it's as simple as forking if you have a problem). Therefore I think anyone who releases should - morally/ethically, not legally/license - state what which philosophy they are following. It'd be interesting if people could release their projects "abstract" fork-only. So they could publish releases that would be vetted and merged into the downstream forks, but would never be released as a deployable itself.
- kelnos 7y ago
  It's really hard, though, because you'll always get people who will feel entitled. In the distant past I've released things and explicitly put in the readme something like "This is provided in the hope that it will be useful; I do not have time to support it and will not accept requests for help, but will consider merging patches that fix bugs or add useful functionality". And yet I still got people who would ask for help with it, or file bugs without patches and then get angry when I wouldn't help them.
yellowapple 7y ago
> It's not like he was getting paid to work on this, was it? So? If I'm donating clothes to one of those coat drives, and the clothes I donate are tattered and covered with rodent feces, should the organizers of said drive not be upset with me? Especially if said organizers point this out politely and I respond with "lol you'll take what I give you, peasant"?
vfclists 7y ago
Reasonable expectation does not equate to entitlement. So what is the person who finds the flaw supposed to do: 1. announce to all the other users of the library to download his branch with just the single fix 2. report it to the maintainer with a suitable patch, discuss it, and hope the maintainer applies it sooner rather than later. TBH the maintainer sounds like the boy with the soccer ball who ends the match and takes his ball home with him, because the opposing side scored against his team.
- atoav 7y ago
  To me the maintainer sounds more like the boy who brought everybody cake and then left the party when the other boys started nagging about how their mothers would make much better cake and how his cake is all wrong.
  - twic 7y ago
    It's more that he bought a cake, but it wasn't cooked in the middle, so there was a chance people could get food poisoning, and the other people at the party pointed that out and suggested ways to cook cakes more consistently, but the author really likes cooking soggy cakes, and he's never got sick from it so it must be fine, so he left the party and told everyone the others were mean to him.
    - comfyinnernet 7y ago
      It's more like he bought a cake but the brakes were faulty and it skidded off the road and killed an innocent trifle.
im3w1l 7y ago
Let's say some charitable person hands out food to the poor. Only it's cooked with bad hygiene and people who eat it fall ill. People can and should warn tell each other to stay away. Even if his feelings get hurt. Even if he was only trying to do good. I think this is a good metaphor because how bad the food is is key. If it's just a little bad he is doing a good thing. If it's a little bit more bad it's neutral and people can take it or leave it. And if the quality is really bad that's when people need to protect themselves and each other by dragging his name through the mud. I'm not familiar with actix so I wont presume to say which category it falls into.
mayankkaizen 7y ago
Although I agree with you but there is one more point to consider. Why do people write open source libraries/frameworks? You'd say they write it as a hobby or learning experience and this is totally fine. But why don't they keep their work private if they aren't or shouldn't be bothered about how people use their libraries? I agree OSS maintainers do a lot of work but no compensation in return. I believe most maintainers actually strive to remove flaws/bugs in their projects. But if you write a half baked buggy OSS which is used by many people, you definitely should have some sense of responsibility towards users. Otherwise keep it private or at least boldly acknowledge that your project is merely a toy project which has many bugs and you aren't bothered about those bugs.

deleted 7y ago

[deleted]

adar 7y ago

From what sklabnik's post says, patches were submitted but the author wasn't really receptive to them.

jwlake 7y ago
I honestly dont understand people being mad at this. Every dependancy I use I don't like 100% I fork and modify and then upstream changes, and if they never get merged, who cares? If there was a big user community that wanted different things, fork and have a seperate maintainer structure. Why drama?
- boutad 7y ago
  Then you might end up with a bunch of different forks each with different fixes applied.
  - pfortuny 7y ago
    And?
    - boutad 7y ago
      Wouldn't it be better if there was one repo that had all of the fixes?
  - jwlake 7y ago
    A huge number of npm dependancies I use are basically unmaintained, have tons of forks and multiple PRs with the same fixes. I choose the one I like and move on, the magic of github!
    - svick 7y ago
      Are you saying that that's a good thing?
jessaustin 7y ago
In that case, you clone and fork. If you're just trying to get your stuff working, your fork is private. If instead you're trying to enjoy publicity, you publicize your fork. In neither case is it necessary to annoy someone who has already done a lot of free work for you.
- jimbokun 7y ago
  Reporting bugs is annoying? I want people to point out bugs in my code, so both my code and me as a developer can improve.
  - jessaustin 7y ago
    This isn't a serious response. As amply demonstrated in TFA and elsewhere, the harassment was far more than "reporting bugs". And, anyway, yes, reporting bugs can be extremely annoying. Different devs respond to this annoyance differently. npm devs, for example, have decided not to pay too much attention to bugs reported by the public. [0] [0] https://npm.community/c/bugs https://npm.community/c/bugs
    - Razengan 7y ago
      > And, anyway, yes, reporting bugs can be extremely annoying. I would never touch the product of someone who found bug reports annoying.
      - lenkite 7y ago
        Strangely, I would rather deal with developers who find bug reports annoying than folks who simply ignore them. The former have a touch of pride and you have a chance to get them to see your point of view. Better that than speaking to a black-hole.
      - jessaustin 7y ago
        That's a good policy, both for you and for them.

jsjohnst 7y ago

I don’t have the full picture here, but the source article implies that folks weren’t just complaining, but also offering PRs to fix the issues, which were rejected. That feels less like entitlement to me and more like bad stewardship of the project, but again, most of my info is biased by source article.

manish_gill 7y ago
This is why I wrote "forked". They do have the right to not accept PRs for their own project, no? Sure, someone can be a bad steward, or maybe just opinionated. Doesn't give anyone the right to be mean to the point of making them quit their own project.
- jimbokun 7y ago
  All of this is second hand, where are the mean comments "making" this person quit their own project? Were they actual personal attacks, or just criticism of the code? If you can't accept legitimate criticism of your work, that shows a real lack of maturity. (The article didn't give concrete examples, so I don't know which is the case here.)
  - steveklabnik 7y ago
    Here is an example of an actual comment. I believe the thread is deleted now: > "seriously? Please just stop writing Rust. You do not respect semver, you do not respect soundness, so why are you using a language predominantly based around doing these things right?" This is what I was thinking of when I wrote "far, far over the line."
    - jeltz 7y ago
      Yes, that comment was not ok but as far as I have seen that is the only comment which keeps getting quoted. All but a handful of people seem to have been civil.
      - 7y ago

jimbokun 7y ago

Ok, so here is the article Klabnik cites, comparing various Rust HTTP clients: https://medium.com/@shnatsel/smoke-testing-rust-http-clients-b8f2ee5db4e6 https://medium.com/@shnatsel/smoke-testing-rust-http-clients... Skimming this, the author doesn't really like any of them. Note, however, the long list of issues reported at the end of the article. Here is the first one I clicked on: https://github.com/algesten/ureq/issues/24 https://github.com/algesten/ureq/issues/24 The maintainer is happy to get the report, and has an exchange with the reporter acknowledging the bug and how to fix it. This all seems a very civil, mature way to address issues with open source software. Accept actionable criticism of your code, and strive to make it better. As a developer, I know having other people test my code and report problems back to me is one of the best ways for them to help me and my code improve! I think identifying to your code to the point where you consider criticism of your code an attack on your personal identity demonstrates a real lack of maturity.

jasonlotito 7y ago
You might have missed a couple lines. It's easy to miss as it's right below the quote from the article mentioned: "This causes the now-usual Reddit uproar. It’s extra nasty this time. Some people go far, far, far over the line." The issue isn't the article or the bug reports. It's the uproar from Reddit, and the extra nasty comments. "Some people go far, far, far over the line." There is a reason HN has guidelines for how to approach communication. It's because if we "go far, far, far over the line" and get "extra nasty" things devolve and this place becomes far worse. Rather than "toughen up" or "just not taking things personally," HN realizes that words matter. Like I said, a couple lines easily missed or forgotten. It's not the bug reports. It's the extra nasty comments.
- timjver 7y ago
  This could very well be thanks to the moderators, but I hardly saw any nasty comments on r/rust. People were critical of the actix maintainer, sure, but I didn't see anything that crossed the line. Some comments in the GitHub issues were indeed nasty, but those were actually called out on the subreddit. There's no way for me to know for sure, but it seems as though Klabnik was exaggerating here.

AnonymousPlanet 7y ago

> It's not like he was getting paid to work on this, was it? That is completely beside the point. Do the Debian maintainers that were responsible for famous security slipups regarding SSH keys got paid? No. Would the backlash if they had been unwilling to fix the issues been warranted? Absolutely. Once you are a part of people's infrastructure and these people rely on you to not be irresponsible, you can't afford to play the but-I-dont-get-paid-card. You can resign gracefully and let other people take over. If you put up a tantrum, you probably get your reputation burnt faster than a Google project gets when they suddenly pull the plug. Open source is not some backyard game anymore. It involves companies and their commitment in form of infrastructure and participation. Open source is like capitalism. But a project's success is measured in commitment instead of capital.

Uehreka 7y ago
I’d argue that if a company has a larger than normal dependency on keeping a project running (like a cloud provider with 1 million VMs running Debian or Debian-based OSes) they should hire a full time employee whose sole job is to work on it. I think the basic rules still apply: You’re getting this software for free rather than paying for something expensive. Though you deal in the software, you get no guarantee of its fitness for any purpose. If you want a better guarantee of its fitness, either pay the current maintainers or hire someone good who can become a maintainer. OR choose open source projects where a BigCo like Microsoft or Google has hired people to work on it full time.
- AnonymousPlanet 7y ago
  > You’re getting this software for free rather than paying for something expensive. So open source is free as in beer, not free as in speech after all. And the reason a company might choose to use open source is solely because it's free, not because they can see the source code or alter it? Because that is why companies are in it, not because they were cheap for the small cash of a paid version. And they're in it because they can watch and choose those projects that are well maintained. If the maintainer pulls a tantrum and acts unreliable that kills the project from the point of view of any serious user. Until someone else takes over maintenance or it is forked. This "it's free so you get what you paid for, and if it's shit don't complain because it was free" really rubs me the wrong way. It's a very capitalist mindset that measures everything in money. If there is no money, there is probably no worth, so don't expect any. Accomplishment, dependability, positive net effect? No money, so don't expect it?

vunie 7y ago

No demand for work is being made here. I'm simply saying a project that isn't a toy project will be criticized if it doesn't behave according to community standards. I'd consider it to be social norms. It certainly isn't entitlement.

tomjakubowski 7y ago

Nikolay works for Microsoft, who use actix-web internally. He was putting in 12 hour days for 3 weeks porting the project to async/await, so I sure hope that Microsoft was paying him for it!

pgeorgi 7y ago
So he was paid by Microsoft to handle their pain points. How much did any of the reddit guerilla pay him to be able to make similar demands?

pcr910303 7y ago

Okay, I massaged the GitHub API logs[0] with jq to make a readable version of the issue history[1]. I was firstly (based on the blog post) feeling bad about the maintainer... but after reading the issue report, it turns out multiple people were working on the issue and the author responded... 'this patch is boring'. That's... certainly not good to people who are trying to resolve the issue. He even goes to threatening to delete the organization if people talk about the issue. [0] https://gist.github.com/bb010g/705c8ffe4b9db9550a7782d25e5a53be https://gist.github.com/bb010g/705c8ffe4b9db9550a7782d25e5a5... [1] https://gist.github.com/pcr910303/d7722a26499d0e9d2f9034a06f2433b4 https://gist.github.com/pcr910303/d7722a26499d0e9d2f9034a06f...

mratsim 7y ago
Thank you very much. Are there some deleted comments that might have been missed? If not the conversation was civil until the maintainer refused a patch for a "boring" reason.
- steveklabnik 7y ago
  As I mentioned in the post, this situation has been going on for a long time. You'd need to read a few dozen pages to get the full context here.
- Izkata 7y ago
  Not quite correct. That patch was never intended to be merged as-is in the first place: > As a PoC > Presumably this requires benchmarking/more exhaustive testing which I don't have time to do, but if someone wants to take the patch and get it merged feel free Keeping that in mind, the "boring" comment comes off differently to me, like they got sidetracked from the original issue and he didn't feel like continuing - which is nearly the confirmation given in the second issue.

CydeWeys 7y ago

From a pragmatic point of view, it's very bad to have widely used libraries that are poorly maintained and that have unaddressed security issues. It's not entitled to not want that situation to exist. If you create a project that ends up becoming such a security risk, you really should be doing something to address it, for the good of everyone. This could be as simple as adding more maintainers with commit access who will address the issues.

cthalupa 7y ago

>People could have forked and worked on the issues themselves, but that's asking too much. Forking projects should be a last resort. This is the "Taking my ball and going home" approach, and now we're splitting development efforts, potentially ending up with very different code paths where improvements can't be merged from one to another, etc. It might be the right thing to do in this situation - but people wanting to avoid it want to avoid it for good reason. It's a big hammer and not the first one you want to pull out of your tool bag. >Why do the hard work when you can just write a comment/tweet blaming someone else, right? Except, as the article mentions, the author wasn't interested in detailed bug reports or PRs that had code that fixed it. This wasn't a case of people just being nasty - the maintainer wasn't interested in people doing work to fix it, either. >Your comment is precisely what entitlement looks like. This isn't someone asking for a feature request or minor bug to be resolved and whining when it didn't happen. This is a security vulnerability in a popular package where detailed reports are provided and the maintainer has a history of not accepting feedback, PRs, etc. on similar issues in the past. Security vulnerabilities are a big deal: They have implications for not just the user or company that is making use of the software, but also potentially any end users. This is a web framework - a good portion of projects using it are going to be public facing. A good portion of those are going to be storing user accounts and information about the users. A security vulnerability puts all of those people at risk too. I maintain that any project that you make publicly available you have a moral obligation to resolve security issues if it is at all within your power, and to disclaim them prominently if it isn't. If I've got a free lemonade stand, but every glass contains a toxic chemical that will activate in my body if a malicious person sprays me in the face with another chemical, people sure as hell can bitch about my free lemonade, even if they could go run it through a filter and remove the toxic chemical.

ncmncm 7y ago
No. Fork anytime you want to use something in production and don't consider it right. Post pull requests if you care to, and post your fork, too, if you like, being careful to keep clear that it is a different project. Some forks wither, some surge, some re-merge. It's all part of the dance. Any of it is better than flaming somebody who makes a thing and offers it.
7y ago

tunesmith 7y ago

If you make your project public, does it by definition mean you are open to other people using your release? I think there's a difference between "Hey, use this project of mine," and "If you use this project, you're on your own..." I think a lot of these debates come down to this confusion. Some people assume the former (and expect some level of response), some the latter (and say it's as simple as forking if you have a problem). Therefore I think anyone who releases should - morally/ethically, not legally/license - state what which philosophy they are following. It'd be interesting if people could release their projects "abstract" fork-only. So they could publish releases that would be vetted and merged into the downstream forks, but would never be released as a deployable itself.

kelnos 7y ago
It's really hard, though, because you'll always get people who will feel entitled. In the distant past I've released things and explicitly put in the readme something like "This is provided in the hope that it will be useful; I do not have time to support it and will not accept requests for help, but will consider merging patches that fix bugs or add useful functionality". And yet I still got people who would ask for help with it, or file bugs without patches and then get angry when I wouldn't help them.

yellowapple 7y ago

> It's not like he was getting paid to work on this, was it? So? If I'm donating clothes to one of those coat drives, and the clothes I donate are tattered and covered with rodent feces, should the organizers of said drive not be upset with me? Especially if said organizers point this out politely and I respond with "lol you'll take what I give you, peasant"?

vfclists 7y ago

Reasonable expectation does not equate to entitlement. So what is the person who finds the flaw supposed to do: 1. announce to all the other users of the library to download his branch with just the single fix 2. report it to the maintainer with a suitable patch, discuss it, and hope the maintainer applies it sooner rather than later. TBH the maintainer sounds like the boy with the soccer ball who ends the match and takes his ball home with him, because the opposing side scored against his team.

atoav 7y ago
To me the maintainer sounds more like the boy who brought everybody cake and then left the party when the other boys started nagging about how their mothers would make much better cake and how his cake is all wrong.
- twic 7y ago
  It's more that he bought a cake, but it wasn't cooked in the middle, so there was a chance people could get food poisoning, and the other people at the party pointed that out and suggested ways to cook cakes more consistently, but the author really likes cooking soggy cakes, and he's never got sick from it so it must be fine, so he left the party and told everyone the others were mean to him.
  - comfyinnernet 7y ago
    It's more like he bought a cake but the brakes were faulty and it skidded off the road and killed an innocent trifle.

im3w1l 7y ago

Let's say some charitable person hands out food to the poor. Only it's cooked with bad hygiene and people who eat it fall ill. People can and should warn tell each other to stay away. Even if his feelings get hurt. Even if he was only trying to do good. I think this is a good metaphor because how bad the food is is key. If it's just a little bad he is doing a good thing. If it's a little bit more bad it's neutral and people can take it or leave it. And if the quality is really bad that's when people need to protect themselves and each other by dragging his name through the mud. I'm not familiar with actix so I wont presume to say which category it falls into.

mayankkaizen 7y ago

Although I agree with you but there is one more point to consider. Why do people write open source libraries/frameworks? You'd say they write it as a hobby or learning experience and this is totally fine. But why don't they keep their work private if they aren't or shouldn't be bothered about how people use their libraries? I agree OSS maintainers do a lot of work but no compensation in return. I believe most maintainers actually strive to remove flaws/bugs in their projects. But if you write a half baked buggy OSS which is used by many people, you definitely should have some sense of responsibility towards users. Otherwise keep it private or at least boldly acknowledge that your project is merely a toy project which has many bugs and you aren't bothered about those bugs.