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…
Agreed. I think there is quite a lot of entitlement on the internet and as Klabnik pointed out: on reddit. And while it's definitely a maintainer's responsibility to make their code serve the interest of its users to the best of their ability, fundamental disagreement should result in forks, not vitriol. It's moments like this that I reflect on the past and the public and virtual forums I have participated in... and…
A Sad Day for Rust
271–280 of 1001 posts
Re: A Sad Day for Rust
#272I understand maintaining open source is a lot of work and why someone might want to call it a day - but this is probably the least professional way someone could do it. People depend on this software. It is inconsiderate to just move it to private instead of taking the time to hand it off to someone else. I'm 80% through building an API using actix-web. Time to reassess whether or not I should start over - wonder wha…
You don't get to invoke professionalism, or lack thereof in regards to some individuals work they've made available for free. Open source gives you access to source code to do with as you please. Storing your own copy is a good idea if it's something critical to your endeavors. The possibility of having to maintain anything of that nature yourself is always a risk. Expecting, demanding, or begging for anything except…
I used to lead a volunteer organization. I had many people depending on me for what I provided. Eventually, it became too much and I needed to step down.
A) I could have just left, let the organization collapse on itself, burnt every individual, organization and volunteer that depended on me - and just said, "doesn't matter was a volunteer organization."
B) I could have taken the time to ensure that there is a system in place such that the organization stays afloat, supporting the individuals, organizations, volunteers that are dependent upon it while it finds a new leader.
Either of those choices were mine to make - but I wouldn't be surprised at all if someone called me unprofessional if had picked A.
Re: A Sad Day for Rust
#273Earlier quoted context omitted.
> 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…
And this is why I honestly don't ever want to release an open-source project. At the very least, I'm not going to make it easy for people to contribute. I'll keep the git repo private, go without a ticketing system, and just post tarballs full of code on a self-hosted website (I guess like the NetHack team used to do before 3.6, but they had a ticketing system, and I wouldn't). Maybe I'll even use a non-free license…
Re: A Sad Day for Rust
#274A 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…
1. Just because a thing exists, does not give you the absolute moral right to criticize it, especially in a way that is toxic for the person or persons that created it.
Criticism affects both the people criticized and the community/universe at large, and not always in positive, productive ways.
2. Just because a thing is free, does not grant the thing or its creator absolute immunity from criticism.
Things that exist have an impact on communities or the universe in general, and people are going to be affected. And not always in positive, productive ways.
1 and 2 can both be true, and I think they are both true.
There is a judgment call involved as to when criticism is unfounded, unproductive, a distraction, and/or outright toxic, just as there is a judgement call involved as to when a thing’s existence in its current form is a net negative.
You are not wrong about user entitlement being a problem, as noted by #1, and you are not wrong in a commercial sense about maintainers not owing any one person anything.
But as per #2, I do not believe that is an absolute blanket injunction to never have an opinion about their choices or about the net positive or negative effect of the existence of the thing they maintain in its current form.
Re: A Sad Day for Rust
#275Re: A Sad Day for Rust
#276Earlier quoted context omitted.
Of course you can criticize, but people are continuously demanding things, like "he should have labeled it as a toy project", "he should have given reasons why he didn't accept the patch", etc. And Drew is very right to say: No, he didn't have to do any of that.
You know, there is a lot of "He isn't required" but I will say there are reasonable expectations that people have when a project gets to a certain level of exposure/downloads/etc. and while someone should not be "cancelled" or tarred and feathered for not accepting a merge request, if your project is a leader in its niche (Rust web frameworks) you should do better. You publish your code to Github, you're part of a co…
Maybe. The main issue I see with github is that it's impossible to disable pull requests there. We have that issue in the coreboot project, which uses github as a read-only mirror.
Maybe we should just shut that down to make clear that coreboot is not part of the "GitHub community".
Re: A Sad Day for Rust
#277> Can we reject the idea of a BDFL? Can we include as many people as possible? Can we be welcoming to folks who historically have not had great representation in open source? Can we reject contempt culture? Can we be inclusive of beginners? I feel like in any language, beginners are more than encourage to write things in said language. Yet when working on language internals, you need to be more careful. Reading the F…
That was not a CEO but a founder, AIUI. Can't really fire them or ask them to step down, they literally own the place.
Re: A Sad Day for Rust
#278A 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 an understatement.
I work in regulated environments where a software error has consequences. Dependencies must be vetted. If we end up relying on a dependency with known vulnerabilities the auditors are going to want to know what we did to mitigate the risk of this out-come. You need to have an answer for that question.
I recommend packaging your upstream dependencies. That way you can patch vulnerabilities you find and ship those fixes today before those patches make it up stream. That's a risk mitigation strategy and often good enough to fend off auditors.
Many (all?) open source licenses provide the software without any warranty or guarantee of merchantability or fitness for use. None. At all.
Re: A Sad Day for Rust
#279That's okay, Rust should never be used for web anyway. I don't like the idea of Rust, C, C++, or Assembly for directly web-facing services. Any non-GC language should be a non-starter. There are literally (uncountably?) infinite ways you can have memory errors in a native program. The consequences of any of these can be devastating because absolutely anyone can access your endpoint. Notice the asymmetry: One small, u…
Re: A Sad Day for Rust
#280Earlier quoted context omitted.
The community's response might be valid if it were limited to that. But, quoting TFA, they went beyond that. "It’s extra nasty this time. Some people go far, far, far over the line." When someone polite says this, I picture some of the nastier attacks on the internet - doxxing, death threats, and swatting.
In this case it meant people saying things like "you are bad and you should stop writing rust, forever" possibly with some more colorful words in there. Very hurtful things but at least not threats and actions...