Earlier quoted context omitted.
If that's the case, then why open source it at all? Just make people pay.
There are many possible reasons, and yes, one is because they might hope it's useful to other people. That's not the same as being "responsible" for such usefulness.
A Sad Day for Rust
691–700 of 1001 posts
Re: A Sad Day for Rust
#692Earlier quoted context omitted.
Forking is extremely aggressive, and just because someone has the time to write a patch doesn't mean they have the desire or time to run a project.
> Forking is extremely aggressive This is not so. If you said "forking can be perceived as an aggressive action"* I would not disagree with you, but in the context of an FOS ecosystem, forking should not be perceived as aggressive, and it definitely is not inherently so. If someone doesn't want anyone to fork their project, why release it under an open source license? Free/Open source, full control: pick one. I objec…
Re: A Sad Day for Rust
#693Earlier 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'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. I mean, I'd say that it is a maintainer's responsibility to do some of these things. If they can't, they should allow another interested&qualified person to be the maintainer instead. I understand that it's their right to abdicate these responsibilities. It's not illega…
You alone decided that maintainers have all these obligations (which I would consider reasonable things to do for the record), but the maintainer of this library doesn't agree, and the license doesn't require it, so you're just setting yourself up for disappointment here.
Re: A Sad Day for Rust
#694Earlier quoted context omitted.
It is absolutely a bad thing to be negative and snarky. It sews resentment within the community and taints potentially valid points. One can express legitimate concerns and be heard without putting oneself on a pedestal or diminishing the self-worth of others. We as a community must take responsibility for fostering a merit-based discourse, and reject pettiness and snark.
What sews resentment is being repeatedly dismissive of serious problems, as we're seeing with this hackish use of 'unsafe' features - that's an attitude that diminishes the self-worth of others, if I ever saw any. If anything, a bit of irony and snark can be helpful in underlining a sharp, pointed critique, while de-escalating the sorts of petty, antagonizing attitudes that we've seen in this case.
No doubt, having to contend with this issue is frustrating for all parties. I think it’s important however to help people feel heard and respected even if we don’t agree with them. One of the burdens as a pillar of the community is the necessity to rise above that frustration (articulating it in an emotionally intelligent manner when necessary) – to focus on educating, and hearing constructive criticism.
That said, candidly it’s not helpful to talk about using snark as a means of being heard. It’s like saying “I’ll put down my weapons after you put down yours”
Let’s not bury the lede here: people are coming to Rust because they see, and are excited by its potential. They are passionate about making the language better. I think we should hear them, search for patience, and disagree without being disagreeable. We will go a LOT further together through collaboration than we can through divisive rhetoric.
Re: A Sad Day for Rust
#695Earlier quoted context omitted.
> It's not like he was getting paid to work on this, was it? That is completely beside the point. Do the Debian maintainers that were responsible for famous security slipups regarding SSH keys got paid? No. Would the backlash if they had been unwilling to fix the issues been warranted? Absolutely. Once you are a part of people's infrastructure and these people rely on you to not be irresponsible, you can't afford to…
Commitment can't be measured. It isn't a quantifiable thing, like dollars.
I originally invented the analogy to make some friends of mine who had a very strong market oriented mindset, understand open source. This was many years ago, when the likes of Microsoft painted open source in the light of anarcho hippie communism. I needed to explain to them that open source is closer to their thinking than some Fortune 500 behemoth that is capitalism on the outside but basically socialism inside.
Re: A Sad Day for Rust
#696Earlier quoted context omitted.
> Open source participants are volunteers and owe you nothing. I can't agree. Not for all participants. Let's take Linus. He's in charge of the Linux project, which thousands (millions?) of people contribute to every day. If Linus suddenly stopped merging any and all patches—but refused to officially step down—what do you think would happen? Oh, the project would more than survive—someone would fork it and that would…
I think you're missing a point. If you promise something, people will get upset if you don't deliver. There were no promises made here. If you want to compare it to your example, it's more like your "primary teacher" would ask you to cover one week after other and after 3 years you'd say you just won't do it anymore - should anybody be upset at you?
And to focus on a different part of the analogy for a moment—if somebody looks more closely at what I'm teaching students, and sees that I'm actually showing them how to use flamethrowers, yeah, they have a right to be upset. Again, it doesn't matter that I'm a volunteer, they've placed a significant degree of trust in me.
People should still audit their dependencies, just like people should observe my teaching. But it's also fair for them to have expectations.
Re: A Sad Day for Rust
#697A 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…
> “ 2. Open source participants are volunteers and owe you nothing.” Absolutely not. They are compensated with prestige, enjoyment, decision-making power, future employment rewards, and sometimes even money, all of which was their choice to pursue through their labor and time spent on the open source project. The users of open-source projects, upon which the projects themselves depend, are also not obligated to anyth…
> enjoyment
Riiight
Re: A Sad Day for Rust
#698Earlier quoted context omitted.
Did the patches obviously maintain the exact same behavior? If so, why should the author care about them? If not, it’s not the author’s responsibility to ensure they’re correct patches, but it is the author’s responsibility to ensure their package is correct. If it was correct already (not sure about this, but it seems it was very popular and used in production, so I imagine it worked well), they have no responsibili…
> I would be very unlikely to accept a patch that simply changed the internal typings for the abstract goal of “fewer any”s. Out of curiosity, isn't a focus on that kind of things precisely the goal of Rust? I understand your point, but this was software built for Rust, which has this kind of thing (safety, the right types, etc) as a primary goal. From https://www.rust-lang.org/ : > "A language empowering everyone to…
Are you kidding? Rust is a tool, not an ideology. You don't have to share in the beliefs of the tools designers to use a tool...
Re: A Sad Day for Rust
#699A 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…
> Open source participants are volunteers and owe you nothing. I can't agree. Not for all participants. Let's take Linus. He's in charge of the Linux project, which thousands (millions?) of people contribute to every day. If Linus suddenly stopped merging any and all patches—but refused to officially step down—what do you think would happen? Oh, the project would more than survive—someone would fork it and that would…
I think what we are running into here is a matter where different groups have different expectations of what is owed and why it is owed, but due to the difficulty of talking about what is owed to others makes it hard for us to verbalize or sometimes even concretely conceptualize what we are talking about. There are also different extents one can owe something (legal being the most extreme, as you will be forced to by the courts with possible violence if you don't).
If a one of the parents tried to get a court to order you to teach the class on penalty of contempt of course, would you find that reasonable? This sounds quite extreme, but there are plenty of cases of owing someone something that the court does enforce in a similar manner. My guess is that you would find such an reaction unreasonable to an outrageous degree, but would find far less extreme enforcement measures (such as being disappointed) as being reasonable. I would even go a bit off topic and say that this level of being owed is proportional to the payment you receive. As a volunteer you likely get no money, but are still 'paid' in social recognition.
So you can owe something on the level of being disappointed, but not on the level of court order. So what level does a project maintainer owe others and why. And what do those others owe them in return?
Re: A Sad Day for Rust
#700Earlier quoted context omitted.
> 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…
Read the license, it frames the project exactly.