> It was never Nikolay's job to vet actix-web for you, nor did it become his job when the library became popular, nor does invoking "security" change anything in the slightest.
I don't think the anger is directed at there being security issues, the anger is directed at the fact that even when security vulnerabilities where found and patched, there was major pushback even getting those patches merged into the library. And regardless of how strongly you feel about 2), the community is extremely validated in saying "Hey this library in a language that professes security isn't secure and the maintainer doesn't seem to care". These statements aren't mutually exclusive
>the community is extremely validated in saying "Hey this library in a language that professes security isn't secure and the maintainer doesn't seem to care"
Yes, but that's not what they said. They were hateful and virtrolous, which is never appropriate. Fork it and fix the problems, create a new library which has the same API but is more sound, promote an alternative library in its place, offer to lend a hand in maintenance - these are the correct solutions.
> 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?
Cherry-picking a comment doesn't give a good representation of the community. The GP is right - most comments were courteous. The point is that saying "the community" was hateful and vitriolic needs more evidence than a couple of bad eggs, because those exist everywhere.
The parent comment still stands. Whether the maintainer was in the right or in the wrong, whether they were being a jerk or not, if he wasn’t listening to the community why not just fork the code? GitHub’s UI makes that super easy.
Just because it's easy to fork in the UI, doesn't mean it's easy to get people to switch. Some people are actually concerned about the community as a whole, rather than their own projects.
Counter: what about the tension and potential community split when a fork starts getting popular?
I was there (as a user who closely followed development) during the nodejs > io.js split. While it worked out in the end, it felt like a bitter battle at first. Node survived by chance perhaps.
We have our async-std vs Tokio right now, I'd imagine having another split (at least in opinions and preference) on actix would still keep tension high.
nodejs <=> io.js split was a great evolutionary step.
It allowed for the chaffs to fall through making node a stronger project because it was clear that neither of the sides was going to "win" outright.
If the argument is that "maintainer is not doing his/her job of being a maintainer" and this argument is accepted by the users, then should the project be forked by someone who will do his or her job of being a maintainer, the users will flip their source repo pointer and move onto the fork effectively killing the original.
The risk was worth it, node was stuck (in 0.12), and it was the whole thing, not "one of the things that you use to run JS on the server". A fork of actix wouldn't enjoy the same conditions that existed with Node.
Does the fork care as much about TechEmpkwer benchmarks? What happens if it is slower because it forbids unsafe even where it makes sense?
There was a looming cliff in Async/await, which caused a split to some extent (some old libraries that no longer have maintainers, changes that make updates difficult). A fork with those changes looming would mean divergence when rewriting to support Async/await.
Maybe I'm being too cautious, but I doubt we'd have had a successful fork earlier. Let's see if it happens now ...
You're lumping a few bad apples (apparently recruited from Reddit) in with "they". The users who found the bugs and provided patches were largely courteous considering the circumstances.
Steve Klabnik makes this point in his write-up, but I'm restating it here for clarity. You don't get to cherrypick who is part of your community or not when these situations arise.
Those "bad apples" are part of the Rust community, and the Rust community needs to take responsibility for them the same way any community needs to take responsibility for their bad apples even if it's just to denounce their behaviour.
Good thing that those who submitted the patches and PRs were polite; they're not the ones who caused this maintainer to quit though I'd wager...
I wholly agree with your viewpoint in this comment.
There is a prominent "Fork" and "Clone" button in every GitHub repo. If you're so fucking sick of the lack of support from the maintainer, fork it, fix the flaws that you've found, and assume some of the responsibility for the project.
This whole situation is a bunch of people getting angry because of what they view as a lack of accountability. That's preposterous - the nature of GitHub and open source makes it super easy for you to assume some of that accountability yourself. The fact that so many people chose to get upset rather than assuming accountability speaks volumes to me.
As a maintainer, it is his choice which patches to accept. If you're not happy with his decisions, choose another project, fork it, or pay someone to do it for you.
> As a maintainer, it is his choice which patches to accept. If you're not happy with his decisions, choose another project, fork it, or pay someone to do it for you.
Sure, but that DOES NOT mean you're immune to criticism, especially when it comes to security.
Your type of argument could otherwise be used for pretty much everything - even large corporations. It's not useful.
> Sure, but that DOES NOT mean you're immune to criticism
The problem wasn't the criticism, but the expectation that said criticism invokes a certain behavior of the maintainer.
You can criticize open source maintenance by creating a fork in which you outline your vision (e.g. "much less use of 'unsafe' in the web package") - and deal with the burden of being a maintainer.
Everything else is just trying to force people to do stuff for you, and that's rude.
FWIW, I don't have a dog in this fight. On the one hand, there is the maintainer who is within his rights to accept or reject patches as he wishes (although it's not great that he's allegedly falsely advertising his project as secure) and you have critics who are within their right to criticize (although it's not great that much criticism is vitriolic, etc). As TFA says, it's a sad affair all around.
> The problem wasn't the criticism, but the expectation that said criticism invokes a certain behavior of the maintainer.
Of course it implies that the maintainer should change. All criticism implies an expectation of change, at least when the opportunity to change is still available.
> Everything else is just trying to force people to do stuff for you, and that's rude.
Criticism isn't "force" or "attempted force". This is just criticism. If you think criticism is rude, that's fine. Hypocritical, but fine.
You can't rationally say the maintainer is within his rights for rejecting security patches and then argue that critics are wrong for criticizing these practices.
> Criticism isn't "force" or "attempted force". If you think criticism is rude, that's fine. Hypocritical, but fine.
No, the attempt to make somebody do what you want by brigading is what's attempting to exert force and what's rude.
Hiding that behind "I'm just criticizing" (you didn't, but it's a popular refrain in such "debates") is more than only rude, it's also cowardice.
> You can't rationally say the maintainer is within his rights for rejecting security patches and then argue that critics are wrong for criticizing these practices.
The author of the package didn't force their code onto the users.
The authors of the criticism forced their criticism on him by throwing it his way in the form of bug reports etc. even when it was clear that there's no interest in it.
> No, the attempt to make somebody do what you want by brigading is what's attempting to exert force and what's rude.
Unless the critics are engaging in threats, intimidation, and/or violence, we're talking about criticism and not force.
> Criticism isn't "force" or "attempted force". If you think criticism is rude, that's fine. Hypocritical, but fine.
No, the attempt to make somebody do what you want by brigading is what's attempting to exert force and what's rude.
> The author of the package didn't force their code onto the users.
No one is arguing this. Weird straw man.
> The authors of the criticism forced their criticism on him by throwing it his way in the form of bug reports etc. even when it was clear that there's no interest in it.
Wow. I really didn't anticipate the "bug reports == force" equivalence.
I don't know that I agree with the parent post equivalence of "bug reports == force" but I think there is a point to be made that this wasn't just people speaking poorly or offering criticism. There is a real difference between posting your criticism on a platform you control and filling up the issue tracker used by the project. There is an aspect of coercion in that the maintainer has to choose between expending effort to combat the flood of unwanted issues or abandon the use of the issue tracker. They can't just decide to ignore the criticism.
Re. "The author of the package didn't force their code onto the users," it's not really a straw man. People are arguing that the author has moral responsibility for their use of his code. That ignores the fact that they actively chose to use his code. The only way the author would be morally responsible for their use of his code is if he had forced them to use it somehow. So yes, people are basically arguing this.
So basically, if you use open source code in your code, you should expect there to be security vulnerabilities which people know about and are keeping quiet about because it'd be unfair to the unpaid creator to criticise them? Tbat sure makes it sound like it's morally irresponsible to use open-source rather than purchased commercial code in something like a web-facing service in 2020, especially given what we know now about the damage compromises can do and the resulting legal climate.
You can report on security vulnerabilities in a library without being vitriolic.
Find vulnerability. Already, awesome of you to have done. Issue patch request. That's 10x even better, you're a boon to the community. You submit it, it gets rejected, you find out why and it's the maintainer is just not feeling it or some other irrational reason. Fork, put in the readme why you forked, write a blog post without being a dick about it, done.
The article we're talking about is referring to the bloodbath of a Reddit pile-on. That's totally unacceptable behavior from an adult.
Please don't twist my words. I never said you have to keep quiet or that you're not allowed to criticize. If you see that a project has serious issues, feel free to write a blog post about it. Maybe offer to help, but don't demand your help being accepted.
- full rights to modify it and use it as it was your own
There's no other guarantee.
So if someone writes some code that becomes highly popular, they have no obligation whatsoever to maintain it the way people want.
They don't even have to maintain it at all, if they don't want to!
It's out in the public, it's free, that's the end of the agreement on the creato's side.
If a writer gave away their writings for free, could people pretend that they write what people want them to write, the way they want?
Is it fair to judge the writer because the answer was "WONTFIX"?
But the reality is worse than that.
A lot of companies are literally making billions using OSS, but they are not paying for it, a lot of programmers are making a lot of money by assembling OSS for their clients, but they are not paying for it, hell most of them are not even contributing in _any_ way, what does entitle them to pretend the attention of the OSS maintainer or that the maintainer should act in a way or another, according to the "community" desires?
Yes. I would expect there to be vulns and inconsistent patching for all OSS that I depend on and where I don't have a professional contract with its maintainers.
>Sure, but that DOES NOT mean you're immune to criticism, especially when it comes to security.
But our society does not just openly accept giving criticism. There are rules. Unwritten and extremely vague ones, no doubt, but still social rules. This is especially so when criticizing something a person is providing for free. In this incident, did the criticism cross the boundary and violate those rules? It seems so. Many people likely gave respectful criticism that followed the rules but they appear to have been drowned out by those who did not.
Security isn't a special license for being nasty. Criticism is fine, even with some urgency due to security being important.
But software done for free by volunteers carries no obligation of a legal or even a moral kind, whatsoever. This is completely different from selling software or doing work for hire or donations. There a moral and often even legal obligation exists.
no your argument isn't useful. the question is never about rights because we all know what the maintainer's rights are (so it's always a discussion of obligation).
if you accept that the open source projects are voluntary as an axiom then you in fact cannot criticize choices made by the volunteer.
here's an analogy: a homeless person asks for money. you don't give him money but buy him food. can the homeless person rightfully criticize you?
A homeless person asks for money. You don't give him money but give him some advice. Can the homeless person rightfully criticize you?
You can absolutely criticize choices made by volunteers. I don't think you need to think too deeply about this to imagine situations where few would object to criticizing a volunteer's behavior. An obvious one would be if an open source maintainer willfully included malware/etc. into their project - which, to many people, ignoring glaring security issues is vaguely equivalent.
I obviously don't think vitriol is warranted ever, but criticism obviously is from time-to-time.
what is the relationship of your analogy to this situation? is the maintainer the homeless person in your analogy?
you can criticize all you want as an exercise of your critical thinking faculties but the volunteer is not in anyway obligated to heed the criticism.
"it's my money/time and I'll spend it how I want, which includes burning it"
is the fundamental axiom. Given that that is the foundation what sense would it make to criticize that person for burning the money - it's right there in the premise that they're allowed to!
> what is the relationship of your analogy to this situation? is the maintainer the homeless person in your analogy?
It's your analogy, you tell me.
> you can criticize all you want as an exercise of your critical thinking faculties but the volunteer is not in anyway obligated to heed the criticism.
Nobody said they were. Nobody's trying to punish the maintainer legally. That doesn't mean criticism won't be offered or warranted.
Here's another analogy: You have a right to be a jerk in real life. Nobody's going to physically or legally stop you, barring extreme circumstances. People will still criticize you for being a jerk, as is THEIR right.
in my analogy you're the homeless person and the maintainer is the charitable person. in your analogy the homeless person is getting advice from ...?
>People will still criticize you for being a jerk, as is THEIR right.
completely specious. code in a github repo is not active participation in society. the fact that it's public does not mean it's been submitted for evaluation in any way. criticizing a thing that wasn't critically submitted is meaningless. it's like calling my practice sketches inferior to commissioned pieces - no shit that's the point!
> in my analogy you're the homeless person and the maintainer is the charitable person. in your analogy the homeless person is getting advice from ...?
the maintainer?
> completely specious. code in a github repo is not active participation in society. the fact that it's public does not mean it's been submitted for evaluation in any way. criticizing a think that wasn't critically submitted is meaningless. it's like calling my practice sketches inferior to commissioned pieces - no shit that's the point!
Uh, what? By packaging something as a crate, by listing it on crates.io, you're submitting it to be used. If you don't want it to be used or evaluated, at all, why in the world would you publish something as a crate on a public registry?
This is more like submitting your sketches to a public art gallery and then being upset when the public criticizes it.
>This is more like submitting your sketches to a public art gallery and then being upset when the public criticizes it.
that's not what happened. there weren't simply discussions of the viability or soundness or the crate. there were implicit/explicit demands for changes. so your analogy is wrong again - it would be like submitting public sketches and then facing demands that the sketches be improved. does that sound like something that i as the artist should be comfortable with? more importantly does that sound like something a reasonable person would do (make demands for alterations to sketches submitted to a public art gallery)?
what are you talking about? The code was submitted to be used by the public as a crate on a public registry. There were ABSOLUTELY discussions of the soundness of the crate - that’s literally what sparked this issue, security flaws in the crate.
Are you sure you have a firm grasp on what actually transpired here?
And people are allowed to criticize his reluctance to accept those vital security patches, because he submitted code packaged as a crate to be used by others on a public registry.
By publishing something to be used by others in a public registry, you are opting in to receive criticism from the public.
Criticism is not the same thing as vitriol and I’m not endorsing the latter even one iota.
You've broken the site guidelines egregiously in this thread. Since you also have a long history of breaking the HN guidelines, we'd normally ban an account for this, but it has been posting pretty well in recent history, so I won't ban it this time.
you know what would be useful mr. arbiter-of-what's-appropriate? if you would point out exactly what you believe i've done that is "egregious" instead of just vaguely alluding to the guidelines page and leave it up to interpretation/divination/mind-reading. as far as i can tell i've engaged in a good faith discussion/debate and it was solely this other person that shouted/antagonized. the only informal (could be perceived as antagonistic) thing i did was remark on how that person was moving goal posts after i clarified and produced reasoning for my position and how i'm glad that one valuable thing that came out of the exchange was i learned to avoid them in the future. as far as i can tell in the comment chain, it was the other person's that got flagged first and was the source of the tension.
there's something so aggravating about how you preside (note i didn't call it moderation) over these forums. what is the point of a voting system if you can unilaterally censor and censure? you know what the pretense to "objective" and "rational" discourse of this forum does? it inspires the kind of arrogance you see here on so many posts - absolutist positions on everything from tech to healthcare to history. the brand of yc and you and the rhetoric of the guidelines and you all function as an aegis.
For starters, "man i'm glad there are identifying details about you in your profile so i can avoid working with you" is an egregious personal attack, certainly something we'd ban accounts for, especially when they have a history of breaking the site guidelines.
> what is the point of a voting system if you can unilaterally censor and censure?
HN is a constitutional democracy. I can see why you'd find it annoying if you're assuming otherwise. We can't go by upvotes alone—if comments break the site guidelines, it doesn't matter how upvoted they are.
The voting system alone doesn't regulate itself—it leads to flamewars because indignant and unsubstantive comments frequently get upvoted. That's why there need to be countervailing mechanisms like flagging and moderation.
i would love for you precisely identify what part of
>man i'm glad there are identifying details about you in your profile so i can avoid working with you
is an attack. it's an expression of my personal exasperation. there's literally not a single ascription of any qualities to the other person. you can ctrl+f "you" or "your" in this subtree
and i in no place ascribe any qualities to anyone. my only other remark was pointing out the other person's belligerence which i still didn't make personal.
so either you can claim that there's something like a "zero tolerance" policy for antagonism or you can retract what you've accused me of.
this is my overarching point and has been for years on hn: it's evil to paint with a broad brush people that are actually antagonistic and those that don't feel they should toe the line in response to those people. your constitutional moderation is this brush.
it's not about whether someone is above criticism - it's about whether criticism makes sense in the context of what's being proffered. in another part of this branch of the thread i make the analogy with a an artist's sketch posted to a public art gallery. it's not that you can't criticize, it's that it doesn't make sense to criticize because the artist isn't attempting to achieve anything.
maybe a better analogy is if i play a pickup game of basketball and i get labeled a bad player for not trying my hardest. it's not that the criticism is misplaced it's that it doesn't make sense at all - i wasn't trying to be a good player! i was trying to have fun.
That’s not the issue at all, and we know this because the project was advertised as secure and the critics were arguing that it wasn’t advertised as such. This is characteristically different than your basketball analogy because it is neither explicit nor implicit that the project was unsuitable for production. Drew is arguing that the criticism is invalid because maintainers are within their rights to even lie about their projects because all responsibility lies downstream. Note that security DOES indeed lie downstream, but Drew is mistaken for arguing that this downstream responsibility immunizes maintainers from such criticism. This is a non sequitur.
I don’t understand the desire to make this out to be a sort of dichotomy—both groups have the right to do what they did (the maintainer to reject patches and even allegedly lie about the security properties of his project and the critics to criticize even in bad taste) and both parties could have handled it better. TFA did a fine job for implicitly acknowledging this by simply referring to the situation as sad all around.
>That’s not the issue at all, and we know this because the project was advertised as secure
this is so weird to me. i have a really difficult time on hn often because i don't understand why people that claim to be intelligent can't distill out the fundamental/primary issues.
it's a free/proffered/donation/voluntary/no strings attached piece of code. that is the first thing that defines its use/understanding/existence/ontology whatever other words. everything else is contingent upon that. you can debate this point - you can say something about the social contract of open source software and your responsibility to the community if you yourself have benefited from other open source projects and etc but no one is debating this. everyone is debating aposteriori things.
if i put a mattress out on the street with a sign "no bed bugs" and you pick it up and it has bed bugs in can you be mad at me? can you take action against me?
i don't know what kind of framework i need to appeal to in order to underscore this issue so that people address it directly instead of things further down the line. i would really appreciate someone showing me how to either do this (put the focus on the thing i'm engaging with) or tell me why i'm wrong for focusing on that.
> this is so weird to me. i have a really difficult time on hn often because i don't understand why people that claim to be intelligent can't distill out the fundamental/primary issues.
I feel the same way, but not about /u/weberc2's post.
> it's a free/proffered/donation/voluntary/no strings attached piece of code. that is the first thing that defines its use/understanding/existence/ontology whatever other words. everything else is contingent upon that.
This is another of your own axioms. These aren't universal. In particular, if a maintainer states or otherwise implies that his project is secure and suitable for production and then behaves otherwise, criticism is warranted. Even if he doesn't, criticism is still permissible.
> you can debate this point - you can say something about the social contract of open source software and your responsibility to the community if you yourself have benefited from other open source projects and etc but no one is debating this. everyone is debating aposteriori things.
No one is debating this because it's not necessary. The maintainer's explicit assertions about his project (its security, etc) override implicit "social contract" responsibilities.
> if i put a mattress out on the street with a sign "no bed bugs" and you pick it up and it has bed bugs in can you be mad at me? can you take action against me?
Not sure, but I can certainly criticize you.
> i don't know what kind of framework i need to appeal to in order to underscore this issue so that people address it directly instead of things further down the line. i would really appreciate someone showing me how to either do this (put the focus on the thing i'm engaging with) or tell me why i'm wrong for focusing on that.
In general your arguments are based on your own axioms. If your axioms aren't widely-shared, then you will run into these sorts of disagreements.
>This is another of your own axioms. These aren't universal.
how is this my axiom? it's on github. no one has paid for a license (the license is completely permissive).
>In particular, if a maintainer states or otherwise implies that his project is secure and suitable for production and then behaves otherwise, criticism is warranted.
is that part of the TOS of github? is that part of the bylaws of the guild of software engineers? is that in the bible? where is this codified except in this thread around this issue where everyone is mad?
>Not sure, but I can certainly criticize you.
you can do whatever you want. you can stand on your head and recite the star spangled banner. i'm posing the question whether it's reasonable. is it reasonable to criticize me for putting that mattress there in that state?
>In general your arguments are based on your own axioms
again they're not mine in the least - i did not coin the phrase "don't look a gift horse in the mouth". that is much older than me and fairly universally understood/accepted.
It's your axiom because others don't believe it being on github or free immunizes the maintainer from criticism. Licenses and GitHub ToS have no authority over who may or may not be criticized. You reason that it's not eligible for criticism because you hold the axiom that it is unreasonable to criticize open source projects. The "gift horse" phrase doesn't apply to situations where the "gift" is a liability; i.e., something that could leave you worse off than before--the Trojans would have done well to look their gift horse in the mouth, for example.
This has been the argument throughout the various discussions -- that somehow if there isn't a payment structure between party A and party B, there is full immunity from criticism, questioning, expectations, etc. It is absolutely insipid and is a logical non-starter that doesn't pass the most basic of considerations. Yet it keeps recurring. It's bizarre.
As a maintainer, I treat almost all PR submission with kind words.
What actix developer did was, to pardon my French, inexcusable. Deeming security patch boring? Making your own `Cell`, implementing it badly and misusing it, because it's faster on some stupid benchmark site?
If we designed cars like that, they would have no breaks, no gears and no cabin.
Honestly, I think it's better Rust abandons `actix` asap. Before it gets any real traction.
The same "stupid" benchmark site let to dramatical improved .NET Core performance , re-engineered the .NET Server stack and even changed the C# language on the way.
I do not know how the Rust community manages performance comparison, but the .NET bubble was broken by that page and resulted in awesome results for the platform.
PS: just pointing out what the page achieved somewhere else. The discussion about the maintainer and what happened there is a different topic.
But from what I heard, to get where it is, actix developer took some really bizzare shortcuts. E.g. hardcoding parts of response. On top of general unsafe usage.
I think the benchmarks are flawed, since they don't account for such "optimizations".
The benchmark is very smart in that sense. It has multiple stages (e.g. plaintext, db access,...). It proves with each stage deeper into your stack. You can disable there parts of your stack (e.g. middlewares, views, controllers, ...) and just operate on low level http request response pairs. And there you can hardcode on top then (as the application). The stages of the benchmark are optimized for testing individual disciplines like the connection and memory management of the low level http server and parser.
In .NET case they changed the language in response to the needs of the Techempower benchmark (and the Unity3d engine) to allow safe and performing ops. .NET also has the unsafe keyword for low level ops and is surely also used. The advantage of .NET is that it was a team with a central manager who pushed all areas, http framework, base class library and language into the same direction. A community like Rust does not have that privilege.
The "boring" was in response to the comment above it, which was discussing if the patch is large enough to merit a statement that they are contributing under the projects license.
The patch was "boring", not substantial to claim copyright.
Sure, but once you’ve forked, now you have a fork only you use, but which you know is more secure than its upstream for reason X. That’s an unstable equilibrium—you want others to know of your fork, and to switch to it, so that other downstream projects can also be more secure.
Adding to this, you might still transitively depend on the upstream through your other deps in ways you can’t change without either forking all your deps... or getting them to switch.
And what does “getting the ecosystem to switch” look like? It looks a lot like complaining about the upstream, such that others in the community understand what the problem is that your fork is solving.
The level of entitlement here is absolutely insane.
If the community cares about security then should this happen:
> Sure, but once you’ve forked, now you have a fork only you use, but which you know is more secure than its upstream for reason X. That’s an unstable equilibrium—you want others to know of your fork, and to switch to it, so that other downstream projects can also be more secure.
The community would move onto your secure fork and the author of said fork would become a maintainer. As Dave Rand, the CTO of AboveNet used to say to newcomers who used to say 'X should be done!' -- "Thank you for volunteering - you are now in charge of X."
Following Dave Rand's framework, the conversation went something like:
"Atrix-web should not use unsafe"
"Thank you for volunteering - you are now in charge of making atrix-web not using unsafe"
"Thank you for delegating responsibility of making atrix-web not use unsafe, to me. I accept responsibility for this piece, but you are still the leader of $PROJECT." <workworkwork> "Here is a PR that makes atrix-web less unsafe."
"I don't accept your PR."
Dave Rand's advice doesn't apply here, as several people picked up responsibility for making atrix-web less unsafe, put forth the work to do so, but were rejected. It's one thing for me as a user to feel entitled to everyone else doing what I think they should, while not putting in any effort, but IMO it's less clear cut when I'm putting my money when my mouth is, and submitting PRs.
None of the people made it safe because it is not in the code.
Fork it, make it "atrix-web-safe", post about it on whatever rust announcement list/forum/group is and have people move to the "atrix-web-safe". That's leadership. The rest is moan-fest.
If you fork on GitHub, they take care of letting people know.
I've forked a few abandondedish projects, and other people seem to find the patches. The best example I can think of is stud, which the people behind Varnish adopted and renamed to hitch; they surveyed the landscape and took good patches from most of the forks.
I might not look for forks from a more active project, but it's definitely something I look for when I run into problems with software without a lot of recent updates.
If enough people support your idea you will get a new community around your fork.
Or you can pay the cost of bringing in changes from the upstream project. This happens a lot for commercial software. I remember having to maintain a “fork” of BEA’s WebLogic server for a year or two until they incorporated changes my employer needs.
If you depend so much on that code, if the security of your software depends on someone else's free work, why don't you hire that person to fix the bugs?
Of course you can criticize, but people are continuously demanding things, like "he should have labeled it as a toy project", "he should have given reasons why he didn't accept the patch", etc. And Drew is very right to say: No, he didn't have to do any of that.
You are right that he didn't have to do any of the things people pointed out but that doesn't mean choosing not to do them isn't fair game for criticism and "he should have labeled it as a toy project" and "he should have given reasons why he didn't accept the patch" seem more like fair criticisms than making demands.
> "he should have labeled it as a toy project" and "he should have given reasons why he didn't accept the patch" seem more like fair criticisms than making demands.
Those are demands. The toy project one is relatively low cost, but "he should have given reasons" brings with its lots of effort to do right - and then you get to do it over and over again, because the masses can fling shit at you faster than you can reason about it.
You know, there is a lot of "He isn't required" but I will say there are reasonable expectations that people have when a project gets to a certain level of exposure/downloads/etc. and while someone should not be "cancelled" or tarred and feathered for not accepting a merge request, if your project is a leader in its niche (Rust web frameworks) you should do better.
You publish your code to Github, you're part of a community. You make it open and allow for contributions and see people are using it, you should be clear about your level of give-a-shit.
Both are true. I obviously can't trust that maintainers will do what they SHOULD do via common sense and online civility, so I SHOULD vet them appropriately.
Why do so many people insist on being aloof and unhelpful in communicating to users of their software? What is so hard about offering a modicum of context for what people can expect of you as a maintainer? It's so ideologically rigid and unreasonable.
> You publish your code to Github, you're part of a community.
Maybe. The main issue I see with github is that it's impossible to disable pull requests there. We have that issue in the coreboot project, which uses github as a read-only mirror.
Maybe we should just shut that down to make clear that coreboot is not part of the "GitHub community".
I urge you to stop thinking about how aloof and unhelpful you are permitted to be, and consider how minimally helpful you could be in communicating to users of your projects.
In this case it meant people saying things like "you are bad and you should stop writing rust, forever" possibly with some more colorful words in there. Very hurtful things but at least not threats and actions...
If someone poorly implements something, potential causes harm in doing so, doesn't accept that they have done so poorly and express a desire to learn and improve in future endeavors, it isn't even necessarily incorrect to express that they may not want to pursue that particular field anymore. Of course it should be done tactfully which I doubt most of the comments on Reddit did. I see this same sentiment expressed fairly often on HN in usually but not always more polite terms.
In what way is it correct or even helpful? Even if done tactfully, I have a hard time seeing that being taken by anyone as anything other than a personal attack.
The correct response would be to organize the community to create a fork that is more focused on correctness and security than on performance.
It is correct and helpful because it can prevent continued poor behavior which impacts others. Trying to protect someone's feelings only goes so far. Sometimes you have to be straight and to the point with people whether they take it as a personal attack and it hurts their feelings or not.
Whether it would be appropriate in this I case I don't know but I disagree that it is never the correct response.
> it can prevent continued poor behavior which impacts others
I highly doubt that it would do anything to prevent that continued behavior. I cannot imagine a situation in which there is not a better and more appropriate solution to mitigating poor behavior that telling people "don't participate in this field". At best you will alienate them in such a manner that alternative approaches are less feasible and at worst you convert bad behavior from being passively to actively malicious. I'd be curious if you have a concrete example for when you think this approach has been beneficial in any context.
Note, I consider revoking credentials (e.g. disbarring an attorney or revoking a medical/engineering license) to be something entirely different as there is an active endorsement that needs to be terminated. Relevancy in this case would be to removing a package from a package/dependency listing service/manager.
This is just your opinion, and not a fact or some kind of social rule. In fact, I would say that using your logic, I can say that you should never ever express your opinion on such matters again, since you clearly don't know what you are talking about. Just giving it to you straight. My opinion is fact. Respect it! Do you see the irony?
> it isn't even necessarily incorrect to express that they may not want to pursue that particular field anymore
Can I express that to people who think a volunteer project owes them anything & couldn't be arsed to implement the project's functionality themselves in the first place?
Somehow I don't think that would be a constructive use f time.
Rust is a programming language. Nothing more, nothing less. It is a tool. If I like the typing and macro systems used by Rust, but I do not care in the slightest about “memory safety” I can write my dirty, filthy ‘unsafe’ C style code with casts, and raw pointers, and multiple mutable references in a giant unsafe block and get a compiled binary out of rustc. And if I use the above style of coding to write a neat CLI tool and offer the code as open source on Github, so be it. What the purported ‘Rust community’ thinks the language professes doesn’t mean a thing. Use the tool or don’t.
I don’t want to come as negative toward Rust or developers using it, but there is a whole lot of using Rust’s ‘security’ focus/features to say the Actix developer needed to do things a certain way. He wrote he, he could do whatever the hell he wanted.
I don't think the anger is directed at there being security issues, the anger is directed at the fact that even when security vulnerabilities where found and patched, there was major pushback even getting those patches merged into the library. And regardless of how strongly you feel about 2), the community is extremely validated in saying "Hey this library in a language that professes security isn't secure and the maintainer doesn't seem to care". These statements aren't mutually exclusive