[deleted]
A Sad Day for Rust
631–640 of 1001 posts
Re: A Sad Day for Rust
#632Earlier quoted context omitted.
Why is the maintainer responsible for that? They're just another dev who wrote something that became popular. It's almost like watching lottery winners having their lives ruined.
> Why is the maintainer responsible for that? It just seems to me that there's a give-and-take to being the maintainer of a popular open source project. You get help on the project in the form of people contributing patches, right? Doesn't simple human curtesy and a modicum of wisdom suggest that you should explain your rationale in accepting or rejecting them, to manage expectations, so that it doesn't end up like t…
> You get help on the project in the form of people contributing patches, right?
Any open source maintainer will tell you that many PRs, even well-intentioned ones, end up being a net negative. Often they don't further the maintainers aims, they need detailed review, take sometimes a lot of effort to manage the communication tactfully, etc.
Yes, many PRs are a win and it can be really gratifying seeing your project become bigger and better than you could have made on its own.
But also, many PRs are just a chore and a hassle.
Re: A Sad Day for Rust
#633Earlier quoted context omitted.
> if you write one, advertise one, you need to care about security The word "need" there is wrong. You could (and perhaps should) take the opinion that one should care about security, but there is no obligation (legal, financial, or moral) that requires an open source maintainer to care about anything. If you want those obligations, get a contract and pay some money. What's happened here, and you seem to have fallen…
> You could (and perhaps should) take the opinion that one should care about security, but there is no obligation (legal, financial, or moral) that requires an open source maintainer to care about anything. I was taught that part of being an engineer taking a moral responsibility for the safety of your creations. I know that the field has changed quite a bit, and that people in open source come from many different ba…
I don't think these are contradictory positions. It's a bit like defensive programming in social space: one can take significant responsibility for one's own work while remaining aware that others with no legal/etc compulsion to likely will not.
Re: A Sad Day for Rust
#634Earlier quoted context omitted.
You might not believe this, but I agree with you! Doing something to the best of your ability includes the right to be able to suck at it also. I am pressing for absolutely no standard of quality, yet you somehow think that's the case. It's not. I just think that if you're going to call yourself a maintainer of something, then you better at least pretend.
I disagree. I really think doing an intentionally crappy job is acceptable. Not even pretend. I think it is okay to really half-arse it. Or break it. Or be lazy. Or whatever. Except maybe intentionally harm someone.
Intentionally doing a crappy job is harmful.
And if you're intentionally doing any of the things you listed above, then you're not a maintainer. That simply is not what maintaining means.
Re: A Sad Day for Rust
#635I want to add two (maybe very) controversial comments. 1). It should be considered RUDE to contact a solo maintainer in any way relating to the project (email, issue, pull request, etc.). You should ALWAYS fork the project and use the forked project on your own terms. Most people write their projects, on a whim, on a Saturday, for a bit of fun. They do not want to be shackled to a hobby for the rest of their lives. 2…
A maintainer that you can't reach out to is no maintainer at all. If that's the behavior they expect from others, they should clearly state that the project is not being maintained, and be open to others taking up that effort instead.
Re: A Sad Day for Rust
#636A 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…
That's good advice on how to treat others-- don't act entitled toward open source maintainers. Thank them for their work.
But what exactly are the responsibilities of a maintainer? How far should you go to fix bugs? How thorough should you be about your code's limitations?
If you're doing a project just for fun, should you discourage others from using it in production?
Re: A Sad Day for Rust
#637Earlier quoted context omitted.
Meta-comment: Thank you. Online discussion would be much more productive if everyone clearly laid out the principles on which their viewpoint was based. Fundamentally, there are only a few ways honest people can disagree: Different principles, different information, different interpretation, or just plain misunderstanding. (Meta-meta: This is the principle that I believe and based this comment on.) Much of what makes…
In addition to the (great) framework you listed, there is another big factor - incentives. You may be aligned in principles, have the same info etc. but if your incentives are misaligned it can be hard to agree.
Surely a disagreement based on incentives is not an honest disagreement?
Re: A Sad Day for Rust
#638I remember when people were claiming Common Lisp community is toxic, but I find that it is the languages which tend to focus on "building community" with Community Managers and Codes of Conduct that end up becoming truly toxic cesspools in the end. See also node.js. The focus on community attracts people who aren't interested in programming, but rather those who want a playground for gaining clout and trolling. You n…
If the community is openly acerbic, toxic, autocratic, etc it sometimes becomes less of an issue because you know exactly what to expect, and expectation management is important for people.
If I in the past would have felt I needed to send a patch to the lkml, I wouldn't have felt intimidated because if my code would've gotten shredded to pieces, I was in very good company. The lkml also didn't really brigade, or bully, even if people sometimes was quite emotional. However, for some people I'm sure it would be hell.
There are however several projects with extensive guidelines that I would feel intimidated to interact with, as the power struggles and infighting is likely to be well and alive although I can't see it, there's also a brigade of attackers available to anyone who manage to convince them I was in the wrong.
Community guidelines unless expertly written and religiously enforced are unproportionally useful for those with either a manipulative streak, or those with good social and language skills, as they often grant them more power. In this respect mirroring society. However, apart from keeping the most blatant misconduct out of the open, it also becomes a weapon to be used against anyone less adept at navigating the social hierarchy. Thus, the extent to wherever a particular community ends up, in reality becomes almost inscrutable to the casual observer.
For me it's the same in real life, in contexts where the societal norms are somewhat displaced I have few issues. The selfish, aggressive, and other bad actors stand out like they would wear neon colors. In society in general, in the workplace, I have all kinds of issues because amid all the unspoken rules there will always be one that can be sufficiently well misapplied to defuse valid criticism.
We don't get pathological liars voted into various offices because people are good at arguing rationally, but they also tend get to stay there because they are protected by the rules, unless the rules are expertly and independently applied.
Re: A Sad Day for Rust
#639Earlier quoted context omitted.
The above was from personal experience and observation from having been a part of many online communities -- pre-dating reddit -- in all ways including: here-and-there member, first-hand maintainer and manager, and antisocial member causing a ruckus. Armchair psychology? No, I've made many friends and acquaintances, both online and in real life. The ones that bubble around posting online heavily, have developed antis…
that is armchair psychology.
[deleted]
Re: A Sad Day for Rust
#640Question: why didn’t the more safety-focused developers just fork the project? I feel like fork-o-phobia causes 90% of the incidents like this.
Forking the code is "easy" (OK, maybe not based on the other comments), but anyway... Another (persistent) problem has been the crates.io namespace. You can fork actix, but then you'll need to come up with a new name for it, and then educate the wider community of that. It is a big hassle, and slows adoption. Adding onto the issue is that crates.io does not (yet) support the username/projectname naming scheme as on g…
I don't see that as a major problem in this situation.
Given that the actix author already wanted to take a step back after the last incident, and also seems to be generally okay with giving the project away, a fork could also be officially advertised.
Word also travels fast in communities, and if a viable fork does come up, people will quickly start to recommend it.