Through pushing through user antagonistic changes completely at odds with users wants and hoping people are pliable enough to forget all about trying to be screwed so you can bide time until the next at attempt to screw users?
Well, that’s the vibe I’m getting from you. I naively assumed open source was based on trust, shared effort and contributions to benefit users so they can install software on their machine that they know is reliable/trustworthy and privacy focussed because anyone can scrutinise it. Silly me.
Ideally we would have something that’s more dehierarchized, but until someone figures out how to do that, all open source repositories have a group of maintainers (or some other name for those who have commit access) who need to (individually) approve of contributions. As it stands, open source is indeed shared effort, but shared effort that has to be approved by a member of a cabal. There’s a reason stewards are often called https://en.wikipedia.org/wiki/Benevolent_dictator_for_life (which is indeed a slightly different concept, but hopefully you get my point that chief maintainers have lasting influence and power).
It’s still much better than other levels (i.e. proprietary). When maintainers slog behind community PRs and wishes for too long and/or persistently screw them up, a critical mass of users leaving will build for alternatives created, accelerated by the fact that most of your project’s users are going to be enthusiasts accustomed to switching and upholding open source principles.
In summary, yes, maintainers make decisions to make users (or some shared vision) happy and are supposed to backtrack when enough of the users object. This is true whether the change is antagonistic or not. What you said in your first paragraph is the opposite of that. (I guess my initial question was what do you think should be the reason to backtrack other than users aren’t happy. “Users are hurt” is the same thing as “Users aren’t happy”.)
As for Audacity? It’s been four years with no attempts, so Tenacity doesn’t look like it’s going to pick up momentum. Until the next incident, Users won’t believe they’re being screwed (and I agree with them) and aren’t building that critical mass. (I also object that the opt-in telemetry PR was antagonistic.)
They tried to add in opt out telemetry in. A few forks were created as a result.
it was never opt-out, it was always planned to be opt-in
I think originally it was the other way and many distros use a compiler flag to stop it being opt out.
the code was never even merged; that’s definitely not true
So they raised a PR with the intention to do this?
Are you saying the only reason they backtracked is because users weren’t happy?
How do you think open-source development works?
Through pushing through user antagonistic changes completely at odds with users wants and hoping people are pliable enough to forget all about trying to be screwed so you can bide time until the next at attempt to screw users?
Well, that’s the vibe I’m getting from you. I naively assumed open source was based on trust, shared effort and contributions to benefit users so they can install software on their machine that they know is reliable/trustworthy and privacy focussed because anyone can scrutinise it. Silly me.
Ideally we would have something that’s more dehierarchized, but until someone figures out how to do that, all open source repositories have a group of maintainers (or some other name for those who have commit access) who need to (individually) approve of contributions. As it stands, open source is indeed shared effort, but shared effort that has to be approved by a member of a cabal. There’s a reason stewards are often called https://en.wikipedia.org/wiki/Benevolent_dictator_for_life (which is indeed a slightly different concept, but hopefully you get my point that chief maintainers have lasting influence and power).
It’s still much better than other levels (i.e. proprietary). When maintainers slog behind community PRs and wishes for too long and/or persistently screw them up, a critical mass of users leaving will build for alternatives created, accelerated by the fact that most of your project’s users are going to be enthusiasts accustomed to switching and upholding open source principles.
In summary, yes, maintainers make decisions to make users (or some shared vision) happy and are supposed to backtrack when enough of the users object. This is true whether the change is antagonistic or not. What you said in your first paragraph is the opposite of that. (I guess my initial question was what do you think should be the reason to backtrack other than users aren’t happy. “Users are hurt” is the same thing as “Users aren’t happy”.)
As for Audacity? It’s been four years with no attempts, so Tenacity doesn’t look like it’s going to pick up momentum. Until the next incident, Users won’t believe they’re being screwed (and I agree with them) and aren’t building that critical mass. (I also object that the opt-in telemetry PR was antagonistic.)