Actix project postmortem | Hacker News Reader

Actix project postmortem

github.com

338 pointsdabj397 comments

"Ok... So that was unprofessional. If you don't want to maintain a project anymore, you give it to someone else and link to that repo in your README.

This just screwed me over big time."

https://github.com/actix/actix-web/issues/1#issuecomment-575...

These kind of entitled attitude is probably exactly why the guy just removed everything.

More details / discussion here: https://www.reddit.com/r/rust/comments/epszt7/actixnet_unsou...

They're right, it was unprofessional... but since the maintainer is not being paid this is not a professional project. It's a personal project. And this seems like a perfectly personal thing to do with something that's preventing happiness.

Well, it's easy to get confused when you look at the professional looking website with a well crafted logo, a promo list of features and a copyright notice from the "The Actix Team". The community page even says "We're a welcoming community so don't be afraid to engage.". Ouch!

The easy way to tell is to remember if you're paying them or not.

That's not true at all. You can pay for amateur bullshit, and you can get professional software and support for free (and free as in freedom).

My Ethernet is stuck in ipv6, professionally tell me how to fix it, for free.

Sure, could you provide some more detail?

That's not an open source project any of us maintain.

Also, there are expectations for both sides of a professional interaction. My employer buys various fancy networking equipment for lots of money and we absolutely wouldn't expect an answer for that question.

I actually did that for years in a linux forum.

You can get professional software and support for free, until you can’t. This “you’ve provided me free support once, so it’s your obligation to support me for free indefinitely whenever I ask” attitude has certainly contributed to my open source exhaustion as a maintainer.

Well, good luck getting a company you paid for a product to provide indefinite support, large professional software companies cancel projects and EOL software all the time.

You only have a right to complain about the amateur bullshit you paid for, though.

You have a right to complain about anything and everything.

For instance, I don't pay a penny for HN but I can complain that these discussions sometimes become self-congratulatory prattle where angry people carrying a giant chip on their shoulder posit absurd, completely ridiculous notions and they're supported in their group delusion by like-minded parrots. You don't have to agree with my complaint, but nor do I need your or anyone else's permission to hold it.

Absolutely not. You can get professional (but not necessarily timely) support from me for multiple projects I maintain on GitHub, for free.

For many people, their personal interest in open source is writing code for fun and showing it off. For others, it's making a product that people can rely on. The second one is my motivation; don't take that away from me.

The distinction between "amatuer" and "professional" is literally the motivation for the action, i.e. if you are doing it for enjoyment vs if you are doing it to get paid or advance your career.

If you are making products that people can rely on primarily because you enjoy it, you are literally an amatuer.

There are figurative connotations of quality and polish implicit with those terms, but I find those connotations unfortunate and in many cases unwarranted.

Sure. I'm not saying I am a professional. I'm saying I will provide professional-style support (according to the connotation), just not necessarily in a timely fashion, and it's demoralizing when other people say you should avoid my amateur software because they're leaning on the connotations of "amateur" and "professional."

That’s fine. It’s even admirable if you to do that. But it isn’t and shouldn’t be mandatory.

While “mandatory” would be a stretch, I don’t think there’s anything unreasonable about expecting project owners not to overstate the maintenance level of their projects. Deliberately conveying a false impression to people is called lying, and it’s generally regarded as being bad.

Huh nothing you said indicates it is a professional project. Sleek does not equal professional.

Exactly. It can be argued it's unprofessional to become dependent on third-party software without any background recherche regarding the maintainer's motivation, team size, financial standing, etc., especially when said third-party software isn't a replaceable, standards-based component such as, say, Java Servlet containers and other web components used to be.

I absolutely agree with this. The author has spent an insane amount of time to build all this stuff and instead of getting recognition and/or being payed adequately he is getting shitstorm after shitstrom.

As an outsider I have to say that I think what the Rust community has technically achieved is remarkable. But on the social side it is not so bright, avid Rust users constantly spam forums of other programming languages with toxic comments. But this incident shows that the situation is even worse than expected, the Rust community even treats its own peers like sh..

Well, no different than any other tech where the community is an echo chamber full of fanboys. Linux used to be like that, especially some of its distros (uhm Gentoo?), cryptocurrency fans are like that, Apple users probably don't need mentioning neither ...

Gentoo is just a meme spread by some 4chan /g/ board's members. Maybe you meant Arch?

... Gentoo predates 4chan's existence by 3 years, is one of the older and more respected distros still around, and is the basis of Chrome OS and Container Linux. Don't assume that 4chan somehow defines the things they happen to be interested in.

"btw I use Arch" is a meme as well

Professional pursuits are things related to a vocation, not directly tied to an exchange of money for every interaction under consideration. If you're in the industry of software development, and tie your identity to an open source project, it is de facto professional.

In this example it is held as a significant accomplishment on this individual's linkedin page. Which isn't surprising as professional credibility is a primary motivation driving a lot of open source involvement. We are seeking a different, less direct form of compensation.

So it's fair to say that acting like this is unprofessional.

That doesn't mean it isn't merited, or that they might have been frustrated or had good reason. But professionally they would have been much better served by other means: Simply announcing that they're retiring from the project and encouraging forking and the percolation of a new canonical version, etc.

> It's a personal project.

If you create an organization on GitHub for a project that is meant to remain personal, this kinda sends a wrong signal.

Blaming some users for being rude and entitled, and then deleting an open source repo out of spite... it's a bit hard to feel sympathy for the guy here.

For information, the repo has not been deleted but simply moved: https://github.com/fafhrd91/actix-web

> If you create an organization on GitHub for a project that is meant to remain personal,

Sounds like there were intentions or plans to transform a one man project into something bigger. Some steps were made. Hence, a nice looking website, a github org, benchmarks etc. All those signals are intentions, the vision of the future self. They may or may not come true.

Nothing signaled an established business model or sustainable backing of any kind.

> And this seems like a perfectly personal thing to do with something that's preventing happiness.

Sure, if you want to spread the misery. That's still kind of a dick move, even if he's perfectly within his rights.

Now due to that comment actix maintainer has disabled issue too. I don't know why people show such attitude as if they are paying him to do opensource.

It is your choice to use open source software without open sourcing your own work or without contributing.

But by engaging in open source you engage in a social contract, you become part of a community whose goal it is to foster collaboration and help one another, other people start to rely on you, just as you rely on their libraries, compilers, and kernels.

The author choose to break that social contract out of spite. He created a scenario where people choose to rely on him, when they could have relied on other works, and then screwed them over majorly.

"The actix author almost certainly (unless they deploy their own kernel) has profited immensely from other peoples work."

Prove it.

"But by engaging in open source you engage in a social contract" https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...

>> Prove it.

Actix was written in rust. Rust is OS. qed.

Quote from Rich's gist.

>> I'm sure you know better about the one true way to write software. But kindly don't burn the community down on your way out, with self-serving proclamations.

The actix author could just have walked away, no harm done, push one button "Archive", go outside and enjoy the sun.

Instead they choose to throw a tantrum, write a pamphlet and nuke everything.

Entitlement goes both ways.

> The actix author almost certainly (unless they deploy their own kernel)

... or use Windows / MacOS / Solaris / any other commercial OS he paid for...

> by engaging in open source you engage in a social contract

You heck. You simply allow other people to use your work as they see fit. That's it. The only contract is the license, and the license is very explicit in denying the existence of any other tie, explicit or implicit.

When you hold the door open for somebody you don't sign shit, yet it's implicit that you don't swing the door in their face.

But you don't hold a door: you are dropping a package on the street and letting people pick it up. Anyone can reuse the cardboard, paint it red, stack it up with other packages, or hang it on their livingroom walls... but there is no guarantee that the package won't contain a bomb, that the cardboard was made by eco-friendly methods, or that it will last one second after getting dropped on the streets.

Yes and pushing the archive button is saying "I won't produce any more packages sorry."

What they did was climb through everyones window to get the cardboard box back, just as with the npm leftpad incident.

Stop painting the narative like people demand some volunteer to do more free work, when all they do is ask to not be actively sabotaged.

No, he didn't break into people's house, started their computers and started deleting stuff. It's all the same as the day before yesterday.

Except for they didn't simply push a commit which replaces the code with a readme that tells people to go maintain it themselves or fuck off, they emptied it, rewrote their history and did a git push --force.

And frankly I don't buy the story that they wanted to put the code on their own repository anyways, seems more like a concession because the other contributors also hold some copyright.

No, he just stopped dropping the package on the street every Monday at 7am. Whoever picked up the package in the past, still has it - or had the option to preserve it.

If your workflow relied on a package being delivered every morning, even unchanged, it's your own fault. He never made that guarantee.

Stop painting the narrative like people owe you anything, when you're just failing to correctly evaluate the actual resiliency (non-)guarantees of production pipelines based on random github repositories.

Yeah there's this common concept in society called trust, aka a social contract, that people don't advertise their stuff first only to deliberately screw you over.

And yes shockingly people are entitled to be treated fairly and not to be sabotaged. And no, providing them with a library for a limited period of time and then being fed up with it's maintenance doesn't somehow earn you that right. It gives you the right to walk away, but clearly thats wasn't enough for the author.

But hey if you want that to live and bathe in that kind of toxicity, enjoy!

Caveat Emptor.

That's the bare minimum of what you can do, which really just constitutes dumping your code on GitHub, slapping an unmaintained label in the readme, and calling it a day

But we can go beyond that, and start to do more work, and make grander social promises. Calls for a "community" come with the implicit agreement that this codebase now exists for more than just the one person who initialized it. And that you've pushed it into the public, and requested people to treat your repo as the repo, you've taken on certain responsibilities, and made some implicit, or explicit, promises.

Sometimes the job is thrust upon the maintainer accidentally (eg Linus), and sometimes it is requested (apparently in this case?)

But nonetheless it's a natural function of the OSS community, and there are ways to deny the responsibility appropriately, and inappropriately.

But it's there is much more nuance to this than dumping a box, or reading a legal contract (which is never representative of social contracts; it's just the bare minimum to avoid responsibility in the eyes of a lawsuit.)

Lawsuits is how society distinguishes the actual social contract from wishful thinking. You are free to establish your own imaginary community based on imaginary rules of etiquette, but everyone else is free to ignore such "rules".

Sure, but people whose behavior is only constrained by law rather than the general expectations of good taste in their community are generally referred to as assholes or with some similar term to indicate that their behavior is disapproved of but not to the extent that it would make sense to prohibit.

> These kind of entitled attitude

If you offer code to the public – and present it as an active, dependable project – professional behavior is exactly what you implicitly promise and signed up for. If you can’t offer that (at any time, and for any reason), then you should immediately make that clear, front-and-center, to any current and future users.

It isn’t “entitlement” on part of the users – the users are making reasonable expectations based on promises implicitly made by the the project as it is presented.

I've never heard of "implicit promises". For me a promise is by definition explicit. Anything else are assumptions, in this case false assumptions.

In many contexts, there’s often an implicit promise to be courteous to others, even if it’s not defined explicitly.

From my skim of the maintainer's comment, this happened because people didn't keep their end of the promise.

I, and most people reading this, likely never interacted with this person. From where I sit, this is what's colloquially referred to as a "dick move".

“Implicit promises” is going into my Orwellian dictionary. What a farce, do people really believe such a thing?

It’s strange that you’re unfamiliar with the term. It’s an important concept in legal contexts, and the same general concept applies in all sorts of situations where people make reasonable inferences about other people’s behavior. It’s even called out as a real thing that is then explicitly denied in many OSS licenses, because otherwise such implicit promises might have legal implications.

Or to put it another way:

As an open source maintainer, you're perfectly entitled to just walk away. Hit that archive button on github so nothing new can come from the repo, and enjoy your life. Nobody could fault on you that. People would prefer you work out a clean transition to a new maintainer, but you have no obligation to do so.

Deleting the repos is the equivalent of setting the house on fire on the way out (especially when they're under their own org). Unlike in reality, it turns out it's totally permitted, but people will still view it as a dick move.

If you want to rely on some code that it takes even a second of your day to think about your response to author deleting that public code, then you fork it and simply track author's repo.

I don't see why.

Anyone that cared already has their local repository copy.

After all that is what DVCS are all about

Issues and pull requests are often useful documentation (for open source projects, sometimes the only documentation), links to files and lines of code are now broken.

That is what happens when one outsources everything to Github.

This would have happened identically even if the project had its own hosting, so outsourcing hosting to GitHub isn't a factor in this case.

Lkml doesn't seem to have this problem, and they are the original git users.

So all you need to do is get popular and important enough that several unrelated third parties will mirror and host your communications for you.

Or... publish everything as essentially a log in an openly accessible manner (ie. email as a on a list serv with it's web accessible archive), and places like archive.org will happily squirrel it away for you.

I wouldn't happen if instead of git, they used fossil.

It seems like the only "Fossilhub" is this: http://chiselapp.com/

I would guess that it would make it very hard to create a community around the project.

Fossil has everything built in including fully functioning web interface (in contrast to git).

The repo has not been deleted! https://github.com/fafhrd91/actix-web

From the bottom of the postmortem repo:

> At the moment I am planing to make repos private and then delete them (will remove benchmarks as well), unless others suggest better ideas.

so it's not deleted. it's the last call for all the people that wanted to profit from his work to take up the mantle and drive the project

something anyone can do right now, I would add

but people just prefer directing the guy work

Strongly disagree. For me, what's implicit is that any software, commercial or F/OSS, can be abandoned at any time - because that's just the way it is. A remedy would be to use software coded to a specification with mulitple implementations such that in case a project folds, you might be able to switch over to a different implementation. The Java EE ecosystem used to be like that until around 2012 or so.

Abandon is different from deleting everything.

Ofc, git is distributed, so someone should have a copy of the repo, even if it's not updated.

Edit: disregard post, apparently it's just moved to the personal account.

Not deleted.

> I moved actix-net and actix-web project to my personal github account. I will make decision during next couple days what to do. I don’t want to see the project becomes ghost of what it was. Maintainers must understand how everything work, but don’t anyone who does and those who could are busy with other projects. At the moment I am planing to make repos private and then delete them (will remove benchmarks as well), unless others suggest better ideas.

I see thanks

That's very much a "Not deleted _yet_"

With distributed version control, is anything ever really deleted? How does he have the power to delete everyone else's local copy of the project and prevent them all from forking and maintaining it?

https://news.ycombinator.com/item?id=22074620

> what's implicit is that any software, commercial or F/OSS, can be abandoned at any time

This is particularly true when you look at what licenses say:

... THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.

... THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.

... IN NO EVENT SHALL <COPYRIGHT HOLDER> BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

The onus is always on yourself to insure against everything.

Good examples

I do not think these expectations are reasonable. This line of thinking is definitely the core issue of the problem.

I think that's made pretty clear in pretty much every open source license: "Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND".

That’s a legal, not a social statement. Following the letter of the document that governs your work doesn’t mean you still can’t do something that would be inconsiderate.

I am honestly confused by this line of thinking. what should projects do in your opinion? should there be a LEGAL-LICENSE and SOCIAL-LICENSE?

I believe that the legal is the "top-level" statement that sets expectations all the way down.

Legal documents don’t really make an affordance for what would be impolite versus what would be against the license. Usually I think the unwritten expectations work out ok (for example, in a project I help maintain I recently wrote out an apology for stepping away from development and ignoring contributions to fulfill these obligations) but perhaps writing it down in some sort of Code of Conduct style document might be beneficial.

I think that people have pretty much put their "core values" into their licenses these days. People who don't want Amazon to run their software as a service use the AGPL. People that don't really want an open source project but want to put "open source!!!11!" on the box add caveats like "you can't run this code on a device you didn't buy from us" (very common in the keyboard firmware market).

If people aren't choosing a license compatible with their values, then that's on them. The era of Github only giving you free hosting if you pick a DFSG-compatible license are long over; you could put the Windows source code on Github and they would be happy to use a heart emoji to describe how they feel about it.

>If you offer code to the public – and present it as an active, dependable project

Not familiar with the project or Rust Ecosystem. Anyone else can comment whether it was presented / marketed / sold as an "active, dependable project" ?

As someone more used to the Ruby Rails ecosystem, I think the communities as a whole generally accept the convention that all open sources, whether they are backed by a single person or cooperate account, are given out as it is ( MIT ) and their maintainer or author will do the support or development as they could when they are FREE. And it is perfectly acceptable of forking it to make your own variation or improvement.

> professional behavior is exactly what you implicitly promise and signed up for. If you can’t offer that (at any time, and for any reason), then you should immediately make that clear, front-and-center, to any current and future users.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.

It's in big capital letters there. Explicitly no implied promises.

> It isn’t “entitlement” on part of the users – the users are making reasonable expectations based on promises implicitly made by the the project as it is presented

That is almost literally the definition of entitlement

Yeah, that's really the core of the problem, isn't it. People trying to impose an implicit understanding (which is nothing more that 'this is what I want the world to be like') when there's an explicit statement of 'this is how it actually is'.

The attitude baffles me. So many times I've had someone come in all butthurt and say 'I know it was in the contract, but I didn't think they'd actually enforce it'.

> So many times I've had someone come in all butthurt and say 'I know it was in the contract, but I didn't think they'd actually enforce it'.

or the converse situation "I know I used liberal license but I'm still going to raise hell if people actually do what the license allows"

No, that's not the converse. The license says exactly what it means, which is:

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,

Period. Calling it a 'liberal license' doesn't mean what you think it means.

To assume certain conditions that are not explicitly laid out without even talking to the person providing you the service is literally entitlement. It seems like you've made assumptions that turned out wrong. I've fallen for it too in the past. Not everyone thinks the same thing so people's assumptions are always different. The key thing is, when your assumptions don't turn out true, to learn from it.

In the case of open source, it's worth asking the maintainer what the terms are if you're unsure. The LICENSE always says that authors and contributors are not liable for any outcome, either as an ALL CAPS paragraph or a clearly defined section.

Everything is provided as-is so you can't expect anything. It's on you to pick up after them if you still need the project.

Exactly. The open source community is far from homogenous, and people who engage in it (maintainers, packagers, <s>leechers</s> users, etc.) tend to have wildly different expectations that vary from person to person. I’m sure RMS, some Contributor Covenant wielder and I won’t ever agree on a set of assumptions.

Moreover, companies present themselves as “active, dependable project”s then go belly up all the time. Not sure why hobby projects should be held to a higher standard.

No you don’t. You aren’t alone in assuming that, but it’s an entirely unreasonable expectation. And as evidenced by this exact thread, people like you cause good developers to stop maintaining their projects. Your attitude harms our community.

Practically speaking, if I give you some work I did for free yesterday, and give you some work I do for free today, that does not entitle you to free work from me tomorrow. It does not entitle you to free support on the code I’ve published already. I owe you my time when you’re paying for it. Until then, if I have made something you found valuable you are in my debt for its use. Not the other way around.

As a user of my software I generally give you two rights - you have the right to use the code in your project, and the right to fork the project. And as the maintainer, I have the right to spend my time however I want for the rest of my short life on earth. If the beach looks like more fun than putting up with entitled complaints on github and HN, that is my right.

Cool, you don’t have to work in the project if you don’t want to. But going and nuking it off the face of the earth so nobody can have it is still impolite.

It's good that git clones are all complete, full copies, including history.

And for that I am quite thankful that it is so widely used.

But they don't have the issues nor pull requests that were open when the repo disappeared.

Should have used fossil :)

Yeah, no.

If you put your code out there open, it's still your code. If people start to rely on it, they need to be ready to maintain their branch.

> If you offer code to the public – and present it as an active, dependable project – professional behavior is exactly what you implicitly promise and signed up for. If you can’t offer that (at any time, and for any reason), then you should immediately make that clear, front-and-center, to any current and future users.

As far as I can tell, this project was released under the Apache License 2.0.

https://github.com/actix/examples/blob/master/LICENSE

Clause 7 of said license says the following:

"7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License."

Other popular free software licenses (namely the GLP) have very similar clauses.

> It isn’t “entitlement” on part of the users – the users are making reasonable expectations based on promises implicitly made by the the project as it is presented.

Expecting labour from someone without paying them is the very definition of entitlement.

> Other popular free software licenses (namely the GLP) have very similar clauses.

What the license says and what image the project presents can be very different. Pointing to the license and reasoning that nobody has legally promised anything contractually is not very useful.

> Expecting labour from someone without paying them is the very definition of entitlement.

That’s a very mercenary view of the world. What about volunteer charity workers? Is it OK for them to just not show up whenever, just because they aren’t paid?

> What about volunteer charity workers? Is it OK for them to just not show up whenever, just because they aren’t paid?

I have some friends whose profession is running charities (i.e. they actually get paid). Volunteers not showing up is exactly what happens, all the time. And my friends expect it, plan for it, because the volunteer is not getting paid to be there. Without that tangible incentive, a volunteer time competes for all the other intangibles competing for time (e.g. "I'm tired", "the kids need something", "friends are going to do something fun at the same time"). They build it into planning: some percent of the people who signed up aren't going to show up...if the weather bad, a bigger percent aren't going to show up. And so on.

They don't get all ranty or judgmental about it, they're just smart enough accept that reality and to plan for that eventuality. Just like anyone using an open source project without paying for it should be.

> What the license says and what image the project presents can be very different. Pointing to the license and reasoning that nobody has legally promised anything contractually is not very useful.

It is quite useful, because the license is the legal document that comes included with the software, and that specifies what things you agree to if you use the software. And it explicitly specifies that you cannot assume any contractual obligations from the "image the project presents", or anything of the sort.

> That’s a very mercenary view of the world. What about volunteer charity workers? Is it OK for them to just not show up whenever, just because they aren’t paid?

I would say that if someone promises to do some charity work and doesn't show up without a good reason is breaking a promise, and is thus being a shitty person. People should keep to their word. Open source authors promised us nothing and owe us nothing. More often than not, we owe them.

> Open source authors promised us nothing and owe us nothing

There is such a thing as an implicit promise. A project which presents itself as active and maintained by a community does implicitly promise a certain level of attention by its maintainers.

> either express or implied

Did you miss this part?

There is such a thing as an implicit promise, but it does not trump an an explicit disclaimer of such attention. Which there is in this case. Once again, thanks for demonstrating the entitled attitude that brought this on.

Would you please edit out personal swipes and/or snark and/or name-calling from your posts to HN? Between this and https://news.ycombinator.com/item?id=22080698, you'd done this more than once in the thread. We're trying for curious conversation here, not flamewar rhetoric.

If you'd please review https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting, we'd be grateful. I appreciate how much your HN posts have improved, but it's necessary not to break the guidelines.

Lets compare it to an other type of volunteer based work, after school activity for kids. Some of those are going to be free, run by people who volunteer (usually other parents), with disclaimer policy that say that any responsibility is on the parent and no liability may be put on any of the volunteers.

Is there a social contract that put some expectations on the volunteers who are organizing the activity/event, and is that the definition of entitlement?

I would say there is such social contract, and when people expect too much of it there is also entitlement going on. Where the exact line goes is gray zone.

> professional behavior is exactly what you implicitly promise and signed up for.

Wise up. Professionals get paid, if you aren't paying some one they are not a professional. This is the reason why opensource projects provide professional support for pay, for professionals who need professional support.

> you should immediately make that clear, front-and-center, to any current and future users.

like, for example, in a license file?

> you implicitly promise and signed up for

Think about this. Do you really think it makes any sense to try to hold people to promises inferred by alternate parties that aren’t even providing any consideration in return?

Just think about that.

A large amount of human interactions work this way. It's fuzzy and messy, with many shades of gray, but the world is filled with implicit promises with varying degrees of commitment and severity.

Well sure.

That's exactly why I encourage people to think about it.

It's a delusion to believe random strangers owe you anything (beyond basic compassion and curtesy) and you'll continue to be unhappy until you let go of that delusion.

Apparently a number people believed this developer worked long hours on this project (for free) because they were obligated to do so. Not only was that incorrect, it seems to have contributed to the dev leaving the project since some people felt justified in making rude (and sometimes angry) demands.

Thinking about it is important because when you do, you can see there's no reason at all to believe that the dev would put in a lot of work for free to maintain a project while continuously receiving abuse from a reddit mob while doing so.

Is it entitled? Most would agree, "very" (but that's not my concern nor judgement to make)

Did the maintainer screw over people that were using Actix? Very likely.

I sympathize with both sides here. I've been the unthanked, punching bag contributor on a few notable projects, and I've been a user of software whose leadership got into drama and squabbles, that ultimately fucked me over.

There were times that I pulled certain projects and essays, that had greatly helped people, and taken my ball home because I was fed up with the people I was catering to. There is no correct answer here, dealing with people and their emotions, but there is a way for both sides to handle things without contributing negatively to other's lives.

> Did the maintainer screw over people that were using Actix? Very likely.

How so? Just find a fork with a decent maintainer, or push your copy to your own repo. Let the Actix guy do his thing and move on with life.

In open source you give and take. The actix author almost certainly (unless they deploy their own kernel) has profited immensely from other peoples work. This is because as a community we have realized that we don't sell libraries, we sell stuff build with them, so we all win when we share. It is your choice to use open source software without open sourcing your own work or without contributing. But by engaging in open source you engage in a social contract, you become part of a community whose goal it is to foster collaboration and help one another, other people start to rely on you, just as you rely on their libraries, compilers, and kernels. The author choose to break that social contract out of spite. He created a scenario where people choose to rely on him, when they could have relied on other works, and then screwed them over majorly.

Dude, sorry to break this to you! But basically any widely used software is supported by major companies just to avoid this problem.

Libraries, compilers and kernels alike.

If you want to rely on software being there, you should be ready to pay for people to support it.

> This is because as a community we have realized that we don't sell libraries, we sell stuff build with them, so we all win when we share.

It is clear to me that is not true anymore. It is really hard to find open source project without clear direct financial incentives.

Again, as a community, we should start to pay for the components we use.

Companies should contribute their fair share by supporting open sources projects monetarily, definitely!

But that is a different issue, from the behavioral standards we as a community uphold implicitly, and which are broken by pulling a "left-pad" incident.

I believe we should not demand free work from people only because they were nice enough to push their code on GitHub and let stranger use it for free.

I work in open source as well at both day job and for "fun" but I fix the issue that I want and if people want something from me as author of whatever, there is going to be a money talk.

To take the metaphor from a different user on this topic: "Its completely ok to not hold the door open for someone, but its extremely impolite to drop them into their face."

The author created a project and advertised it to people, if they don't want to maintain it anymore, sure, no problem.

But deleting it to spite others is considered a d* move.

> has profited immensely from other peoples work

Have they? how much $$$ profit did they make?

You aren't paying for shit and yet you think they are making a profit and you are entitled to professional support? Wise up.

Making a profit != profiting.

I profit from Clojure, Python and the linux kernel. Doesn't mean I habe an income from their existence.

Nobody is arguing about professional support, but advertising a project and then deleting the entire thing to spite people is a jerk move.

Ready up!

> Making a profit != profiting.

Thats exactly what it means.

https://dictionary.cambridge.org/dictionary/english/profit

I use linux to write python that I sell for a profit, I profit from these things, and I am happy to support these projects with my profits in return for professionalism I need to make a profit.

If I use them in a personal project I benefit from them not profit, and I certainly don't expect anything more than the benefit of not having to write that code, the rest is up to me.

This is pure entitlement.

From your source:

>> the good result or advantage that can be achieved by a particular action or activity

Once it's public and people depend on it you can't retract it like that. His goal was to make his work public, not private.

Why?

It’s no longer “his” code.

The point of open source is that people can maintain their own forks etc. There's plenty of mirrors of actix I'm sure.

You can retract it. He just did it. You can take down any webpage under your control. I could delete this comment later if I like. You could delete yours. etc.

> I could delete this comment later if I like.

Now you can’t.

You basically can. The cost of free stuff like this is "be nice to the guy giving it to you" or at least don't be actively abusive about it. If the community won't pay that price, expect it to evaporate.

> The cost of free stuff is "be nice to the guy giving it to you".

Can I get this on a poster please? Really well put.

This goes both way though. Be nice when people submit patches especially when you reject them.

The abusive comment seems to have been a knee-jerk response from someone dissatisfied by the "it's boring" comment about a proof-of-concept patch.

It's absolutely correct that people don't have obligations simply by putting some code online. But they do have obligations when they start telling people to use their code. We understand this as humans even in realms far from open source: if I see you approaching a door, I am under no obligation to open it just because I'm physically able to, but if I open a door for you, I'd better hold it until you're finished walking through, or I'm a jerk. By holding the door open, I've made an implicit promise that I'm not going to close it on you.

It's not very hard to say, this is a project for my own technical interest, I don't intend to follow Rust norms about use of unsafe, and you shouldn't rely on it, but here's the code if anyone wants to look. That's fine! (And I do think we need to be better about making it common to do that. GitHub has no good tooling for such a repo, for instance: you can't disable pull requests unless you archive the project or make it private.)

But that's not what Actix's docs say. See https://actix.rs/docs/ for instance: there's nothing to the effect that you shouldn't use or rely on it, and everything to the effect that you should. (In case that page gets taken down, it starts, "Actix is your door to developing web services with Rust and this documentation is going to guide you.") On https://actix.rs/community/ it says you should report bugs to GitHub, implying that bug reports are in fact welcome, and there isn't a single statement that the project goals prioritize the author's technical excitement over correct code.

Again, there's nothing wrong with wanting to prefer your technical excitement over having bug-free code. Just be clear about it.

He held the door open for a lot of people. Some people spit at him as they walked through. He doesn't want to hold the door open any more, he's done it enough. He didn't sign up to be a doorman for life.

Right, and he can do that and that would be totally fine. People stop maintaining projects all the time. But by going out of his way to antagonize people (many of whom aren’t even the people who “spit” at him) he’s just not being very nice.

Just walk away then, no need to set the door on fire.

> Just walk away then, no need to set the door on fire.

That's what he is doing: simply walking away.

But he doesn't owe you anything, and that'exactly what you are getting.

It's astonishing how some people feel entitled to other people's life work. It's like you believe others owe you everything just because you like their work.

he's walking away, but before he does he decides to brick up the door he was holding. that's ok though because the house has lots of other doors that are based on the door he was holding open, all people have to do is to go through the effort to find the best version of the door that is most like the door he was holding open before that he's bricked up and thus is not available for comparison anymore.

I certainly think he had the right to do what he did, and the people who were rude deserved to have the door bricked up, but the people who read the notices he put up before hand about how he was holding open the door and it was a good way into the house might feel he is sort of a jerk.

> he's walking away, but before he does he decides to brick up the door he was holding.

If you're interested in the project you can still access the source code.

Hell, the author asked for volunteers to pick up where he left off.

Yet, you're only complaining that he is no longer working for you and complying with your personal whims.

That's the problem. A guy volunteers himself and donates his expertise and work to give you a gift, and in return some moochers just want to mooch off of him and, worse, attack him for not complying with their whims.

Literally no one is complaining here that they no longer want to work on the project. It's all about the deleted code, and the damage he did to the community by yanking the project from its primary hub (which also kills all gitter conversations, links, build pipelines e.t.c.)

>> the author even asked for volunteers

citation needed

well, I already apologized elsewhere as I had misunderstood his personal repo to mean a private repo, but anyway I don't code in Rust, so no, I'm obviously not complaining that he is no longer working for me.

This obviously means also that he has not given me a gift.

Finally I am not sure what reasoning has led you to assume that if he gave me a gift moochers would want to mooch off of him, and how they would do so by virtue of him giving me a gift. Whatever reasoning it was, I'm forced to think there must have been little of it.

This idea that replacing unsafe code with safe code is "spitting" is unhealthy in the extreme.

I don't understand why the author felt so defensive about accepting packages. As far as I can tell, they've always had this attitude.

Why even make a project open source if you don't want to consider patches? The whole idea is that even if you think a thing is boring, someone else may not and they'll do that work for the community.

Weirdly, this is now some kind of grave affront to the maintainer who appears to take the idea that a compiler check could be added to their general framework as an insult.

> Why even make a project open source if you don't want to consider patches? The whole idea is that even if you think a thing is boring, someone else may not and they'll do that work for the community.

This is a false dilemma - making a project open source can have plenty of motivations besides "I want to be a project manager for free!". Some other motivations:

* Someone may find this useful even if I don't ever touch it again.

* This could show others an example of a different way to solve a problem.

* This is cool, look what I did!

* Github is a free host, and there's no reason to keep this private.

* I just need some code I wrote in a public place for hiring managers to peruse.

> This is a false dilemma - making a project open source can have plenty of motivations besides "I want to be a project manager for free!". Some other motivations:

But isn't it also a false dilemma to suggest that the only lens by which you accept PRs is in the role of "project manager?"

> Other reasons offered

Sure but those are hypothetical. That's not what was going on here. The author of this diatribe was actively soliciting patches and maintaining the project publicly.

We certainly aren't coercing him to take a role he didn't want (at least initially).

I know why I might.

Here's an analogy for you. When you pour yourself a glass of pop, and you over-pour - do you then pour the drink back into the bottle?

I know some people that would return that drink to the bottle, and some that would rather pour that little bit into the sink. Those that would "backwash" believe that the bottle will be fine - sure, you've maybe transferred a little bacteria in, but it probably won't cause any problems. Those that throw it away believe that the hygiene of the bottle - even from a clean glass - would otherwise be compromised.

So if you come to my battle-tested codebase, and tell me "Hey, I've made you code better. It now has a theoretical metric of cleanness, instead of your proven metric of cleanness" - you may well have just introduced a bug. I now need to test your code, ensure it meets my real-world standards of cleanness. And maybe it does! Maybe your code has fixed a glacially-slow memory leak, but I won't see that. Maybe your code has introduced a complex interaction that none of my examples exploit, but other people's examples blow up because of it.

Maybe the bottle of pop will be fine. Maybe in a couple of days time, when I have guests over, the unhealthy layer of scum floating in my mother-in-law's glass will make me look bad.

Either way, it's a lot of work, and little certainty, and only theoretical benefit - vs no work, and full certainty in the real-world correctness of my code.

And it's a question of which do I value more - my big bottle of pop, or the dribble you'd rather give me back.

So uh, I gotta be honest with you: I can barely follow your post. It makes very little sense to me. But the parts I can figure out, I disagree strongly with.

> So if you come to my battle-tested codebase, and tell me "Hey, I've made you code better. It now has a theoretical metric of cleanness, instead of your proven metric of cleanness"

The flaw with this is that just running code in production for a modest amout of time proves nothing. That is in fact the opposite of proof, it's an anecdote. Safe code from a sound compiler can be literally proven to hold certain properties, with a margin of certainty that depends on then compiler.

Now of course, the proof guarantees of the specific code in question are weak compared to what you can do with something like Liquid Haskell or Idris or Coq, but they're definitely more than this pride-based programming you're holding up.

> Maybe your code has introduced a complex interaction that none of my examples exploit, but other people's examples blow up because of it.

And maybe your code already had that. That's why I trust compiler checks a hell of a lot more than people. And that's why I find this entire movement of pride-based programming that you and the subject of this thread so problematic. You're just holding up your haphazard experience as evidence. And honestly, not many people's experience would move me that way. Maybe if you're running it as Google or Facebook's frontend I'd find that reassuring, but short of that...? No.

Have you load tested your software? How did you simulate it? Have you validated your algorithm with a tool like TLA+? Have you watched your memory use carefully? Have you measured the latency variance? Under what kinds of loads? Is your data real or a projection using something like USL4J?

> Either way, it's a lot of work, and little certainty, and only theoretical benefit - vs no work, and full certainty in the real-world correctness of my code.

Pull requests on GitHub are generally the click of a button. If they're not good on grounds of completeness, then reject them on those grounds. Not, "Oh here we go again this code is so much more mechanically verified than mine, don't start this again."

> pride-based programming

I'm absolutely not talking about pride. That's a straw man - nowhere in my answer did I discuss a person's pride. I'm a big proponent of egoless programming (as far as any human being can) and while I have no idea whether ego came into this, pride is not the only reason a person might reject these kinds of patches.

That said, ego is a great reason for you to dismiss valid arguments, so I'm guessing you've made up your mind.

> The flaw with this is that just running code in production for a modest amount of time proves nothing. That is in fact the opposite of proof, it's an anecdote. [...] proven to hold certain properties [...]

You've just made exactly my point, but from the opposite side. You are saying that Safety, and those "proven properties" are of higher importance than being bug-free in the real world.

The issue is that it is impossible to prove that code is correct via tools. You can prove some properties, but you cannot prove fitness for purpose.

> Have you load tested your software? How did you simulate it? Have you validated your algorithm with a tool like TLA+? Have you watched your memory use carefully? Have you measured the latency variance? Under what kinds of loads? Is your data real or a projection using something like USL4J?

Generally speaking, I have no idea. In this scenario, I know the project owner has done some performance testing, so maybe. But honestly, I've no idea what you're trying to argue here.

> Pull requests on GitHub are generally the click of a button

This seems like a big flip from the previous statement. No, Pull requests on GitHub for a trusted and depended-on project are NOT a single click. If that is how you run your open source PR pipeline, very quickly your users will not trust you.

> You've just made exactly my point, but from the opposite side. You are saying that Safety, and those "proven properties" are of higher importance than being bug-free in the real world.

You don't know its bug free. You're saying you haven't seen obvious bugs. That may work for you, but I try to gamble as little as possible when it comes to code.

But even if we ignore safety, you're also skipping expressiveness and more self-evident code for what?

You're not qualifying your "real world experience" with any sort of alternative rigor that might represent some sort of nod to modern practice. Until you do, you're shouting "I believe in this because of my pride."

You can deny that characterization, but that's what it is.

> Generally speaking, I have no idea. In this scenario, I know the project owner has done some performance testing, so maybe. But honestly, I've no idea what you're trying to argue here.

As opposed to your "pop" metaphor, you think asking for some demonstration of rigor is confusing? Well... The world is full of different ideas I guess.

> No, Pull requests on GitHub for a trusted and depended-on project are NOT a single click. If that is how you run your open source PR pipeline, very quickly your users will not trust you.

You didn't read very carefully if this is your takeaway and I won't entertain a straw man. Perhaps next time spend less time on a labored "pop" metaphor?

This is cognitive dissonance at its finest! Clearly you want preciseness, so I'll go through these gems bit by bit:

> You don't know its bug free.

And I haven't said that I did. What I have said is that - unless you give some evidence to the contrary - I'd rather trust the code as it stands, to new code that hasn't had the same amount of airtime. So if there is a known bug, and your bug fix ALSO introduces some correctness, then brilliant! I applaud your girl/boy scouting. If you are rewriting someone else's code because you don't like it on a philosophical level - however much the community appreciates this philosophical viewpoint - the project owner is under no obligation to gamble on your new code, and is right to accuse you of hubris, self importance and a lack of any kind of empathy.

> You're saying you haven't seen obvious bugs.

No - I'm saying you haven't seen any proven bugs. I'm saying that care and attention has been made to eradicate the bugs that were in the first versions of the code. With every code change you make, every line of code has a 1-in-X chance of containing bug(s) (that X varies from language to language) so if you change a lot of lines, unless the code is _really very very_ broken, the more lines you add, the greater the likelihood that you're adding bugs.

> That may work for you, but I try to gamble as little as possible when it comes to code.

I think I've made the point above, but in case I haven't: Both choices are gambles. One is a gamble with the evidence to back it up, the other is a gamble on something that has next to no evidence at all. One is the pragmatically certain choice, the other is a lot of risk with no known reward (in this case).

> But even if we ignore safety, you're also skipping expressiveness and more self-evident code for what?

I can't answer that. That is a very very good question. But not asked as hypothetical question - ask it for real. What has the original developer gained? Why is that more valuable to them than enhanced memory safety? Why does the original developer believe this code to be safe enough? Until you ask this question and can answer with certain knowledge, you have not earned the right to rewrite his code.

> You're not qualifying your "real world experience" with any sort of alternative rigor that might represent some sort of nod to modern practice.

Oh, I'm sure the original code had no behaviour-driven tests, single-character method names, that the original author reimplemented GOTO just to get the thing to work.

> Until you do, you're shouting "I believe in this because of my pride."

> You can deny that characterization, but that's what it is.

I'm happy to assume that pride did come in to it. The original author is proud of their work, the new author is proud of theirs. Great. But making a work that only exists to trample on someone else's decisions is crappy behaviour, unless you can prove that your change actually fixes a real problem.

And I do deny the characterization, but only in the sense that you have some kind of weird fixation on this as the only conclusion. I've been making an argument for pragmatism - the pragmatic choice is to ignore the rampantly self-assured meddler.

> As opposed to your "pop" metaphor, you think asking for some demonstration of rigor is confusing? Well... The world is full of different ideas I guess.

You can ask for a demonstration of rigor, but as I pointed out previously, I'm not in any position to give it. I don't know what he did or didn't do to the code. My question is, why does that actually change the gambles above? Are you saying that the author of the pull review DID do all this? Are you saying that the project owner, working in his spare time for free on a project used by thousands who are probably making money from it, should be required to implement this level of testing? Your statement was presented without any context, which is why I was confused.

But here's the rub: Absolutely none of the strategies you mentioned can guarantee correctness in the real world! None of them. Sure, they can help. Maybe they'll make that 1-in-X bugs-per-LOC turn into 1-in-2X, or 1-in-20X. But they won't fix a fundamental misunderstanding on the way a method should work. They won't tell you that some client code is now broken because you introduced an assumption that wasn't in the original code.

What they will do is reduce the amount of time that the original author has to spend with their family, because they now need to test your code change for all the bugs and bad assumptions that the original author probably made the first time they wrote the code, and a few more beside. Maybe they do now have to rewrite their TLA+ constraints, rerun their benchmarks, etc.

The original author might be willing to use his spare time to make his codebase work better. He does not have to spend that time massaging your pride because you rewrote his code because you knew better.

>>> Pull requests on GitHub are generally the click of a button

>> No, Pull requests on GitHub for a trusted and depended-on project are NOT a single click

> You didn't read very carefully if this is your takeaway and I won't entertain a straw man. Perhaps next time spend less time on a labored "pop" metaphor?

I'm not seeing how this is a straw man. You were minimising the effort that goes into PRing... I pointed out that lack of effort in PR process is bad... you shout straw man and try to insult me?

Hey - I'm just trying to give you another perspective here. If you're not a fan of analogies, that's a shame, sorry you feel that way, some people find them useful. You started this by saying:

> I don't understand why the author felt so defensive about accepting packages.

The guy basically flat-out said that the problem was with entitled idiots who think they know best rewriting vast swathes of code without understanding the original decisions.

Since you didn't understand that, I gave you an allegory. If that doesn't help, and this doesn't help, well, don't know where we can go from here.

> Since you didn't understand that, I gave you an allegory. If that doesn't help, and this doesn't help, well, don't know where we can go from here.

It was a metaphor, not allegory. And literally no one understood it. I only saw your comment because I was briefly reminded of this discourse after some other community sites found your attempt at metaphor and mocked it in front of a wide audience.

Not the outcome I was hoping for, but I hope that the exposure helps you get your message of "I do what I want and don't have to prove anything to anyone" when writing code. I look forward to seeing how that helps your professional reputation.

Well put. I’d add on to your metaphor: slamming the door on someone is quite different than just not holding it open anymore. The second is totally acceptable; the first is impolite.

This case is clearly akin to not holding the door open anymore.

The code’s all there and still available, right? Anyone who wants to can reach out and “hold the door open” for themselves, can’t they?

> if I see you approaching a door, I am under no obligation to open it just because I'm physically able to, but if I open a door for you, I'd better hold it until you're finished walking through, or I'm a jerk. By holding the door open, I've made an implicit promise that I'm not going to close it on you.

This reminds me of an incident years ago. I was on a city bus, very full of people, and we were just about to leave a stop. There's a woman maybe 150 feet away running towards the bus. The driver sees her running and re-opens the door, waiting. Inconvenience to all of us on the bus, but hey, she's running.

The woman, seeing the bus has waited for her, stops running and starts slowly walking instead.

Driver sighs, closes the door, drives away.

I'm not sure what the moral lesson I take from it is, but mainly "if I go out of my way to help you, don't take advantage of my generosity". Maybe that partially applies to situations like this one. Or maybe just "don't annoy transit operators". That's a good one too.

In this case, the maintainer made an active and conscious decision to do something that did nothing but hurt everyone using the project. There are no passengers who might benefit here, sadly.

Since this seems to be a constant point in this thread but I don't see it: How exactly did that person hurt anybody? They maintained this project for 3(?) years and the code is readily available elsewhere on github now. If there's really that many people being inconvenienced by that, surely somebody else will take over that fork instead.

This person killed the momentum that this project had, much of which was only partly their work. Forks fracture a project’s community and pit the pieces against each other: occasionally they work out, but often they all just fizzle into nothingness. Keeping a project together has value. (Also, note that associated GitHub metadata such as issues has been wiped.)

Reading the description in the root of that project, the community and user base might just as well be attributed to "killing the momentum" if you like (if that's even the case, this seemed to have happened literally hours ago). The issues seem to be intact on the maintainers personal copy of that repository.

I mean, yes, keeping a project together has value, I just don't see where the assumption here comes from that this maintainer has to do that indefinitely or even has to be involved in actively searching for successors in a community they don't feel good about. The maintainer even states being open to suggestions. If nobody steps up, momentum can't have been that great, if somebody does, a fork will live on. That's still in the realm of mild inconvenience, other projects have survived much larger controversy.

edit: the frontpage is currently topped by a more balanced write-up by Steve Klabnik that weighs up, among others, both of these views https://news.ycombinator.com/item?id=22075076

> I just don't see where the assumption here comes from that this maintainer has to do that indefinitely or even has to be involved in actively searching for successors in a community they don't feel good about

Of course they don’t. But I don’t see why they couldn’t have made an issue along the lines of “I’m stepping down, I’d like someone else to take over the project”. (Still reading through the other writeup.)

What do you mean wiped? It was moved to personal account https://github.com/fafhrd91/actix-web.

I was under the impression that that repository was probably going to be deleted at some point.

I think you are confused. The maintainer made an active and conscious decision to protect himself. That's clearly not "nothing", and a perfectly legitimate reason.

They're referring to the maintainer's conscious decision to reject a patch made in good faith, that fixed the issues that had been pointed out. It was rejected with the statement "this is boring." Do you think this behaviour is justifiable?

> I think you are confused

You sure?

It is if your the one maintaining it. It's not like people are paying the person to accept their patches. If they want their patch applied they can fork the project. The maintainer isn't a slave to others.

Under what obligation does the maintainer NEED to accept any patch? It's his project he built. He can build or destroy his work as he sees fit. If you have an issue fork it. This is how things like libreoffice, mariadb, and countless other projects have come to exist.

> They're referring to the maintainer's conscious decision to reject a patch made in good faith, that fixed the issues that had been pointed out.

You're misrepresenting the problem. There was never a bug or an issue, only a bunch of opinionated and vocal users who thought that bullying a maintainer is an acceptable way to get him to accept their patches. The maintainer rejected the bullies' actions and in turn the bullies ramped up their attacks, which ultimately convinced the maintainer that closing up shop is the best way to stop having to deal with these bullies.

> You're misrepresenting the problem. There was never a bug or an issue

The story originated from the author of this article [0] posting a bug report issue [1].

Why are you accusing others of misrepresenting the problem while doing so yourself?

0: https://medium.com/@shnatsel/smoke-testing-rust-http-clients...

1: https://archive.is/BEqfM

Please stick with the facts and thus with primary sources. Part of the blame of this shitstorm lies in those who insist in misrepresenting the problem with bullshit blog posts and "he said she said" nonsense.

https://www.reddit.com/r/rust/comments/epszt7/actixnet_unsou...

Unfortunately this is not the first time Rust soundness/unsafe zealots are aggressive and create shitstorms in the community.

I linked to an archive of the GitHub issue in question and the reporter's own blog article about it. Are those not primary sources? And you've linked to Reddit?

I think there are a number of ways the maintainer could have protected themselves without making it actively worse for the community. I would even predict that this decision makes them likely to get even more abuse, though of course I would never condone that.

> I think there are a number of ways the maintainer could have protected themselves without making it actively worse for the community.

If said community was the one causing the problem, what would be the point of that?

The community is not a monolithic entity.

If there are bad apples in the community then the good apples need to speak up and reject them.

Otherwise the bad apples are the apples.

I think that's fair - especially the part about not taking advantage of generosity. But I don't think that's what happened here. Someone reported a soundness bug. Someone else (IIRC) posted a patch fixing it by switching from a custom Cell type to the standard library one, which is what the maintainer called uncreative and boring. Fixing a soundness bug is a perfectly reasonable, non-advantage-taking thing to do in a PR.

(I agree that in general there is a problem with open-source users feeling entitled to support/features and maintainers not feeling comfortable saying no, but that doesn't seem to be the type of incident that triggered this, and more generally it is difficult for me to see how a patch would count as that - at least a patch that isn't "please maintain this pile of new code," which this one wasn't.)

> Someone reported a soundness bug.

Your description starts off on the wrong foot because a) there was no bug, and b) although the library used unsafe code extensively, its maintainer argued that was not a problem and that didn't meant the code was unsafe.

So in the end we only have issues being reported by opinionated users trying to force their personal opinions on a project maintainer, who due to the content and tone of said issue reporters decided not to accept the reports or patches. Once some bad apples in the community started to increase the unpleasantness of the whole experience, the maintainer said enough is enough.

Well put!

Yeah, people who aren't in perfect running form don't deserve help.

If some one opens the door for you that was nice of them, they did your work for you, they have no ongoing obligation to maintain the door in an open state.

If some one give you their code that was nice of them, they wrote your code for you, they have no ongoing obligation to maintain your code.

by simply giving you their code they have already provided you with value, a head start for nothing in return, they have opened the door for you, the rest is up to you.

We’re starting to stretch the metaphor too far, but by opening the door you’ve signaled to me that I can walk through it safely. Closing it abruptly can in some cases be even worse than the alternative, since I could have possibly opened the door myself (written it myself and not invested time in this particular project) or gone through a another door that was also being held open (used another open source project).

> by opening the door you’ve signaled to me that I can walk through it safely.

It was safe for me, is it safe for them? Thats not a judgment I can make on their behalf. A lot of people are complaining that the code is unsafe while the author thought it was safe enough for them. How many nines is safe, depends on the person.

You should consider these things before using some ones help, not after, looking at the comments here no one did that.

> It's not very hard to say, this is a project for my own technical interest, I don't intend to follow Rust norms about use of unsafe, and you shouldn't rely on it.

So this guy is happy to rely on code he hasn't even looked at and then gets upset when that code is unreliable. This is not a reasonable expectation.

He try's to make out like this was a professional product that you would expect professional support for, but this is just some code he found on github and couldn't even be bothered to look at.

If you took the code when it was available then you walked through the door when it was open, now the door is closed its your responsibility.

> A lot of people are complaining that the code is unsafe while the author thought it was safe enough for them. How many nines is safe, depends on the person.

There's a very precise definition of this, it's not a matter of opinion. The code exposed a public API that was not marked "unsafe" that allowed you to construct (definitely intentionally, perhaps unintentionally) two mutable references to the same object.

> So this guy is happy to rely on code he hasn't even looked at and then gets upset when that code is unreliable. This is not a reasonable expectation.

This is a hostile misinterpretation of what actually happened. The bug reporter actually looked at the code, determined it was unsafe, and reported a bug. That's what everyone wants an OSS user to do.

> The bug reporter actually looked at the code, determined it was unsafe, and reported a bug. That's what everyone wants an OSS user to do.

No again this is end user entitlement, you are not an end user you are a developer, if you discover a bug you are supposed to provide a patch to fix it not expect some one else to fix it for you.

If you depend on some one else's code it is your job to do due diligence on that dependency, no one did and it came back to bite them. People need to stop blaming every one else and learn from their own mistakes.

Which is what the end user did! The maintainer rejected the patch as "boring" despite being given concrete example of how UB could be triggered and how the patch would fix it.

The Actix website encourages end users to report bugs: "If you think you found a bug it's best to go to the github directly."

If you're claiming that taking those directions seriously is entitlement and that it's less entitled to second-guess the maintainer and do what you think they meant even if it's the opposite of what they said....

Another user provided a patch, the patch got called "boring" by the maintainer, a passerby snapped with offensive personal attacks and the rest is history.

agreed that it is being stretched. perhaps a better metaphor would be not just opening the door, but building it.

You walked through the door safely. Then you come back day after day and say "Where is my doorman! He opened the door once, that is an implied social contract to open the door every day!"

If someone is relying on your code, that means they have their own copy of it.

You're not obligated to keep your copy online.

As an open-source developer myself, I'm annoyed when people do that. I want them to rely on my product, not my code. I want them to update when I publish new versions and I want them to send patches back.

There are even almost-open-source licenses that compel you to send patches back. I don't want to use one. I want to treat them with respect and I hope they treat me with respect in turn.

I don't know what planet you live on, but people need a local mirror of your stuff for reasons such as, oh, so that their continuous integration builds don't stop when your server is not reachable.

Most users are not going to use your today's daily build, nor should they. Only people who are more than casually involved with your project can be expected to contribute changes which are rebased to the current.

If things are working for some users, and there is no security advisory that affects them, they have no reason to update to every new version.

Anyway, between you and the users, there may be middlemen: the distro package maintainers. Those people will lag in picking up your changes, and may push back on bad ones that break things for them.

People should mostly get stable things from their distros, not straight from the horse's mouth.

For instance, if I'm building something on Ubuntu 18, I will use the make, bison, shell and whatever else that is packaged on Ubuntu 18; I'm not going to pull these things from the tips of their repos and rebuild their latest versions.

> It's absolutely correct that people don't have obligations simply by putting some code online. But they do have obligations when they start telling people to use their code. We understand this as humans even in realms far from open source: if I see you approaching a door, I am under no obligation to open it just because I'm physically able to, but if I open a door for you, I'd better hold it until you're finished walking through, or I'm a jerk. By holding the door open, I've made an implicit promise that I'm not going to close it on you.

Exactly.

Like it or not, there are implicit social contracts if you maintain OSS software.

Yes I've read the birdseed of the various licenses.

I know this will whip up the oft-suffering maintainers and developers in here. But this is the exact kind of trope that stymies wider FOSS adoption.

The artifacts of these little meltdowns are exactly the kinds of things your upper management will cite the next time you suggest using FOSS vs. whatever vendor they're about to push down your throat.

Ignoring security conventions, and then adopting a "take my ball and go home attitude" isn't a ringing endorsement for adopting FOSS, unless it's run by a large entity.

I'm not saying the author should have to endure abuse or harassment, but consistently pushing unsafe code into a web-framework, being cavalier about trivial and widely accepted coding conventions, and dismissing patches as "boring" is exactly how you end up with NPM Ecosystem v2

> Ignoring security conventions, and then adopting a "take my ball and go home attitude"

That statement is quite wrong. It's not a "take my ball and go home" attitude. You are not the boss of a FLOSS maintainer not are entitled to order anyone around to do your bidding. At best you're addressing a person and asking them to do you a favour. If the maintainer doesn't feel he should be bossed around by you then he has been generous enough to let you pick up where he left off and actually put in the legwork you are expecting others to do.

And in return these haters prefer to just bitch around and criticise others for not following their orders.

This is a weirdly hostile and unreasonable take. The maintainer was rejecting patches and ignoring bugs after advertising that patches were accepted and bug reports were desired. That at the very least makes the maintainer a liar. Additionally, the framework was advertised for general use that it was not suitable for given the soundness issues. Since when did lying to people, wasting their time, and being obstructive about their good-faith attempts to improve the project in the way the maintainer had already requested become admirable?

> Like it or not, there are implicit social contracts if you maintain OSS software.

I think I agree, and its tricky because its really hard to pinpoint what the contract is (without sounding "entitled"), like there is with any social contract I guess. Maybe it even depends on the various cultures of the people working on the project.

that contract is precisely spelled in the license file, idk what you all are on about.

This is kind of like saying "its technically not illegal!", in the same way it's not illegal to open the door for someone and then shut it as they are about to walk through. We are talking about social contracts that are not written but are collectively understood to some degree.

The social contract is generally not written down anywhere. Here's what we're all on about: https://en.wikipedia.org/wiki/Social_contract

I consent to let other people make demands of my OSS because I wish to make demands of their OSS because together we can build a better world than either of us could on our own - because I am consenting to be part of a community. I have security-sensitive Rust code on GitHub. I'm careful about unsafe, and I welcome people filing bugs, because I want the entire ecosystem to be good about unsafe, and so I need to do my part in that.

good thing the license file cover implicit guarantees then, because this is just bullies making up bullshit for justify their pressuring people into complying with their wishes.

The social contract is not enforced in the courts.

> Th e artifacts of these little meltdowns are exactly the kinds of things your upper management will cite the next time you suggest using FOSS vs. whatever vendor they're about to push down your throat.

Yes, this is what I don't understand - we spent decades fighting the perception that open source could never be as good as proprietary commercial software. Now that we've mostly convinced our bosses, we want to turn around and say, no actually an open source maintainer who writes buggy code, rejects patches, and takes down their project when called on it is doing exactly what he should do?

Of course he has every right to do that, but this shouldn't be (and fortunately isn't) the norm. Defending this outcome as the expected outcome just means that the bosses will quite justifiably say, suppose we use this software and I let you publish patches back, you're telling me to expect that the upstream author will take their code offline? Why should I use this software at all, let alone let you waste your time on patches? I'm gonna buy from Oracle.

> Why should I use this software at all, let alone let you waste your time on patches? I'm gonna buy from Oracle.

With OSS you always have an option to keep your personal copy of the source tree, and you have an option to fork it and maintain it at your own expense. When Oracle closes and discontinues the software you rely upon, you are screwed big time.

Big companies often have code escrow agreements to cover that exact problem.

The advantage of them is pretty theoretical since you don't really want to become responsible for someone else's code drop, but that's not any different with open source.

>you're telling me to expect that the upstream author will take their code offline

Yes. If a company shuts down, who is to blame when the downloads are no longer available?

No offense, but your build process is lacking if you are affected by a project disappearing from the internet.. You should be bundling all of your libraries with your final artifact.

This is a prime example of relying on the cloud without a continuity plan.

This has nothing to do with build process, this has everything to do with the expectation that a project will continue to exist and put out new releases. All out builds at work, in fact, are offline. We check in tarballs and we don't access the internet. That has nothing to do with whether I can tell my boss in good faith, allow me to submit a patch upstream and it'll be worthwhile to the company and we won't have to carry local patches. Right now I can say that. Why would we want to get rid of that?

Whatever drawbacks Actix may have had, this entitlement has gone too far. There is no defensible reason to tell someone "never write Rust again" because you don't like the code they're making available to you. We need something to remind us that we should be civil and grateful for FOSS contributions.

I recently saw a talk by Atwood about good discourse and how you should remind people of your values before they write their comment, which I think applies here. I'm going to make a single-page website reminding people that FOSS maintainers are volunteers performing a service to everyone else, and that we should keep that in mind.

If nothing else, it'll be an easy think to link people to in my issues sometimes.

EDIT: It's going to go up on https://www.osscoc.com/

"We need something to remind us that we should be civil and grateful for FOSS contributions."

You mean like having the legitimate risk that maintainers will take their ball and go home when people are cruel and others stand around and let it happen?

This is everyone's fault who didn't dogpile the people who were being terrible. We all need to be calling out people being horrible, and provide a little emotional support to maintainers. We worry too much about the feelings of people who contribute nothing, and not enough about the people who build the things upon which we rely.

No, I mean something less remote and which looks less like a random act of God, something that people can read before engaging in discussion and not easily dismiss because "it probably won't happen". We need to raise the level of discourse across the board, not just prevent the most egregious of negativity.

I want people to enter the discussion with the mindset "this is a volunteer effort so I will aim to be productive in my disagreement", rather than "fuck this guy".

Ahh, yes. That would be fantastic.

> "This is everyone's fault who didn't dogpile the people who were being terrible."

That presumes that "dogpiling" would actually stop the behavior, rather than getting people to dig in their heels and further inflame tempers.

Even so, it can serve two purposes: the author feels defended and acknowledged and the author feels relieved as the heat is, at least temporarily, directed at someone else. And this is the worst case scenario.

The author feels defended, but the subject of the dogpiling feels attacked. Maybe that leads to deescalation, but that's far from a foregone conclusion. Bullying bullies often further normalizes the act of bullying in the eyes of the bullied bully, as well as potentially normalizing bullying in the eyes of observers.

There are better ways to handle situations like this.

> how you should remind people of your values before they write their comment

That sort of thing doesn't work, even if it's shoved in people's faces. The only viable solution I've ever seen for enforcing community standards is to suspend or ban people who violate them. Otherwise, you'll always have trolls and people who want to see you fail looking to poison the well.

>I recently saw a talk by Atwood ...

Interesting, if you could share a link or some other source me and my dinner would appreciate it :)

I'm rather sure it was this one:

https://www.heavybit.com/library/video/civilized-discourse-b...

Thank you!

> We need something to remind us that we should be civil and grateful for FOSS contributions.

Sort of ironic that the entire commotion started when the Actix maintainer dismissed a contributor's code as boring after they wrote a POC and a patch for a use-after-free bug.

Open source maintainers have a hard time - especially when they're under criticism and receive zero positive vibes. Author mentions it, here's the excerpt:

Be a maintainer of large open source project is not a fun task. You alway face with rude and hate, everyone knows better how to build software, nobody wants to do home work and read docs and think a bit and very few provide any help.

This a big problem with open source - I, as a programmer, like when someone commends me. It might be childish, but if I invest a few days into code and someone finds it useful - I would love to hear it, it would make the day for me. Instead, I had similar experience like the author of actix - hatred, rudeness and a lot of people who don't read the docs, they merely expect everything to work if they drop the library into their project.

Sadly, we're way too negative and don't appreciate OSS maintainers. This trend should change. It's sad to see yet another project go because author was mentally drained due to negativity. We should take care of our own "brothers in arms" (we all write code or deal with tech, don't we?).

I haven't used Actix-web, but I can sympathize with the author. Keep your head up, recharge your batteries and remain creative. Good luck with your future products!

A data point: I've been involved in Open Source for 10+ years, developing projects myself, helping to maintain very popular projects, contributing, and I don't see a trend like this. I've interacted with hundreds of people over the years, and the vibes are overwhelmingly positive; I haven't noticed any hatred or rudeness towards myself. I can't think of a single time interaction with OSS people afected me negatively, but there were a lot of positive (or neutral) interactions.

Over time projects I'm contributing to were changing, and so I was exposed to several different communities (Python web development, data science, web scraping), and all of them turn out to be awesome. Maybe that's just luck, but not all OSS maintainers have it hard - no idea why :)

+1 to recharge the batteries!

Evan Czaplicki (Elm designer) has a great talk about this issue "The Hard Parts of Open Source" https://www.youtube.com/watch?v=o_4EX4dPppA

I don’t want to come across as toxic myself, but I think that the toxicity that Evan sometimes has to endure from people in the community is somewhat self-inflicted.

Last year I wrote a web application in Elm. Even though I really liked the language and had lots of fun writing code, I noticed that the users effectively have to rely on Evan to make any meaningful progress. The ‘forkability’ of the project is very poor.

To give you a couple examples of that:

- Elm has a centralized package repository: https://package.elm-lang.org/. There is, however, no functionality in Elm to host your own registry, whether it is public or internal to your organisation. The monolithic compiler/build tool hardcodes the URL of this registry.

- Relatedly, there is no way you can easily fork a package and apply some changes, especially if you have no intent to host it through the official package collection. There is no way to say: “I want to use elm/http with this tiny local patch applied that I have sitting in my tree.”

- Some parts of Elm’s grammar/intrinsics are only permitted to be used by packages with author “elm” (i.e., the official core packages). This means that you cannot fork, say, elm/bytes to yourname/bytes and make local changes, as it can no longer be built.

Because of this, the maintainers of Elm don’t just decide what goes into the tree, they effectively also decide what users may do on their end. They are the folks sitting behind the master control panel and people filing issues/pull requests rely on them to push the buttons for them. I can understand why this causes friction within the community.

Note that this was my experience using Elm early 2019 (January-April). It may well be that Elm improved in these areas since.

Similar experience. Some OSS users have some very entitled mentality.

Yep this is why, more and more, developers are simply doing private repositories. They might exist on GitHub. Or a torrent or something. Rachel goes into more detail about them here.

Basically people fix things and don't commit them back upstream because doing so is too much of a political headache.

> While it's probably true that the dictator does suck at design, the talented user wants no part of the drama which would follow such a report. There is absolutely no benefit to lighting that particular fuse. And so, the problem is never reported, and the patch is never conveyed upstream. It effectively becomes a private fork limited to the talented user's systems.

https://rachelbythebay.com/w/2018/10/09/moat/

I've been thinking for a long time that one of the problems with these online shitstorms is that the adults in the room are silent. It would have been so much better if the senior people in the Rust community stepped in to actually say "Hey, we're all using it, yes it's got issues, but thanks for your contribution and don't worry about the idiots". Instead we've got senior people in the Rust community waiting until the damage is done and then hand-wringing about it afterwards.

It's a tricky balance. This is also sort of where I was getting at in my post with the "unofficial" bit; because /r/rust is not official, we do not look into it. And because this happened on Reddit, there was no real opportunity to actually step in. It's quite possible this is simply a failure on our part.

Today is the first time that I've heard that /r/rust is apparently regarded that little from the Rust team. To me it's the most important online gateway to the Rust community, and also the best resource to stay up to date with the ecosystem.

I knew that it was an "unofficial" channel, but given that it's most likely the single biggest aggregation of people in the Rust community, I always assumed that the Rust team would consider it of close to equal importance to users.rust-lang.org.

> And because this happened on Reddit, there was no real opportunity to actually step in. It's quite possible this is simply a failure on our part.

I don't think that much could've been done to prevent that. It also happened on such a quick timescale that one could've completely slept through the whole situation (from the initial Reddit comment to the post-mortem).

Unofficial subreddits are hard to reason about. Within the context of reddit, they are still the most official place to talk about a thing they like. And even worse, those are the people likely to only interact with the "community" on reddit, forming an echochamber where they think the unofficial subreddit's opinion is some sort of majority.

In rust's case, it probably is worth diverting some of the existing manpower for moderating online discussion to reddit. I think that the harsher this moderation is, the less attractive the subreddit will be to the reddit-only echochamber, as an added bonus. But this is only possible because you already have people involved with online discussion on other sites. In most cases, if reddit or twitter keeps talking about you and keeps saying dumb stuff, you just have to ignore it. This is how r/competitiveoverwatch is treated; everyone knows that the stuff they say there doesn't matter, and that they don't represent more than a tiny fraction of the people watching the OWL matches. Even some of the people posting there know it. The players and casters still seem to read it, but for the most part just laugh about how dumb their opinions are.

In this case, I don't know why the maintainer took some redditor's comment so seriously, when they said that they should not write rust anymore. This is just a separate issue that anyone with "fame" has to deal with, ignoring critics who are idiots, nothing to do with reddit really.

I use to do a TON of open source back in the day. i quit cause of the same reason, people suck and feel they are entitled.

i couldn't count how many times someone would yell, kick and scream about an issue they were having and demand that i fix it right away (ain't gonna happen dude). i finally got to the point where i told people that i would only participate in pull requests and nothing else. you could still file issues, but i wasn't gonna even look at them. if you wanted something fixed, open a pull request and i will help you fix it but i'm not wasting my time with an issue that i didn't personally have an investment in. was i being a jerk for doing that? maybe, but my own personal serenity was worth more to me than pleasing you.

i think every open source author starts out with this fire in their heart to make the software world a better place for everyone only to get beaten down by every moron out there. when you are getting paid to do something, you put up with the idiots in your life (how many of us are still at the job that pays well, but HATE the people there?), but when you are doing it on your own time and not being compensated for it, what's the point?

i applaud this dude for doing what he did. i hope his actions has put the people using his project in a position of panic to the point where they reflect on how they treat people and participate in the open source community. pain is the only way we learn and change things about ourselves. i hope the people who caused the author to quit open source change the way they treat people in the future.

Maybe it's because I work on more niche projects, but every time someone contacted me about an issue in one of my repos they were always exceedingly apologetic about "bothering me". My projects only have ~400 downloads per month, so I'm sure it's a matter of sample size. If anything, working through issues with the community has made me enjoy the work more.

Yeah, it's important to remember that most of the time people are very nice.

Of course there are "problem kids" out there who screamd about an opinion they disagree with or tries flirt with female contributors on IRC..

Having co-workers, a code of conduct, and a community organizer you can escalate to can help a lot.

We are all on notice. Be nice. Support and protect the people contributing to the world... or write it yourself.

For context, this comes after yet another unsoundness bug has been found in Actix-web. Normally people in the Rust community don't get very worked up over these because we know that everyone makes mistakes, but the Actix project has had a consistent history of introducing unsoundness through the use of unsafe for dubious reasons like nebulous performance increases or bypassing Rust's safety guarantees (which is what this last one was about). Furthermore, when someone raised this issue and provided a patch to fix it the actix-web maintainer called the patch "boring"[1]. He also censored comments that talked about the unsoundness and eventually deleted the entire issue. This sort of behavior should not be acceptable from any open source maintainer that runs such a large, foundational part of the ecosystem.

[1] https://web.archive.org/web/20200116203731/https://github.co...

I completely disagree with your last sentence. Think of actix-web as a gift to the world (and judging by its popularity, a very nice gift). Being verbally abused by vocal majority of freeloaders would drive anyone furious.

I think I understand your perspective, though. It would benefit the community to have projects of great importance properly maintained. How to ensure it? Well, by paying people to do it, not necessary developers but active project mantainers. Only then you are entitled to complain about somebody doing a lousy job. To sponsor it, introduce micro-transactions for dependencies.

Obviously being vocally abused is not OK no matter what the victim has done. This is a big problem and I think Steve's article that is currently on the top page of HN gives a good overview of that part of the situation.

My problem with viewing all open source as a gift to the world, take it or leave it, is that when people create open source packages, market them as being ready for production use and as the best option for said production use, and then act unprofessionally towards security issues and reject patches that fix the security issues for no reason other than being "boring" and "not creative enough" people should be able to call them out on it as unacceptable behavior for an open source maintainer. If actix didn't claim to be production ready and instead stated that it was an experimental code base designed to advance the state of the art in web server performance I wouldn't have a problem with how it was managed. However, once you claim that something is production ready I think you need to be ready to take responsibility for it.

I strongly disagree, with extreme passion.

They could have marketed it as the greatest gift to humanity for all I care. It's your responsibility to handle your use of code. Sure, you may find issue's in your dependencies, and you're welcome to submit a bug or provide a fix, but if you expect anything more than the code as it is, it's still your problem how to deal with it.

The entitlement is astounding. A person providing free code doesn't owe you anything or "need to take responsibility" or whatever else you may want.

While that's true, expecting bad maintainership to not have any effect and third parties not discussing about the quality of the software is also delusion. (And in practice, maintainers maintain, and I'm glad they do, because otherwise e.g. Linux distro would be complete absolute crap.)

What is also a in the realm of possibilities is that a project gets a bad reputation and for indirect effects or others, dies. That happened here. However, in the effects we saw here, while the people proposing patches and debating in a civil way about technical flaws (or at the very least widely perceived as such) were fine, the brigading was absolutely inexcusable, as well as the unproductive/nasty comments.

And we yet to see any actual real-life problems with these "unsoundness" problems. Most of these issues raised in Actix were about theoretical problems.

>Actix project has had a consistent history of introducing unsoundness through the use of unsafe for dubious reasons like nebulous performance increases or bypassing Rust's safety guarantees

sounds like the author had specific strategic vision - "push the boundaries" - which he clearly explained, and there are other people who don't agree with such an approach, both are valid positions in their own right, and instead of being jerks and trying to shove their approach down the project owner's throat these other people should have just started their own project reflecting their more conservative approach.

It is like those people who try to push Linus to use C++ and do other funny stuff in the kernel - one should go and read Linus' responses to the people like these.

http://harmful.cat-v.org/software/c++/linus

"Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C.

[...] I've come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really would prefer to piss off, so that he doesn't come and screw up any project I'm involved with."

> This sort of behavior should not be acceptable from any open source maintainer that runs such a large, foundational part of the ecosystem.

And the better solution wouldn't be to harass the guy, but to recommend and try to move the ecosystem away from actix.

You say, "This sort of behavior should not be acceptable from any open source maintainer that runs such a large, foundational part of the ecosystem."

Or what? What's the "punishment" here? Who's going to decide what's acceptable, and what's not?

Seems like you are demanding that the author of Actix do what you want.

Sometimes people take their football and go home. In this case the vocal complaining minority are free to make their own copy of the football, and proceed on their own...which is also known as "put up or shut up".

Or he will lose the reputation, that's what.

> but the Actix project has had a consistent history of introducing unsoundness through

Then you can stop using Actix and create a better project or fork it and fix these unsoundness bugs and call it ActixSound. I do not see the point to rally up the crowd and raid his Github in the name of soundness. This reflects poorly on the Rust community.

I’m not sure why people are so fork-shy. Forking is the greatest gift of open source. It’s basically the point and the core of what it means to have software freedom. I think the anxiety around forking is unwarranted, especially in scenarios where the author clearly has divergent goals and values from a large number of people.

It seems the forest has been lost from the trees: exercise your freedom, fork, and let diversity lead to longevity. I think a lot of the aversion is because forking and fragmentation is messy. It doesn’t surprise me that the Rust community in particular would abhor such disorder :) (see the JS community for a counter example.) But such disorder is a key element of so many good human systems, like democracy and free markets. Better to embrace them and relish the freedom they bring, than dive deep into conflict with others only due to imagined chains binding you together, chains deliberately lacking due to the selfless altruism of the project creators who bound their work to a free software license, to whom you should be thankful, not resentful.

This whole issue is confusing to me. It's like no one ever heard of fork. It's hardly mentioned in the comments. The author owes people what they paid him to do, which is nothing. If he wants to go unsafe and fast that's his business. I don't have to ride with him. I can make a copy of his car for free and drive it the way I want.

I think this is a case of the end justifies the means. The end: get the maintainer to change his code the way I want. The means: bully and abuse him to force him into it because that sometimes works.

At some point open source got morphed into being about free as in beer and gratis volunteer work by generous souls. But its origin and what the licenses themselves are about are freedom to read and freedom to modify. The entitlement that has crept in and the social contracts that seem to have formed around expectations for people writing Free code are concerning.

Shame on people who forget this, and demand more than those freedoms from authors who so generously grant them to others. Based upon what I’ve read, I would have checked out from this project as the author well before they did given the harassment they’ve apparently been getting for not merging PRs into their repo.

I'll save this link for the next time someone tries to argue that the Rust community is somehow "more welcoming" than some other X community.

All internet-based communities contain some assholes. All of them. Sadly some maintainers don't seem to have the werewithal to tell them to go away. I mean, when you get "asked to change coding style", it's the time to put the banhammer down, because there is no way to please these people without humiliating yourself.

> I'll save this link for the next time someone tries to argue that the Rust community is somehow "more welcoming" than some other X community.

It's deeply disappointing to see this outcome (and r/rust is literally divided into two halves on this drama at least for now, ugh), but I believe it is the statement about the average atmosphere. Not that I have an argument for or against the refined statement, but it doesn't automatically get rejected with a single counterexample.

Nah, it's just the usual delusion of small-but-growing communities. The Python community was great in 2001, a bit less so these days. The Lisp community was probably great at some point in the '70s too. It's just that, with size, the likelihood of attracting undesirable elements inevitably grows until their presence simply cannot be denied. At that point, you either deploy heavy-handed moderation and get branded "unwelcoming" by the assholes, or leave it free for all and get branded "unwelcoming" by the most sensitive not-assholes. Then someone or something will spawn a new community, and the cycle will repeat itself.

This process is basically inevitable, and it has been observed in internet communities for so long that it's basically a science by now. It's just the nature of the (human) beast.

Of course I don't disagree to you, I too think that that reputation is extremely hard to retain. However:

1. It seems that there are/were some language communities noted for their relatively more welcoming atmosphere. If small communities are usually great until it aren't, why don't we see many such communities? There seems to be some truth in this (albeit ultimately fragile) reputation.

2. For this reason, in order to claim that some community is no longer what it used to be, you need multiple anecdotes at the very least.

Re 1, if they're small communities, you don't hear much about them in the first place. And if it's a language community, then the language is probably pitched long before the quality of the community comes into question.

That is, I've never heard anything about the communities for zig, D, beef, futhark, pony, Julia, etc.

But then, I don't think ever seen any comment on their community... Their supporters are too busy trying to justify the language's existence!

Well let me the first to mention Julia’s community. Especially on the julialang slack channel, the community is excellent. It’s incredibly friendly, welcoming and helpful.

If a small community is great and the tool they push is valid, it will grow until it's not great anymore. Try mentioning any tool that has grown in popularity, stood the test of time, and still has an exemplary community.

If a small community is great but the tool is not particularly good, they will stay small and simply get ignored. That's the average scenario for most languages not pushed by a wealthy vendor: you just don't hear about them because you don't need the tool.

> you need multiple anecdotes at the very least.

Meh, this is just the first of many to come, if Rust is to keep growing in popularity. It's on the same trajectory as Go, just a bit behind because it got usable a few years later.

> Meh, this is just the first of many to come, if Rust is to keep growing in popularity. It's on the same trajectory as Go, just a bit behind because it got usable a few years later.

If you originally meant that the Rust community is on the way of becoming less welcoming, well that works for me.

I’d argue any community that crosses Reddit and Open Source would cross this issue eventually - it’s not necessarily a Rust issue.

What he created and did was and is amazing.

He wouldn't have had the attention or the criticism that he got if it hadn't been so impressive. I think when something's good enough, people may actually criticize more freely. Some of that is because the project becomes worth the scrutiny. But some of it is also a status thing. If your work is good enough to give you a high enough status, you change categories a bit in peoples minds. They start to criticize you in the way that they'd criticize other entities that seem strong enough that they don't need to be protected any more.

I hope that the actix ecosystem can stick around and keep moving forward. But even if not, I think fafhrd91 made impressive contributions and I'm glad to have used and learned from his work.

Agreed, nice work fafhrd91!

-from another impressed but silent user of your project

I've been using actix-web for my work for some time, contributing however I can while learning Rust and myriad other subjects. This was the third major public event involving controversial design and implementation decisions. A great number of people in the Rust community have refused to accept that not everyone subscribes to their ideology about use of unsafe. They've repeatedly tried to impose their values and priorities upon someone who has been more than capable, if not more capable, of reasoning about legitimate issues and risks and who has his own priorities. The author has not been kind towards those who challenge his decisions, and this has not helped him navigate social issues. It's not just that he struggles with English but has a very different value system and set of priorities than those who he's had to interact with. Further, these contributions weren't from neutral parties but rather a group of long-term adversaries who have taken it upon themselves to hold Nikolay accountable for having differences. They blog, they control the narrative in message forums, they basically do everything in their power to cancel Nikolay and his tremendous work, shaping the public narrative as one that suits their goals.

It took great strength to go as far as Nikolay did in spite of these challenges. I understand why he doesn't want to participate in this culture any longer. It comes at a great cost. Unfortunately, the actix projects and its author are not the only ones who have been targeted for having differences. The next example is Ferrous Systems, who have authored a new ecosystem for asynchronous development. The team has been attacked in all sorts of ways and are going to great lengths defending themselves and to help shape the public narrative. Eventually, they will tire from constantly defending their decisions. Some will lose their patience and tempers will flare. Then, an angry mob will re-emerge and do everything in its power to cancel the momentum of their work and attack the reputations of the authors.

I don't know whether this social behavior will change without the culture changing as well. It requires a respect for viewpoint diversity and acceptance of people unlike ourselves, not just in gender orientation but in opinions and values. It includes tolerating disrespect and leaving people alone rather than trying to destroy them. I doubt these social issues are unique to the Rust community. Cancel culture seems to exist in all shapes. We aren't better for it.

I wonder to what degree the entire incident happened because Rust has unsafe-blocks.

the unsafe blocks were the catalyst

There are only 2 outcomes for Rust not having unsafe blocks:

1. Everything would be unsafe. Same as C/ C++

2. You could not use it to write real software, because not all constructs are expressible in safe code. The std lib requires unsafe to a bigger extend. Talking to the OS does the same.

Unsafe blocks are required to write software. And they are good, because they minimize the amount of code which can not be automatically audited by the compiler.

Unfortunately unsafe blocks seem to get more and more misused as a metric around the quality of software. Which is certainly not their intention.

I remember when I was young and “diverse opinions” was a phrase as celebrated as “diverse backgrounds” is today. Why we had to lose the former while (rightfully) recognizing the value of the latter is beyond me, and without both we will surely continue to descend into continued tribalism, but of a different kind.

I am a Rust beginner, and have made a few small projects with Actix Web. Actix Web is the only framework I use in Rust and spent some time learning about it. During that learning process, the docs constantly get updated but there are examples in the repo. Sometimes there aren't examples and I go to their chat room and ask the maintainer directly, and to my surprise, he always answered my question.

He is a busy guy with a life that already put immense effort to create this library and helping people to use it. He is free to do whatever he wants. People who complained, did they even give him thanks? Or donating coffee money? Grow up and stop spending your SWE salary for your vices.

Tried to write it down and help to enhance the documentation, or written an own documentation? So that reoccurring questions could be reduced.

During that time the actix web library was planning to do some breaking changes because of 1.0 target

  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO

This is part of the MIT license. Many other open source and free software licenses contain the same thing. It's simple, people provide software they write in their free time or "sponsored" by their company, in return they get nothing and you should expect nothing more than the piece of code that gets published.

People have started assuming that free and open source software is not "true" open source if you don't build a community around your project, gain a following and can take advantage in it professionally somehow.

It's a shame, as it puts a lot of pressure on people, instead of all of us just sharing code because we love coding and want to share it with everyone who also loves it.

I'm on board with your general message, however, the larger actix isn't some independent project. It is clearly endeavored to build and serve a community. And maybe that wasn't the intent of the author/maintainer? I don't know. But I'm going to tell you right now that if you don't want to be part of a community (for better and worse) the best plan is to not join one, especially not one that proselytizes itself in a way similar to many commercial/oss hybrid outfits.

I don't mean to condone people being jerks or the typical reddit brigading that is being talked about. It's just, it doesn't really matter what your license says. If you act like you're going to serve customers, you just might get some customers and if you can't deal with customers then you probably shouldn't act like you want to serve customers.

It's perfectly fine to build a project in the open and license it openly and not accept open participation.

> But I'm going to tell you right now that if you don't want to be part of a community (for better and worse) the best plan is to not join one

Well, you can want to be a part of a community one month, and not the other month, which is fine. We have other stuff going on in our lives too.

> It's perfectly fine to build a project in the open and license it openly and not accept open participation.

It's also perfectly fine to build a project in the open, license it openly and try to push for open participation, but later change your mind and not do that anymore. As mentioned, open source comes with no guarantees, what so ever. Let's keep it that way.

The MIT license isn't the only thing Actix wrote. They also wrote this:

https://actix.rs/community/

> Community: The best things in life are to be shared

> Join us - Want to talk to others about questions? The actix gitter channel or reddit community are your best starting point.

> If you think you found a bug it's best to go to the github directly. There are two repositories that you might want to report against. actix for issues with the actor framework or actix-web for the high level web framework.

> We're a welcoming community so don't be afraid to engage. Interactions are governed by our code of conduct.

I agree with you that projects aren't required to do this. (And I also agree that developers often feel pressured to build up a community for their project.) But still - that's what they wrote.

True, they did write that. But taking into consideration the license open source and free software is usually licensed under, they are free that change those opinions at any time, and you cannot blame them for it.

If you had a contract with the project, I would understand the frustration. But since it's published on a "NO-WARRANTY" and no promises basis, the persons opinion can change at any time, and that's perfectly fine.

So maybe today I feel like, yeah, my open source project should have a community! So I publicly write that. But then 6 months later I change my mind and stop trying. This is also perfectly fine. Annoying, sure, but if you want to avoid that, start making contracts with the libraries that you include in your projects.

I'd like to live in a world where, if I tell you something, you can take my word for it and you don't demand a contract for it.

Also, those words are still on the website. If the author is no longer interested in bug reports - which is absolutely the author's right, to be clear, and does not make them a bad person - they ought to at least change the language on the website to make it clear. Otherwise the language encourages people to waste their time, which is pretty rude.

Removing the repos seems to be a bit much especially since he is planning on making them private and then deleting them.

Why not just leave them in place if you're burned out and see if anyone is willing to take over maintainership.

Given, I don't know the history, but I always feel a bit of pain when code gets lost or destroyed in the heat of the moment.

They have been moved to his personal account for the time being:

https://github.com/fafhrd91/actix-web

https://github.com/fafhrd91/actix-net

> Why not just leave them in place if you're burned out and see if anyone is willing to take over maintainership.

Because a proper hand-off is also a lot of work, which continues the burn-out and the chances of a new maintainer stepping in are slim-to-none (there were already attempts to find one after the last "actix unsafe discussion").

The entitlement in this thread is astounding. Don't like how the project is maintained? Fork it. If you don't have anything nice to say to the person who gave you the code _for free_, then just don't say anything at all.

The repo currently contains a single README.md.

https://github.com/actix/actix-web

Edit: I was not aware he moved it under his personal github account and it’s still accessible. Nonetheless, I still think removing it is a bit extreme.

Yea, because the maintainer was tired of being abused.

I understand how he may he feeling, but this is probably the most used web framework for Rust. He may be hurting a lot more people and projects then just the people he disagreed with.

A proper way of handling this would have been to abandon the project and let someone else pick it up. My understanding is that he did move the source code under his own git user, so hopefully he’ll allow someone else to pick it and maintain.

> I understand how he may he feeling, but this is probably the most used web framework for Rust.

Not a problem. Just fork it and put in the work to maintain it. The license grants anyonr that right. What stops anyone from doing it?

If that's too much to ask then perhaps it should put into perspective how project maintainers are abused.

You haven’t read my comment from two levels up. There’s nothing to fork on the original repo.

There certainly is: https://github.com/fafhrd91/actix-web

Ok, but the arrow of time being what it is you cannot fork something usefully after all the code has been taken away. You can now fork the readme and change that.

It's true I think everyone should do what I do which is to fork anything I think I might need at some point , but that isn't what you actually suggested and it isn't what the parent comment was observing could be a problem for people.

As stated clearly in the README:

> P.S. I moved actix-net and actix-web project to my personal github account.

So he's transferred it to:

https://github.com/fafhrd91/actix-web

Feel free to fork, take a copy, start a new repo. The project is dual Apache/MIT licensed so feel free to do whatever you want within its very liberal scope.

What you're not entitled to do is demand anything from the author or to take up any of his time. Take his code, but don't demand anything else from him.

> Nowadays supporting actix project is not fun, and be part of rust community is not fun as well.

> I am done with open source.

He's over the abuse and entitlement his received over the project and obviously doesn't want to spend any more of his time on it.

Sorry, I interpreted that to mean his private account, which was silly.

You bring all this righteous indignation, and didn't actually read the readme where he tells you were the repo has gone in case you want to fork it and assume the responsibility of maintaining it. I think we've reached the perfect intersection of "entitlement" and "laziness".

> My understanding is that he did move the source code under his own git user

It's not hard to find: https://github.com/fafhrd91/actix-web

> so hopefully he’ll allow someone else to pick it and maintain.

It uses the both the Apache and MIT licenses, each of which clearly allows redistribution of derivative works. It will be interesting to see if anyone (much less the abusive people) are willing to put their money where their mouths are about it.

I think he's being very gracious, all things considered.

He moved the repo's to his personal account. Still there (for now): https://github.com/fafhrd91/actix-web

Especially weird seeing as Github has made forking a very smooth way to work with a project. You fork it, make the changes you want, and then make the changes available upstream.

If upstream vanishes, your fork is still around.

If upstream doesn't want to merge, people can use your fork instead. And, if your changes are that much better, eventually make it the de-facto standard version of the project.

The commits you do in a fork are not visible in your GitHub commit calender until you do a PR and they are merged. For some people this is important so a "forked" project won't have many commits with merging back to master.

You can merge your commits into a separate branch and designate it as the "default" branch for your repository.

lol what?

They won't contribute or work on something unless it touches their commit calendar?

I'm kind of…

I guess that's not really a use case I'm concerned with, contribution-wise.

But who knows! Maybe most of open source work is done for personal vanity.

Yes, and it happens all the time in other projects. There's always "so-and-so's fork that implements feature X and changes Y", and it's awesome that that's a possibility since it means no project is held hostage by its maintainer, and that differences in priorities don't mean the code can't be useful for a range of use cases.

I made much the same point in the other conversation about this.

The beauty of open source code is you can take it, modify it, and even improve and rename it in a lot of cases.

So much of today's internet has to be a fight or a shitstorm. For no reason at all.

This argument confuses and saddens me. If I give away free food which I and others know to be contaminated with foodborne pathogens, is it wrong for them to criticize it? What if I don't know, but I obtain it from a supplier which is known to persistently sell contaminated food? What if I put up a sign in very small print saying that the food comes with no warranty whatsoever and all consumers eat it at their own risk? What if I put up a large sign? What if instead of pathogens, I intentionally add lead-based decorations on the basis that they look and taste good, even if they may be slightly carcinogenic if consumed? What if I clearly state that the decorations must be removed before eating? At what point do I acquire moral culpability for the harms suffered by my customers? These sorts of comments seem to imply that there is no problem with me doing any of this, as long as the food is provided for free and consumers have the choice to not take the food. I would vehemently disagree with that claim. Uninformed choice is not a true choice, and even informed choice cannot excuse certain foreseeable harms.

There's a difference between leaving poisoned but attractive looking food on a sidewalk, and putting code on github. You're losing perspective regarding open source programming -- it's supposed to be fun. There seems to be a political / ideological dimension to this disagreement. Your nanny state would be correct to punish someone for leaving poisoned food out. But we don't need your nanny state in open source software. People can choose to use or not use free software. Anyone whose software has life or death implications would indeed be culpable if they make those choices rashly. But the responsibility does not lie with the maintainer.

That is an entirely specious analogy. This code will not cause someone to get sick or die. And "contaminated" vs. "not contaminated" is a binary result for food -- one is the case and one is not the case. With code, there's nearly always room for reasonable disagreement as to what is the right/good or wrong/bad way to do things, and often people argue over two (or more) perfectly fine ways of doing things that just come down to a matter of style.

I'm not sure if this will change your mind, but in the Rust world, there's a concept of "unsafe" code that can lead to vulnerabilities.

The difference here is that a code consumer can check a Rust project for unsafe code, whereas a food consumer cannot check for unsafe contaminants.

If it's OK to demand a project use only Rust and not unsafe Rust, then it must be OK to bitch at every C or C++ project and demand they rewrite in Rust. If that sounds absurd, that's because it's supposed to.

That's not really an apples-to-apples comparison.

From what I can tell, actix was using unsafe code to improve benchmark performance, not because safe code was extra work. That's fine, but it was misleadingly marketed as more than a toy project, and it shouldn't have been.

Further, rewriting a project is very different from just making different coding decisions when maintaining an existing project.

I still think the actix critics are showing how irresponsible they are for blindly using a library without researching it well.

Indeed. Not to mention, embracing this analogy means literally all food is poison because every piece of software has critical security vulnerabilities whether they are widely known or as of yet discovered.

Are you seriously claiming that food contamination is a "binary" thing? That it's impossible for food to be only a little contaminated, at a level that won't make you "get sick and die?"

Its common knowledge that a certain amount of food contamination is considered safe. And, although specifics are not generally common knowledge, it's easy enough to find that, e.g., the FDA views < 100 ppb of lead in candy as safe.

I don't think hyperbole is helpful to this conversation.

>Are you seriously claiming that food contamination is a binary thing? That it's impossible for food to be only a little contaminated, at a level that won't make you "get sick and die?"

>I'm sorry, but I think you're being disingenuous. Every little kid knows there's some small amount of nasty stuff that's allowed in things like bread (grasshoppers in the wheat fields caught in the combines) and peanut butter because it's such a small amount of contamination and doesn't pose a health risk.

>Please don't be disingenuous in your arguments. It only serves to exacerbate the polarization over contentious issues.

At least he tried to answer in a good faith. Your answer is a lot worse.

That's exactly it. He did not answer in good faith. He answered with a false dichotomy that everyone knows is false.

Not sure why you're upset at me for calling it out.

I mean, the license state:

> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

So if some random person on the side of the street gave away browny, and had a sign like that, I'd do a bit of personal investigating first before eating it, like looking at the ingredients, asking for expiry, and all that. Which you can do for open source software, by just looking at the source code.

Being a maintainer on a popular open source project can be hard. You put expectations on yourself, others put expectations on you, people complain, people trash talk you because they think they can do it better, and so much more.

I think this highlights that maintainers need support systems to help with this. We can use GitHub features to mute or block people. We can have CoCs and try to avoid people who cause issues. But, they still happen and maintainers need help. Someone to talk to, people who have been there, support groups, strategies, and sometimes sabbaticals.

I feel for this guy and hope some time away will help him personally.

We did this to him. [1] We drove him to burn-out. We should reflect on that and make sure we don't ever do that again to any open-source maintainer. And we should pay more of them for their work.

[1]: Including me, as I contributed to a comment thread here about cheating on benchmarks.

Good for him to make a stand!

I can completely understand how he felt. Similar things happened to my open source projects, admittedly at a smaller scale. Users became so entitled to open source software and became hostile. Well, i nipped the problems at the bud by moving the projects off open source license. There were a few people crying foul and vowed not to use it. Fine. I respected their choices, and let's move our separate way.

There're requests to open source and hand the projects to someone else. No. I want to maintain control of the project development and direction, like directors wanting to maintain artistic control over their movies. If someone is so fired up, they can always write their own open source software.

would you have declined a patch that fixes a real problem because it is boring? i do not really get that kind of thinking either. personally i would have accepted it and replaced with something clever latter on

Yes, I would. Because that patch is a "style" patch. It's not important in the author's roadmap for the project.

People ask for different things and think their things are the most important, and when they don't get their way, screaming and kicking to force them in. They can always fork it or create a separate project if it's so important.

I wrote "fixes a problem" explicitly. How is that a "style" patch?

Some people treat style as a problem. In the context of “boring” conversation the problem was the unsafe usage. How’s that not style?

An argument could be made both ways, but I wish people stopped quoting licenses to resolve social issues.

For example, the license does not forbid the user of the software from INSINUATING THAT THE AUTHOR OF THE SOFTWARE IS INCOMPETENT, OR UNFIT TO AUTHOR ANY SOFTWARE, EITHER IN A PARTICULAR LANGUAGE OF THEIR CHOICE, OR IN GENERAL. So one can almost say that anyone who's doing it is exercising their right granted by license.

...But that kind of argument is not really helpful, isn't it? The question is whether some behavior is socially acceptable. License doesn't enter the question.

(BTW, of course I don't support the kind of behavior I endorsed(?) above.)

> ...But that kind of argument is not really helpful, isn't it? The question is whether some behavior is socially acceptable. License doesn't enter the question.

> (BTW, of course I don't support the kind of behavior I endorsed(?) above.)

Let's say someone wants to release some open source software to the world. But they also want to retain the right to remove their currently published copy at any point, their right to reject patches and generally do what they like without being slurred and berated by everyone else.

Aside from adding a plaintext file alongside the code that explicitly says (sometimes in capital letters!) that the code is supplied with no warranty or obligation, explicitly or implied, what should they do?

Isn't it clearly the case that the license explicitly states the social contract?

Closed source is more fun to develop. You get full control over your code, you just have to meet the needs of people who think it is worth enough to pay for it, you can code in whatever eccentric manner you want, and you get to keep the nice wads of cash if it becomes successful. If security is a problem, then the people with wads of cash will leave, but at least there is some incentive there.

I would advise people who decide to embark on large, hard projects like this to stop making them free. Make the source open if you want, but charge money. Either for the product, or for support requests, something. This not only filters out entitled assholes, but it gets you money, money that you can maybe use to pay people to help, or at least to buy a beer.

This is an unfortunate conclusion that I also arrived at after much consideration. I have a proposed dream project in front of me that would take at least 2000 hours to reach MVP. Do I just give it away for free on GitHub under MIT? I spent over a decade honing the skills that allow me to even engage with such a difficult objective. Why should I just give it all away unfettered? What alternative approaches exist in which I share these wonderful new ideas openly and also somehow reap the benefits?

I feel that for certain projects like vendor API integration libraries, opening up the source for all to use freely is the best path. But for others, where years of intellectual property and personal development exist predominantly within the code itself... I think I want to keep this kind of code to myself for now.

I wish that the author have read this "The Hard Parts of Open Source" by Evan Czaplicki https://www.youtube.com/watch?v=o_4EX4dPppA

I thought about exactly that as well :).

Asking for a friend - could someone explain what happened there? The README doc is quite vague - it is more of a personal justification than a rationale (to me).

Sounds like the maintainer writes a lot of code using rust's "unsafe" keyword, and regularly gets issues raised about this (and versioning, and some other bits).

This last issue, which included a patch, has pushed them over the edge after it descended into disagreement.

Net/net they were repeatedly asked to change coding style, didn't want to, and have decided it's better to just avoid the arguments by not publishing code.

The maintainer can choose whatever style they damn well please, if you don't like it don't use it.

What is hard about this?

Is it a community run project or not? The website seems to imply that the community is welcome to participate: "We're a welcoming community so don't be afraid to engage."

There is no such thing as a community run project. But either way, people told the author to literally stop writing Rust code because he doesn't respect semver. This is not a participation, this is just hate.

There's a difference between engaging and putting up with raging users

It's not coding style, it's refusing to investigate use-after-free vulnerabilities in code because it's "boring". Noone should care if a maintainer uses tabs or spaces, or has weird variable naming, but if "coding-style" leads to security issues (due to hand-rolling unsafe memory-primitives), then it is an actual issue, especially if it's for a popular web-framework.

Don't like it, don't use it doesn't really apply to security vulnerabilities in such major packages.

Flaming and personal attacks are not the solution to this stuff, but this drama feels somewhat self-inflicted.

> it's refusing to investigate use-after-free vulnerabilities

Please investigate yourself, don't ask others to do the work you consider important for you for free.

The reporter included a patch.

People did investigate for him and write a patch for him and he dismissed the patch with it being "boring".

Well, maybe people didn't provide detailed enough explanation for the author to understand and merge the patch, so he didn't bother.

Judge for yourself: https://web.archive.org/web/20200116203731/https://github.co...

It seems like the better solution here would have been for the folks who wanted a fixed version of the software to create and maintain a "actix-done-right" fork themselves. This is what we all do in the professional world when a maintainer doesn't want to upstream critical patches for whatever reason.

They're under no obligation to upstream your patch, but it's open source so you're not powerless either! Why so much drama over a rejected PR?

Creating a fork is generally not the optimal solution. Both current and future users benefit from a patch, only those that hear about it benefit from a fork.

Now, in a case like this where the maintainer won't accept patches, yes, fork and move on would have been better.

> somewhat self-inflicted

Let's not start victim-blaming please.

Yes, the maintainer could have made his reasons for making the project more clear, and the maintainer could have been more clear on the intended use of the project (not for production, personal project to see how fast Rust can be, etc). There are a lot of things the maintainer could have done.

However, that doesn't mean there wasn't a problem. There was a ton of negativity around "unsafe" when the author first released the code, and it has kind of become a meme at this point. If a project consistently uses code in an unsafe way, is it really worth spending your time vetting it for your production use case? There are plenty of web severs out there, pick one that aligns with your goals.

For future maintainers of projects, please do yourself a favor and clearly state the intentions of your project. Is it for production use or just a personal project to see how far you can take an idea? Make it clear and get into the habit of reminding people of the project's goals. I am very grateful for projects that do that since it helps me save a ton of time for both the maintainers and myself.

There seems to be a mismatch between the maintainer's expectations of the project and the community's expectations. It's unfortunate that the author decided to pull it, but hopefully this is a lesson to the community to make sure a project is a good fit before diving in with suggestions.

> However, that doesn't mean there wasn't a problem. There was a ton of negativity around "unsafe" when the author first released the code, and it has kind of become a meme at this point. If a project consistently uses code in an unsafe way, is it really worth spending your time vetting it for your production use case? There are plenty of web severs out there, pick one that aligns with your goals.

Should people wait until credit-card data or PII is leaked due to security vulnerabilities? The problem with security is that it impacts more than just the programmers using the framework, it impacts everyone. Does the author deserve the nastiness? No. Do security issues need to be reported, and if not fixed, called out? Yes, for big and advertised projects issues like that need to be reported. If not, there will be users that would naively expect the web-framework they're using to be somewhat secure.

The framework had a professional looking website advertising the project, it had good documentation, a user-friendly API. It advertised a actix open-source community. Had over a million downloads. I would say that expecting actix to be run like a somewhat professional project is not a strange assumption.

The way it was called out was pretty terrible though, and I doubt anyone is happy with what happened.

If personal info or CC data gets leaked, the company which used this library/framework will be found legally liable. Using random code from github is not a valid product development strategy.

The author can write their entire code in an unsafe block for all they care. The buck stops with those that use the framework and that is made quite clear in the license.

Welp.

Time to close up shop folks, we didn't personally perform a deep security audit of every single open source project we depend on!

"Don't like it, don't use it" applies in all situations where the code is free to you and you didn't enter into a contract to "correct" those things that you don't like. People were always free to fork the code and fix what they don't like.

Civility, apparently.

Some people just never "grow up" and/or learn how to treat people with respect, and developers are not special in that regard.

https://www.reddit.com/r/rust/comments/epszt7/actixnet_unsou... context for the "boring" patch.

Actix is full of "unsafe" blocks and the maintainer got a constant stream of criticism over it.

https://www.reddit.com/r/rust/comments/epszt7/actixnet_unsou... has more context.

The Wayback Machine links don't seem to work anymore, unfortunately.

The issue was triggered by someone executing a benchmark on http crates and opening an issue on github, that was then deleted after some heated back and forth.

https://www.reddit.com/r/rust/comments/epoloy/ive_smoketeste...

From the maintainer point of view, it seemed to have been the straw that broke the camel back, but I don't know the whole background.

Still seems like a sad story

Wow. Talk about a bad response though. No matter how abused you may feel as the sole maintainer you should still not throw a tantrum. Censoring an issue title, body, and comments is a gross overreaction. If you want to throw in the towel then just throw in the towel.

It seems like the overarching issue is that Rust is a house of cards. They added unsafe like Java has null. My favorite part is that you can declare a crate to forbid unsafe, but that then doesn't have to hold for it's dependencies.

The obvious implementation is for unsafe to be infectious like const. You have unsafe code, your crate is unsafe. You depend on an unsafe crate, your crate becomes unsafe.

I wish there was a better way of handling that in Rust. You should be able to have a few markers in your code:

- uses unsafe - no unsafe, but dependencies may use unsafe - no unsafe, no dependencies except the standard library may use unsafe - no unsafe, not even in the standard library uses

The current situation is the second one, but many cases probably want the third, and occasionally the fourth.

The best part is, this should be fairly easily solved by crates.io upon submission (is there any use of unsafe and are all dependencies marked as strict or more strictly than yours?).

> The obvious implementation is for unsafe to be infectious like const. You have unsafe code, your crate is unsafe. You depend on an unsafe crate, your crate becomes unsafe.

That would mean everything is unsafe, since every crate depends on core (or on std which depends on core), which has "unsafe" code.

The design of "unsafe" in Rust, instead, is to allow building safe abstractions on top of unsafe code (or be able to clearly mark when the abstraction itself is unsafe). That way, for instance, users of `Vec::push` do not have to worry that it uses uninitialized memory (which is unsafe).

That would prevent you from using the stdlib.

https://doc.rust-lang.org/src/alloc/string.rs.html#1215-1230

Using unsafe doesnt necessarily mean you will have undefined behaviour, it just means you have to think really hard about the behaviour because the compiler won't have your back.

This is a poor comment. You clearly don't understand how unsafe is to be used. No code (of significant size) that you run will be bug free ever. So you might as well start from that assumption and realize you are trying to minimize the amount of unsafe code and bugs; you will never remove all of them no matter what the language.

Concerning is what message this sends to other OSS developers. One goes into F/OSS knowing full well there will be little rewards financially - but facing harassment or attacks on their reputation cannot encourage future projects.

Is it too late to set up a SafeActix project, let him keep the Actix name & creative control, and resolve things semi-positively? Seems like the community mistook it as an effort to build something safe, and it was a thousand cuts of misconceptions/asks. Maybe open an issue and give them a week to decide/vote a new name. I don't think there's an obligation per se, it would just be better.

Poor guy, writing code for fun and maintaining an OSS project long term aren't the same thing. Nor do they require the same skill set.

With abit of elbow grease we can pick the project up again, "reputational damage" is not the end https://en.wikipedia.org/wiki/Service_recovery_paradox

To me, this displays a deep misunderstanding of FOSS on the part of this projects maintainer. He wants to create a project, promote that project to the top of it's field, and completely ignore the perception of his userbase. Then he fell back on "it's my code I'll do what I want with it." That would be fine, but he "sold" people on this code with the understanding that we were all going to take it to it's maximum potential. This was marketed as something which would solve specific needs better than similar products. Most people can handle regression and bugs and regular ongoing refactors as everyone struggles to bring this same piece of code to the next level. What people, especially the dev community, cannot overcome is when they are told that a project has a direction that it clearly doesn't have. If this maintainer had no intention of accepting feedback from his users there should have been a clear indication of that somewhere in the docs.

If you never reconcile your reasoning and expectations with your community then they will deduce reasoning and expectations that you never implied. This maintainer wanted to produce a popular piece of software not to contribute to the Rust community, or because he wanted to make lives easier. This isn't the attitude of someone who is trying to improve his skills or challenge his knowledge of Rust. He obviously didn't do it to get rich. I believe he made actix-web to get famous. He wanted blind recognition for being selfless. He wanted a community of docile dependents who sit up late on GH hitting the refresh button waiting for his next push. He seems to have only wanted to make a product that people revered. When that didn't happen because he never reconciled his goals with the communities expectations he took his ball and went home. "What??? No fame? No glory? Criticism!?!? Fine, no soup for you."

Is this the same actix that won recent Techempower benchmarks? What a pity!

Yes.

The very normal path of growing up as a leader:

1. people are good -> trying to do something good

2. doing good -> realizing many people are not good

3. stop doing good thing, start being frustrated

4. realizing one doesn't need to let people pull oneself down -> start doing good again

5. helping others to do good things and surviving the first shock of being visible

6. $$$

Similar burnout happened with Ecstatic, a very popular Node.js static file serving library.

https://github.com/jfhbrook/node-ecstatic/issues/259

It should be noted that the code wasn't deleted, but forked to his private repo, where it's still open for anyone to use, download, fork, ...

if the issues are so bad and the author doesn't want to fix them, just fork it and avoid all the arguments that won't lead anywhere.

Sad to see this. I'm using Actix in a new project and have been watching the project for a while. Guess I'll be refactoring to use Hyper. If I were farther along I'd probably try to take ownership, but it doesn't make sense given that it's only around 40 LOC in my project that depend on Actix at this point so switching out to another framework is more straightforward than taking ownership of a codebase I don't know.

I understand fafhrd91's (the maintainer) frustration, but it would have been much better to just abandon the project and throw it up for some other volunteer to come in and take it over. Then the project can live on and he can bask in any success it has in the years down the road. Instead, it's a complete mess where all the good work and good will has been undone in a single move.

I've abandoned multiple OSS projects over the years and let other maintainers come in and take them over. Now over 10 years later I can still say I created that project that still gets used because other people have seen value in continuing to contribute and maintain it.

Reminds me of this "Open Source is Not About You": https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...

Agree 100% with the maintainer, read some of the comments on /r/rust and on Github, I haven't seen a more rude sanctimonious community in my 12 years programming. Holy shit!

Rustaceans my ass! From now on Rudeaceans.

Check out their official channels. Anything on reddit is going to be toxic unless it is highly curated by the subreddit mods. That's just the reality of reddit.

People should really learn to ignore the emotional channel of the comments they receive. Just try to figure out if the message contains any useful information with a quick glance, extract it if it does and ignore the rest. People have to shit - that's physiologically inevitable, and there are people who do it in the streets and there are people who shit in comments/messages. Why take them serious?

Easy to say, not so easy to do.

Quite easy to do once you realize you can, adjust the mindset and have some practice. There probably is a lot of garbage in your spam folder - do you take it seriously?

I used to do tech support and some people (not too many) wrote right out rude or nonsensical (like concluding I hate their religion just from the fact our service failed to suit their specific needs). I would just answer such sort of robotically (if their message contained a question which made any logical sense) or ignore them (despite I generally am extremely compassionate and always do my best to help).

Have you ever looked at a glass of a window rather than at an object behind it? Just don't focus on the idea there is a person hating you (there are much more people loving you, by the way, even if they don't write you), instead focus on the fact you are viewing a string which only contains garbage data.

Go to an anonymous image board and look at people writing things which would be unimaginable to see here. Write some yourself perhaps. That can make a nice practice quickly.

> I used to do tech support

As someone who also "graduated" through the trenches of tech-support, I think you underestimate how much that job hardened you and made you able to evaluate this sort of situations in a more detached way. The ability to calm down, bypass a human, and get to the root of a problem standing behind such human, is a skill that few people develop outside of such jobs. Even in healthcare, where "troubleshooting" agitated people is an almost daily occurrence, not everyone learns to cope.

Perhaps. And that's what, in my opinion, people should actively engage in learning.

Perhaps somebody should build a chat-bot which would insult you in various ways and you are to just look at that and respond calmly (while being mindful of your feelings and avoiding feeling bad). That might suit for a risk-free exercise. And as I have mentioned, anonymous image boards are a useful experience too.

BTW I've seen a number of movies about the military where a sergeant would shower the recruits with humiliating insults - perhaps that's the purpose of the act.

Whatever, I can recommend "the fourth way" book by Peter D. Ouspensky to whoever feels interested in developing their capacity to deal with negative emotions rationally and doesn't mind a humble bit of mystical speaking (there is some + it is not really scientific as a whole yet I find it quite rational and, well, amazing). It has helped me a lot.

The most famous of those movies is the one where one of the recruits snaps and murders the sergeant and himself. Not a great example of how human interactions should go.

> I used to do tech support and some people (not too many) wrote right out rude or nonsensical (like concluding I hate their religion just from the fact our service failed to suit their specific needs).

This isn't at all the same thing. You were paid to do your job, and at the end of the day you could just joke about those weirdos.

When working on an open-source project, everything becomes much more personal because your motivation is fuelled by your own personal attachement to the project. Imagine you're helping elderly people cross the street every day, and every once in a while they yell at you for not doing it better, whatever that means. At some point is it still worth it?

And of course you can't just put that behind you once you're back home, because this abuse happens at home. I remember this time where someone literally told me to kill myself while I was fixing a bug - at midnight - in a project I handle. Or the time I woke up only to see that during the night someone public had decided to openly send me literal fuck emojis on Twitter to right a perceived wrong. Good times.

So yeah - building a shell is the right solution, but it's hard and we really shouldn't have to deal with that in the first place.

I get you point, it makes sense, but I feel like I personally have already grown over that and everybody can: just know what are doing the job for. Are you helping the elderly to get their gratitude? No, just because I'm doing the right thing and I know some of them are jerks because loosing their sanity to Alzheimer's and because of hard life they had. Are you maintaining a free project for users' gratitude? No, I do because it's fun, because it expands my experience, fulfills my own needs, improves my CV and because I'm glad if somebody can use it for good. Never expect a reward if it's not guaranteed in the first place.

Should they ignore the negative parts or should people who comment be mindful of the fact that a lot of open source they use is created in someone’s spare time and that they have a human being, not a company? I’d think the latter.

Sure. Both should but that would be naïve to expect the others to do. I write "people should" putting myself in place of the protagonist. Going to the woods don't make drama of the mosquitoes biting you.

Is the reverse true? Should we make no hay of the fact that someone who was tired of being bit chose to leave the woods?

I absolutely don't judge him and I do understand. I just feel like it could be great (for themselves and for everybody) if whoever is smart enough (and he certainly is) would consciously work on their emotional intelligence. Sadly, such an idea doesn't even come to the field of attention of most of the people so perhaps me suggesting that may help somebody. As for the jerks around there will always be enough and we can hardly expect them to improve. I've met too many in my past and once I've got too tired of them I've started to study emotional inteligence, mindfulness, applied psychology etc to become emotionally immune to them (and to many other things) and to communicate to them constructively. I just believe in him (and other people like him) and don't really believe in them (most of them) at this point (perhaps they could be different if they were taught a right way) - that's why I say what he should do, not what them should.

> As for the jerks around there will always be enough and we can hardly expect them to improve

This is why many community systems have ban tools.

You obviously have never participated in open source and are talking about something you had ZERO experience with. Go participate in a toxic open source community for a couple of months and report back about not only the experience but also you emotional well being. I can guarantee you'll be reading your comment and cringing at what you once wrote.

btw, there is and awesome life lesson in this comment i posted, if you can remove the emotional part of it ;)

Now I consider your message a puzzle and am curious about what awesome life lesson have you hidden in it. I am going to re-read it over and over again :-)

> People have to shit - that's physiologically inevitable

I don't think that's universally true. In fact, I think there's a handful of people who don't know how to treat others like human beings and a lack of accountability for their behavior online.

The fact that there is a thing true of open source---it's a harbor for toxic cultures where people aren't held accountable for talking to each other like garbage---doesn't mean we need to just accept that or look the other way. As this situation demonstrates, toxic culture has costs.

For some reason lots of people on HN push stoicism as a virtue. Not all of us are 100% unaffected by dealing with jerks, and we like to get ourselves out of toxic environments that make us unhappy. Is that so bad?

The value in stoicism is that it lets people transcend limitations they have control over. It's a tool and comes in many packages (e.g.: "God, grant me the serenity to accept the things I cannot change, Courage to change the things I can, And wisdom to know the difference.").

Lots of "people on HN push stoicism" because a great many people in all walks of life share life lessons that can be categorized as stoic.

>Not all of us are 100% unaffected by dealing with jerks, and we like to get ourselves out of toxic environments that make us unhappy. Is that so bad?

This is reductive. If you were to undertake a real appraisal of the ideas with a goal to separate the wheat from the chaff, as well as feel out the boundaries of what is often presented as blanket advice (rather than try to get one over on "people on HN"), the advice people are trying to offer would make more sense.

Stoicism is fine, I don't have a problem with it, but I have a problem with people chiming in with attitude advice in face of a non-attitude problem.

Saying someone should be more stoic, especially with a "like me", in the face of a problem, is like telling somebody "deal with it" or "lighten up". At best it's not constructive, at worst it's bragging and putting someone down.

And it deflects the actual problem. The problem here was "too many people were jerks" not "you are too sensitive".

> The problem here was "too many people were jerks" not "you are too sensitive".

So what a solution would you suggest for such a problem? I believe it is more correct to say both are the problems. I have no idea what is possible to do with the jerks themselves but I know it is possible to become immune.

When there is a disease outbreak obviously the problem is the virus but we can't just make it disappear magically so we choose to address it's couple problem - our immunity weakness, we take a vaccine, teach our immune systems to detect the virus, become immune and keep on going.

I have never meant judging the Actix author for "being a pussy", I have proposed the only solution I could come up with.

In fact I have already met some people with alike problems personally, explained them the idea and in some days they thanked me for showing them another perspective which couldn't come to their minds. They didn't know they could just observe the others' behavior (as well as their own feelings) and consciously choose what to feel. Perhaps this might seem like bragging again but I prefer to take a risk of being judged this way for the chance of actually helping at least a portion of people who reads this.

When you have come through some problems successfully and developed a skill necessary, telling about that inevitably sounds like bragging, but IMHO keeping it for yourself (when it could help others) just because of being afraid of being shamed would be selfish.

Your mind is entirely yours, it's the only really private place and you don't have let anybody in to spread chaos there. Trolls want just that and you don't have to obey. It's a magical space free from the limitations of the material world, entirely under your own power, your intention alone is enough to do whatever you want there. If somebody attacks you physically you can't just ignore that, they will damage you anyway. If somebody attacks you verbally you can react by feeling something or nothing at all, all you need is to know you can (and be mindful of what's going on at the moment in the first place), much like Neo in the Matrix.

I agree with you. Really it is something that probably can be learned over time. I think it helps a lot to just remember how much money this or that dumb hater have paid for their entitlements (i.e. nothing), which -at leas in my eyes- emotionally reduces their words to a child's tantrum.

Sure, but it helps more to realize once and forever: all the shit anybody says is just a "child's tantrum". Real grown-ups don't behave this way, too many people just don't grow up as they age.

On the other hand, we should also understand that a constant stream of insults, contempt, and general negativity around every step one takes, can and will bring anyone down, and even induce depression

"The thing is that, of course, there are totally different ways to think about these kinds of situations. In this traffic, all these vehicles stopped and idling in my way, it’s not impossible that some of these people in SUV’s have been in horrible auto accidents in the past, and now find driving so terrifying that their therapist has all but ordered them to get a huge, heavy SUV so they can feel safe enough to drive. Or that the Hummer that just cut me off is maybe being driven by a father whose little child is hurt or sick in the seat next to him, and he’s trying to get this kid to the hospital, and he’s in a bigger, more legitimate hurry than I am: it is actually I who am in HIS way.

Or I can choose to force myself to consider the likelihood that everyone else in the supermarket’s checkout line is just as bored and frustrated as I am, and that some of these people probably have harder, more tedious and painful lives than I do.

Again, please don’t think that I’m giving you moral advice, or that I’m saying you are supposed to think this way, or that anyone expects you to just automatically do it. Because it’s hard. It takes will and effort, and if you are like me, some days you won’t be able to do it, or you just flat out won’t want to.

But most days, if you’re aware enough to give yourself a choice, you can choose to look differently at this fat, dead-eyed, over-made-up lady who just screamed at her kid in the checkout line. Maybe she’s not usually like this. Maybe she’s been up three straight nights holding the hand of a husband who is dying of bone cancer. Or maybe this very lady is the low-wage clerk at the motor vehicle department, who just yesterday helped your spouse resolve a horrific, infuriating, red-tape problem through some small act of bureaucratic kindness. Of course, none of this is likely, but it’s also not impossible. It just depends what you want to consider. If you’re automatically sure that you know what reality is, and you are operating on your default setting, then you, like me, probably won’t consider possibilities that aren’t annoying and miserable. But if you really learn how to pay attention, then you will know there are other options. It will actually be within your power to experience a crowded, hot, slow, consumer-hell type situation as not only meaningful, but sacred, on fire with the same force that made the stars: love, fellowship, the mystical oneness of all things deep down.

Not that that mystical stuff is necessarily true. The only thing that’s capital-T True is that you get to decide how you’re gonna try to see it."

Because it is very very hard to ignore.

I very occasionally get death threats to my work email due to people being unhappy with some public facing stuff I do. It's unsettling but I can mostly ignore it. But if it happened all the time and I wasn't able to open my email or interact with a community without getting hate mail I'd go into a cocoon. People aren't machines. When hatred is relentless it is unbelievably difficult to put it aside.

Is this sort of action unprecedented?

What was Actix-web?

A web server built on an actor framework and probably the fastest Rust web server out there for many use cases.

I used it because it was easy to fill my niche case (TCP + UDP + WebSockets + HTTP interfaces to the same thing) as well as my boring CRUD apps, and it worked on stable Rust since a long time ago.

The author got a lot of flack for using "unsafe", then fixed most uses of "unsafe" and it has become something of a meme now. Unfortunately, there's an odd, almost religious crusade against unsafe in the Rust community, especially by those who don't really understand the ramifications of using unsafe incorrectly or how to tell whether unsafe is being used correctly.

It's a cool project and I have loved using it. I'm probably going to use something else unless someone steps up with a commitment to maintaining a fork.

Thanks for the explanation.

It's funny to see history repeat itself with "Unsafe" hooks. JAVA has a number of projects which also do this for speed and it always freaks people out.

The open source equivalent of the rage-quit hehe.

I don't get it. This is a Git project. So did none of these people actually bother to clone it?

Probably easier to just rely on binaries . . . suckers!

One of the downsides to GitHub is that it stores a lot of state that Git cannot capture, and is at the mercy of project maintainers to continue existing unaltered.

But forks prevent that, right?

No, forks don’t include issues or pull requests, among other things. Another problem is with “canonical links”: people will link to comments on the “original” project, which are at the mercy of maintainers to not be edited or deleted.

There are plenty of repository clones, that's not the issue. The issue is that people want to contribute back to the same repository so you don't have to figure out which project is the just up to date. When a project like this goes away, it takes some time for everyone to figure out which fork is actually being maintained properly.

The best course of action, IMO, is to state that you're stepping away, perhaps indefinitely, and ask if anyone wants to be added as an admin to take over. That's not required, but it's a nice thing to do.

I'm sad about this on a lot of levels, any I hope the maintainer does what I'd like, but if not, I'll just wait a few months and see how the dust settles. For now, I'll probably go back to investigating other projects.

The Linux kernel has no central repository, they use email & stuff. I believe that is what the author of Git intended.

> The Linux kernel has no central repository

It does have a central repository, it's this one: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

> and ask if anyone wants to be added as an admin to take over.

That's the worse possible course of action, this is how you get RCE vulnerability or bitcoin stealing malware injected into a popular project. Other random people should not be able to take over any project, they should do the work to promote their own fork and gain their own reputation. At least until we have a language able to protect from threats like that.

In case you're directly impacted by this, https://www.arewewebyet.org/topics/frameworks/ provides a list of web development frameworks for use with Rust. Just pick one with a less cowboy-coding oriented attitude than Actix-web, and you should be OK.

Like it or not, it's best to view this incident as having direct parallels to the NPM left-pad incident.

Ignoring the specifics of what led up to this for the moment, observe that a single person was able to completely annihilate an entire dependency's source.

I think one of the primary requisites to reliable FOSS development and adoption will need to be tooling that maintains immutable records to the best of its ability, so that prior artifacts cannot be revoked; you publish code as FOSS, it is with the clear understanding that you have disposed of your authority to revoke it.

There are cases where something may need to be revoked, but make it a multi-layer process at that point, not a single button and one man's whim.

Reply on news.ycombinator.com