Live data from Hacker News

Actix project postmortem

github.com

281–290 of 408 posts

Re: Actix project postmortem

#281
post #244

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.

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 ris…

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.

Re: Actix project postmortem

#282
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.

Re: Actix project postmortem

#283
post #154
post #128

Earlier quoted context omitted.

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.

Re: Actix project postmortem

#284

Earlier quoted context omitted.

> 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 thi…

> 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.

Re: Actix project postmortem

#285
post #35

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…

"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 suppor…

> "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.

Re: Actix project postmortem

#286
post #244

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.

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.

Re: Actix project postmortem

#287
post #96

Earlier quoted context omitted.

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".

Re: Actix project postmortem

#288
post #154

Earlier quoted context omitted.

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.

Re: Actix project postmortem

#289

Earlier quoted context omitted.

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.

Re: Actix project postmortem

#290

Earlier quoted context omitted.

> 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 w…

> 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.
Post reply on HN