42 ms·

> That came over to me as "you are obliged to do a lot more work that I want you to do, on your own time and personal cost, and to stop developing the project a

> That came over to me as "you are obliged to do a lot more work that I want you to do, on your own time and personal cost, and to stop developing the project according to your own vision or you are a bad person". But he didn't ask for work to be done anywhere in the article? He asks that he not be prevented from writing code that the compiler supports, but which is arbitrarily limited to members of certain organizations. That's not asking for work. I feel like if you make it so that users of your platform cannot do certain work for themselves, and instead must await you doing the work, you are basically creating the entitlement. You now owe it to them, in some sense, to do the work, since you have intentionally blocked them from doing it themselves. I mean, it's open source. You have no contract with the maintainers and so there is no real entitlement to any specific behavior. Hell they could have the compiler try to detect whether you're someone who engages in wrongthink and refuse to work for you if so, and you'd have no legal right to complain. On the other hand, it's plain that there is a certain slice of the population who doesn't prefer this paternalistic approach to software tools. If the Evans of the world wish to remain atop their ivory tower, then they will be the recipients of an incrementally higher frequency of rage-quit posts as a result. Should doesn't enter into it. That's just how it is. Personally my advice is if you're not into opinionated BDFLs blocking you from doing things for non-technical reasons, don't use ecosystems controlled by BDFLs who have a habit of doing this. So, I won't be using Elm, and that's probably for the best both for me and the Elm core maintainers.

jlokier 7y ago
> But he didn't ask for work to be done anywhere in the article? He asks that he not be prevented from writing code that the compiler supports, but which is arbitrarily limited to members of certain organizations. That's not asking for work. But that is asking for work! That's a great example of "why don't you just... $TRIVIAL" where $TRIVIAL = "turn off the restrictions", as if there is no consequent problem for the upstream author to have to figure out how to achieve the design goals of the project afterwards, or manage the explosion in issues with modules that may potentially emerge, or who knows which other concerns (I'm just throwing out some guesses; don't take them seriously.) It's a great example of what Evan describes in the video, of a seemingly trivial request whose potential complex consequences are not seen by the requestor, but are seen and must be dealt with by others; and of conflicting priorities. Essentially it is a request to the author: "I ask that you spend time to revise your design to figure out how to allow my module's techniques to keep working at the same time as achieving the design goals of Elm going forward, and reverse your design decision that you have already made". > I feel like if you make it so that users of your platform cannot do certain work for themselves, and instead must await you doing the work, you are basically creating the entitlement. You now owe it to them, in some sense, to do the work, since you have intentionally blocked them from doing it themselves. You have not blocked them. As many commenters have pointed out, you don't have to wait, you can fork. You can fork quietly if you don't want social issues from making a big noise, as vast numbers of developers do with a vast numbers of projects. If the upstream author is not making it easy for the downstream module author, perhaps requiring the downstream author to maintain a patched version of the compiler and persuade other people to use the patch, tough. There's isn't and shouldn't be any moral obligation on the upstream to screw their design goals to accomodate that particular downstream author. I've had to maintain patched Linux kernels for a project. I didn't resent Linux upstream for that. I didn't complain that I needed to patch the kernel. It was just part of the cost of doing my project. It limited what I could expect to do, but I went into it informed of what to expect. > it's plain that there is a certain slice of the population who doesn't prefer this paternalistic approach to software tools. I agree. It's more than prefer for some. A certain slice almost demands it and makes life hard for any author who does not provide. For which the word is "entitlement". Unfortunately that slice has a subslice who wants something self-cancelling: A non-paternalistic project that talks with them at length patiently, accomodates most requests no matter how varied and contradictory, yet still produces a coherency of design, magic-sauce artefact for them, preferably on a regular release cycle with QA, with nobody's time and personal needs covered. In other words, what they want isn't always feasible, yet they still demand it from individuals (often via emotional pressure), rather than start their own projects. > Personally my advice is if you're not into opinionated BDFLs blocking you from doing things for non-technical reasons, don't use ecosystems controlled by BDFLs I agree wholeheartedly. And that's the advice given to Luke by an Elm developer in 2018! :- https://github.com/gdotdesign/elm-github-install/issues/62#issuecomment-415860947 https://github.com/gdotdesign/elm-github-install/issues/62#i... Sounds like Luke chose to ignore the advice, then was angry 1.5 years later. I think it can be argued that the person ignoring the advice is the one who creates the later problem for themselves. > If the Evans of the world wish to remain atop their ivory tower, then they will be the recipients of an incrementally higher frequency of rage-quit posts as a result. Should doesn't enter into it. That's just how it is. I think that comes under excusing abuse by saying it's inevitable that someone will do it. Public rage-posts about someone's work are still abuse if the basic problem is that the other person didn't do what you wanted them to. What we should have, in a "good" world, is that people like Evan should be able to produce their projects in relative peace without abuse. If people don't like the project, in the "good" world people know what to expect and are free to start their own alternative. I think the Evans of the world lose in our current world, no matter what they do. If they are less paternalistic, they will have both an ever-increasing workload until they step down, and the project will not fulfil their design wishes so it's much less rewarding.
- lozenge 7y ago
  In Linux, if you are in userspace or are merged into the kernel tree, they won't break you. Otherwise, you can write your code but kernel upgrades can break your code. In Elm, it's the same but only a select few can get merged in. The rest get told to rewrite into "userspace" (pure Elm) and find their posts deleted or locked and are accused of being "hostile to Elm's goals". Oh, and you have to patch the kernel before it will load your modules, as it downloads from an official website and checks the Publisher field.
- asdfasgasdgasdg 7y ago
  > I think that comes under excusing abuse by saying it's inevitable that someone will do it. Sorry, a former user talking respectfully about the shortcomings of your software project is not "abuse." However, I do agree with the general thrust Of your comment that it was unwise for Luke to continue to use Elm. For all the reasons he outlines in his post, there are many similarly situated developers who would also do well to avoid it. Luke's post is a public service to let people know that the situation in the Elm project is not very healthy if your needs don't match exactly those envisioned by the core maintainer group.
  - jlokier 7y ago
    > Sorry, a former user talking respectfully about the shortcomings of your software project is not "abuse." I do not agree that Luke's article fits that description. Luke's post talks not only about the software project, but also about Evan personally. It's not direct but that doesn't matter. (You cannot make something respectful just by phrasing it indirectly.) He moralises and talks about Evan personally, by implying strongly that Evan does not live up to obligations that Luke has decided Evan has to others, with the additional twist that it doesn't matter if that implies a free-labour obligation. That was avoidable. Luke could have framed his discussion about how Elm is not suitable to his needs and why others should be aware, in an actually respectful way that did not frame it as a set of obligations Evan was failing to satisfy. But he did not. Talking about obligations is not always disrespectful, but in this case I think it was. If you have been on the receiving end of that sort of thing in a public situation, you may or may not have experienced that it can entrain a mass of many people's responses to an overwhelmingly stressful degree, depending on how people collectively respond to it. People who write such things may not care about that, but these days they have no excuse for being unaware of the possibility. (I don't want to devalue the word "abuse" by overusing it; and for example I wouldn't vote to remove someone from a group I ran for what was written this time, but if it kept happening over and over then eventually I would because I have seen what can happen if action is never taken).

jlokier 7y ago

> But he didn't ask for work to be done anywhere in the article? He asks that he not be prevented from writing code that the compiler supports, but which is arbitrarily limited to members of certain organizations. That's not asking for work. But that is asking for work! That's a great example of "why don't you just... $TRIVIAL" where $TRIVIAL = "turn off the restrictions", as if there is no consequent problem for the upstream author to have to figure out how to achieve the design goals of the project afterwards, or manage the explosion in issues with modules that may potentially emerge, or who knows which other concerns (I'm just throwing out some guesses; don't take them seriously.) It's a great example of what Evan describes in the video, of a seemingly trivial request whose potential complex consequences are not seen by the requestor, but are seen and must be dealt with by others; and of conflicting priorities. Essentially it is a request to the author: "I ask that you spend time to revise your design to figure out how to allow my module's techniques to keep working at the same time as achieving the design goals of Elm going forward, and reverse your design decision that you have already made". > I feel like if you make it so that users of your platform cannot do certain work for themselves, and instead must await you doing the work, you are basically creating the entitlement. You now owe it to them, in some sense, to do the work, since you have intentionally blocked them from doing it themselves. You have not blocked them. As many commenters have pointed out, you don't have to wait, you can fork. You can fork quietly if you don't want social issues from making a big noise, as vast numbers of developers do with a vast numbers of projects. If the upstream author is not making it easy for the downstream module author, perhaps requiring the downstream author to maintain a patched version of the compiler and persuade other people to use the patch, tough. There's isn't and shouldn't be any moral obligation on the upstream to screw their design goals to accomodate that particular downstream author. I've had to maintain patched Linux kernels for a project. I didn't resent Linux upstream for that. I didn't complain that I needed to patch the kernel. It was just part of the cost of doing my project. It limited what I could expect to do, but I went into it informed of what to expect. > it's plain that there is a certain slice of the population who doesn't prefer this paternalistic approach to software tools. I agree. It's more than prefer for some. A certain slice almost demands it and makes life hard for any author who does not provide. For which the word is "entitlement". Unfortunately that slice has a subslice who wants something self-cancelling: A non-paternalistic project that talks with them at length patiently, accomodates most requests no matter how varied and contradictory, yet still produces a coherency of design, magic-sauce artefact for them, preferably on a regular release cycle with QA, with nobody's time and personal needs covered. In other words, what they want isn't always feasible, yet they still demand it from individuals (often via emotional pressure), rather than start their own projects. > Personally my advice is if you're not into opinionated BDFLs blocking you from doing things for non-technical reasons, don't use ecosystems controlled by BDFLs I agree wholeheartedly. And that's the advice given to Luke by an Elm developer in 2018! :- https://github.com/gdotdesign/elm-github-install/issues/62#issuecomment-415860947 https://github.com/gdotdesign/elm-github-install/issues/62#i... Sounds like Luke chose to ignore the advice, then was angry 1.5 years later. I think it can be argued that the person ignoring the advice is the one who creates the later problem for themselves. > If the Evans of the world wish to remain atop their ivory tower, then they will be the recipients of an incrementally higher frequency of rage-quit posts as a result. Should doesn't enter into it. That's just how it is. I think that comes under excusing abuse by saying it's inevitable that someone will do it. Public rage-posts about someone's work are still abuse if the basic problem is that the other person didn't do what you wanted them to. What we should have, in a "good" world, is that people like Evan should be able to produce their projects in relative peace without abuse. If people don't like the project, in the "good" world people know what to expect and are free to start their own alternative. I think the Evans of the world lose in our current world, no matter what they do. If they are less paternalistic, they will have both an ever-increasing workload until they step down, and the project will not fulfil their design wishes so it's much less rewarding.

lozenge 7y ago
In Linux, if you are in userspace or are merged into the kernel tree, they won't break you. Otherwise, you can write your code but kernel upgrades can break your code. In Elm, it's the same but only a select few can get merged in. The rest get told to rewrite into "userspace" (pure Elm) and find their posts deleted or locked and are accused of being "hostile to Elm's goals". Oh, and you have to patch the kernel before it will load your modules, as it downloads from an official website and checks the Publisher field.
asdfasgasdgasdg 7y ago
> I think that comes under excusing abuse by saying it's inevitable that someone will do it. Sorry, a former user talking respectfully about the shortcomings of your software project is not "abuse." However, I do agree with the general thrust Of your comment that it was unwise for Luke to continue to use Elm. For all the reasons he outlines in his post, there are many similarly situated developers who would also do well to avoid it. Luke's post is a public service to let people know that the situation in the Elm project is not very healthy if your needs don't match exactly those envisioned by the core maintainer group.
- jlokier 7y ago
  > Sorry, a former user talking respectfully about the shortcomings of your software project is not "abuse." I do not agree that Luke's article fits that description. Luke's post talks not only about the software project, but also about Evan personally. It's not direct but that doesn't matter. (You cannot make something respectful just by phrasing it indirectly.) He moralises and talks about Evan personally, by implying strongly that Evan does not live up to obligations that Luke has decided Evan has to others, with the additional twist that it doesn't matter if that implies a free-labour obligation. That was avoidable. Luke could have framed his discussion about how Elm is not suitable to his needs and why others should be aware, in an actually respectful way that did not frame it as a set of obligations Evan was failing to satisfy. But he did not. Talking about obligations is not always disrespectful, but in this case I think it was. If you have been on the receiving end of that sort of thing in a public situation, you may or may not have experienced that it can entrain a mass of many people's responses to an overwhelmingly stressful degree, depending on how people collectively respond to it. People who write such things may not care about that, but these days they have no excuse for being unaware of the possibility. (I don't want to devalue the word "abuse" by overusing it; and for example I wouldn't vote to remove someone from a group I ran for what was written this time, but if it kept happening over and over then eventually I would because I have seen what can happen if action is never taken).