A Sad Day for Rust • Hacker News Board

Re: A Sad Day for Rust

#501

Post by 333c » Fri, Jan 17, 2020, 5:50 PM UTC

ernie24 wrote: post #438

I think Github (and other services that host OS software) needs something like "thank you box", that's just alongside Issues. Even if I am not able to contribute to some project I use and like (mostly because I don't have enough technical knowledge yet) very often I would like to - at least - say how much grateful I am for what this person is doing. There is some need for positive energy or gratitude, as we - who are…

GitHub has a donation feature, which is up to the maintainer to enable for their project. Otherwise, it seems to me that a stream of positive comments would get old quickly.

Re: A Sad Day for Rust

#502

Post by thrower123 » Fri, Jan 17, 2020, 5:51 PM UTC

bpfrh wrote: post #124

ddevault wrote: post #38

A lot of this thread has it wrong, and this wrongness contributes to the problem which led to this. I have two simple mantras which establish my philosophy here: 1. YOU are responsible for your dependencies. 2. Open source participants are volunteers and owe you nothing. It was never Nikolay's job to vet actix-web for you, nor did it become his job when the library became popular, nor does invoking "security" change…

The article was not about that, this is not about vetting anything. The problem was that PRs which would have fixed security issues where not accpeted. Do I expected perfect code from maintainers or a answer the next day? No, never Do I think maintainers/creators should merge prs in a timely manner, or ask for help if it get's too much? Yes, otherwise you have multiple forks and the project is not usable anymore.

What is "a timely manner"?

When I signed up for a GitHub account, I don't recall anything about having to agree to an SLA.

I've seen many small projects that I use or monitor where someone will raise an issue or make a PR, and the owner will respond along the lines of "Great, looking into it, but I'm kind of busy right now, will get to it when I have time," and then people going off on them if "when I have time" isn't right now. Usually this is followed by an offer from the owner to give the reporter access or pass the ownership to them, which is invariably followed by crickets.

There has been a lot of talk in this thread about the obligations of project owners. This seems to boil down to fundamental philosophical differences. My view is that if you want people to do shit work and jump when you say frog, you have to pay them for it, rather than bully them.

Re: A Sad Day for Rust

#503

Post by kllrnohj » Fri, Jan 17, 2020, 5:51 PM UTC

BowBun wrote: post #343

dbcfd wrote: post #302

Earlier quoted context omitted.

> 1. YOU are responsible for your dependencies. They not only created issues, they also created patches. That is taking responsibility. They were contributing time and expertise back. Having a project maintainer then call those patches boring or otherwise disregard them? That's childish. He showed time and time again he would respond without civility when an issue was demonstrated in his code. Sadly, that led to some…

> Having a project maintainer then call those patches boring or otherwise disregard them? That's childish So what? Along the same lines, it's not a maintainer's responsibility to follow best-practices, respond to feedback/PRs, or respond in any coherent way to anything asked of them. The fact that you call them childish for not acting they way you want them to makes me think you are the childish one. With those PRs w…

> it's not a maintainer's responsibility to follow best-practices, respond to feedback/PRs, or respond in any coherent way to anything asked of them.

It is when they setup an open source project that has that appearance and is framed as being such a project.

It is entirely the maintainer's responsibility to establish the type of open source project it is. If it was just a toy hobby project and that's all it was meant to be then it should have been framed as such (such as by being in a personal repo for starters). This project promoted itself for production usage, requested feedback & patches on its project page, and had a github setup that gave an appearance of being, for lack of a better word, professional. That's entirely the fault of the maintainer. They set all that up. They established the expectations of the project.

None of that at all forgives the name calling & mud slinging they were subject to, of course. Two wrongs don't make a right. But the maintainer was still also "in the wrong" here. They needed to hand off the project much sooner than they did when they realized they were not at all prepared or ready to handle what they promoted the project as being.

Re: A Sad Day for Rust

#504

Post by juped » Fri, Jan 17, 2020, 5:51 PM UTC

ddevault wrote: post #38

A lot of this thread has it wrong, and this wrongness contributes to the problem which led to this. I have two simple mantras which establish my philosophy here: 1. YOU are responsible for your dependencies. 2. Open source participants are volunteers and owe you nothing. It was never Nikolay's job to vet actix-web for you, nor did it become his job when the library became popular, nor does invoking "security" change…

I would add one more: your patch isn't good just because it exists. Maintainers should, in general, refuse more patches, or they're not really maintaining anything, just overseeing a disaster.

Re: A Sad Day for Rust

#505

Post by enumjorge » Fri, Jan 17, 2020, 5:51 PM UTC

Ygg2 wrote: post #342

ddevault wrote: post #83

Earlier quoted context omitted.

>the community is extremely validated in saying "Hey this library in a language that professes security isn't secure and the maintainer doesn't seem to care" Yes, but that's not what they said. They were hateful and virtrolous, which is never appropriate. Fork it and fix the problems, create a new library which has the same API but is more sound, promote an alternative library in its place, offer to lend a hand in ma…

> They were hateful and virtrolous Who's they? Most of PR commenters were courteous. The last few were rude, but so was the fafhrd91. https://gist.github.com/mafrasi2/debed733781db4aba2a52620b67...

The parent comment still stands. Whether the maintainer was in the right or in the wrong, whether they were being a jerk or not, if he wasn’t listening to the community why not just fork the code? GitHub’s UI makes that super easy.

Re: A Sad Day for Rust

#506

Post by [deleted] » Fri, Jan 17, 2020, 5:51 PM UTC

BowBun wrote: post #343

dbcfd wrote: post #302

Earlier quoted context omitted.

> 1. YOU are responsible for your dependencies. They not only created issues, they also created patches. That is taking responsibility. They were contributing time and expertise back. Having a project maintainer then call those patches boring or otherwise disregard them? That's childish. He showed time and time again he would respond without civility when an issue was demonstrated in his code. Sadly, that led to some…

> Having a project maintainer then call those patches boring or otherwise disregard them? That's childish So what? Along the same lines, it's not a maintainer's responsibility to follow best-practices, respond to feedback/PRs, or respond in any coherent way to anything asked of them. The fact that you call them childish for not acting they way you want them to makes me think you are the childish one. With those PRs w…

[deleted]

Re: A Sad Day for Rust

#507

Post by zzzcpan » Fri, Jan 17, 2020, 5:52 PM UTC

logophobia wrote: post #475

BowBun wrote: post #343

Earlier quoted context omitted.

> Having a project maintainer then call those patches boring or otherwise disregard them? That's childish So what? Along the same lines, it's not a maintainer's responsibility to follow best-practices, respond to feedback/PRs, or respond in any coherent way to anything asked of them. The fact that you call them childish for not acting they way you want them to makes me think you are the childish one. With those PRs w…

It was advertised as a production-ready web-framework, and it was very popular. When do people get to complain? "Oh, my credit card information was stolen due to memory issues in this web-service, it's fine though, we didn't pay the guy, so we can't blame him.". Web-frameworks are cornerstones for security, and if you write one, advertise one, you need to care about security. Features, code-style, ad-hoc PRs, bug-fix…

Everything you ever used in production is "production-ready". The bar is super low, there is no deception here.

The security thing is particularly interesting here. If you care about security even a little bit, you absolutely cannot rely on a random third party to provide timely updates or at all, especially for free. A lot of software doesn't even provide basic security necessities to the point, where OS packages may have to include such patches themselves, effectively always being forks, never using vanilla upstream code. But this is only if you care about security a bit. If you just install from language package managers into prod, you obviously do not care about security even a little bit.

Re: A Sad Day for Rust

#508

Post by Turing_Machine » Fri, Jan 17, 2020, 5:52 PM UTC

logophobia wrote: post #475

BowBun wrote: post #343

Earlier quoted context omitted.

> Having a project maintainer then call those patches boring or otherwise disregard them? That's childish So what? Along the same lines, it's not a maintainer's responsibility to follow best-practices, respond to feedback/PRs, or respond in any coherent way to anything asked of them. The fact that you call them childish for not acting they way you want them to makes me think you are the childish one. With those PRs w…

It was advertised as a production-ready web-framework, and it was very popular. When do people get to complain? "Oh, my credit card information was stolen due to memory issues in this web-service, it's fine though, we didn't pay the guy, so we can't blame him.". Web-frameworks are cornerstones for security, and if you write one, advertise one, you need to care about security. Features, code-style, ad-hoc PRs, bug-fix…

Holding people legally responsible for bugs in their FOSS code would be a good way to ensure that no FOSS code got written. Ever.

Re: A Sad Day for Rust

#509

Post by juped » Fri, Jan 17, 2020, 5:52 PM UTC

anaphor wrote: post #492

ddevault wrote: post #38

A lot of this thread has it wrong, and this wrongness contributes to the problem which led to this. I have two simple mantras which establish my philosophy here: 1. YOU are responsible for your dependencies. 2. Open source participants are volunteers and owe you nothing. It was never Nikolay's job to vet actix-web for you, nor did it become his job when the library became popular, nor does invoking "security" change…

This is a good reason to use Github only as a read-only mirror and just do all development elsewhere. That way you don't have to deal with drive-by issues / PRs from people who just want to complain or won't put in follow up effort.

Why even have the read-only mirror?

Re: A Sad Day for Rust

#510

Post by kungtotte » Fri, Jan 17, 2020, 5:52 PM UTC

jasondclinton wrote: post #456

ddevault wrote: post #83

Earlier quoted context omitted.

>the community is extremely validated in saying "Hey this library in a language that professes security isn't secure and the maintainer doesn't seem to care" Yes, but that's not what they said. They were hateful and virtrolous, which is never appropriate. Fork it and fix the problems, create a new library which has the same API but is more sound, promote an alternative library in its place, offer to lend a hand in ma…

You're lumping a few bad apples (apparently recruited from Reddit) in with "they". The users who found the bugs and provided patches were largely courteous considering the circumstances.

Steve Klabnik makes this point in his write-up, but I'm restating it here for clarity. You don't get to cherrypick who is part of your community or not when these situations arise.

Those "bad apples" are part of the Rust community, and the Rust community needs to take responsibility for them the same way any community needs to take responsibility for their bad apples even if it's just to denounce their behaviour.

Good thing that those who submitted the patches and PRs were polite; they're not the ones who caused this maintainer to quit though I'd wager...