11 ms·

Your suggestion for the problems with this project is "Why don't you just fork it and maintain your own?"

kazinator 6y ago
That's right[1]; and the author of "Why I'm leaving Elm" understands this, yet claims that it's not possible somehow because the Elm people are hostile to it, and that's one of the reasons the project supposedly isn't really "open source". Something seems a bit off in the reasoning. The only reason you can't fork something is that either you don't have all the code, or there is a license problem. One way not to have all the code is that there is a dependency on specific SaaS server installation, whose source code isn't available. If that's the case with Elm, I missed the coverage of it in the article somehow. I did get the part that the packaging ecosystem depends on a particular server controlled by the Elm project. 1. Well, not a solution for the project, but for some of its unhappy users. The project, as such, perhaps doesn't even feel that it has these problems that require solving.
- billjings 6y ago
  He doesn't claim it's not possible, he claims that the Elm community will excommunicate you for forking. I can't think of a language or platform that doesn't have some degree of "soft" forking that maintains communion with the language community. It's common for proprietary reasons (linux kernel, anyone?) as well as experimental reasons (e.g. PyPy). So this is an eyebrow raising claim.
  - jlokier 6y ago
    On the face of it, my impression is that excommunication, if it happens, is more likely to be caused by the author being burdensome to deal with, than code forking per se. Of course the author is unlikely to present it that way. And although I felt the author was moralising in this critique, it may be they are not particularly rude the rest of the time. But even writing a plethora of well-reasoned but difficult to handle posts about what's wrong with your project can be too much. Well-established languages, platforms and projects such as Linux that have a large labour pool with socially-established patterns of working don't have the same problem, because there's enough labour to deal with it. Smaller projects just have to turn people away when they become hard work beyond the capacity of the project's core maintainers to handle it, though. The solution found via FLOSS is to license software so that forking is always possible when a project cannot sustain different visions for the project's direction. This diffuses the tension when people have incompatible needs from the project. Sometimes it comes with drama, particularly if people are competing for attention and trying to persuade others to follow them, but that seems inevitable because of the competition. It is still understood that forking is permitted and intended to be part of the solution, and the social niceties are that you may be encouraged, perhaps strongly, to go away and run your own fork yourself with your own resources, under a new name/domain/etc. while acknowleging where it came from. Then it's your own job to build a reputation too; it's only fair. It's very difficult to keep running a project while your competition lingers on the same mailing list, constantly funnelling people towards their fork in the hope of making it more popular. That's a very good reason to "excommunicate" some people, or to forbid some topics such as advertising the other project repeatedly.
    - asdfasgasdgasdg 6y ago
      > Of course the author is unlikely to present it that way. I don't really get this accusation in light of the author leading the article with admissions of their own failings in terms of how they communicated with the maintainers of the project?
      - jlokier 6y ago
        I'm writing in response to this remark, presented in the parent to my comment: > he claims that the Elm community will excommunicate you for forking. If that is correct, what I said is less accusation and more descriptive, and should really say something stronger: "the author hasn't presented it that way." However if the parent to my comment is mistaken, then I agree that would make that sentence in my response unfairly speculative.
        asdfasgasdgasdg 6y ago
        The bit about "excommunication" is very explicitly linked to the author's plan to fork Elm. Now, I don't think "excommunication" is necessarily the correct descriptor. The Elm maintainer who made the threat said that he considered making a fork on "attack" on Elm's goals [1], and that the project would not be greeted with open arms. (Although in the original comment it was a little less clear whether it was the project or the person to whom arms would not be open.) In any case, I think the comment is very clear that the hostility is to the action of forking, irrespective of previous communication problems. [1]: https://github.com/gdotdesign/elm-github-install/issues/62#issuecomment-415860947 https://github.com/gdotdesign/elm-github-install/issues/62#i...
        jlokier 6y ago
        I don't see anything about making a fork in the linked GitHub issue. (The word "fork" appears once elsewhere, in an unrelated context in a different comment.) The thing about open arms is not about forking (or if it is, it's not obvious to me), and reads to me more like "assuming you are not making your own fork, can you please stop pressuring upstream to accomodate designs which are explicitly against our clearly communicated design goals". The quote is: > @spookylukey It's one thing to build tooling around an implementation flaw without knowing the history, but that's all pretty well communicated at this point. > If you understand the design goals, but don't agree with them, why not channel that in a positive way - e.g. by building something that fits your vision instead of directly working against Elm's design goals? > As someone who has spent a lot of time collaborating with many others to help Elm achieve its stated design goals, intentionally working against those goals feels to me like an attack on our efforts. We have been really clear about our design goals in this area, and you shouldn't expect a project that works against those goals to be greeted with open arms—especially not from those of us who have been working hard for years to achieve those goals.
  - whelming_wave 6y ago
    What would they do? I'm not sure there's an actual threat to follow through on. They can't block a forked compiler from, for example, using official packages without close-sourcing their own compiler (to prevent it from bringing in whatever change makes it work again). At that point, why bother respecting the threat? A forked compiler isn't going to get maintainers? A package depending on the forked compiler isn't going to be maintained? The social cost is possibly something to think about, but if one is set on leaving the community anyways then it's a choice between you choosing to not interact with the community and them (possibly!) choosing to not interact with you.
    - dnautics 6y ago
      It's still worth knowing that they're being jerks about it, since that falls outside of the social (but obviously not the legal) aspects of open source.
      - carapace 6y ago
        > falls outside of the social (but obviously not the legal) aspects of open source. Not really, IMO. Forking a project used to be a really aggressive thing to do back before GitHub made it so common among younger waves of developers. If you go to Evan and say, "Look, I want to use your thing but do it my way." and he says "No, I have a clear vision of what the thing is and it's not that. KTHXBYE." I don't think that's "being a jerk".
    - billjings 6y ago
      The community is more valuable than the code, because the community writes the code. So being cut off from the community is a major blow to a fork, and substantially increases their work burden.
      - whelming_wave 6y ago
        Your fork isn't a significant amount of work, unless they've really threaded in the must-be-in-Elm-Kernel check throughout the entire compiler. Versus trying to rewrite your dependency in Elm rather than enabling importing JS, enabling JS is likely to be simpler since the functionality already exists to let Kernel modules do it.
  - deleted 6y ago
    [deleted]
- em-bee 6y ago
  the last thing i want is to get into drama with developers of a project, so if my choices are to give up and leave or fork and face drama, then i'll give up and leave. how that affects the Open Source status of a project is irrelevant, this is simply not a project that i could use, and thus for all intents and purposes, for me at least, it's a project that can't be forked.
  - kazinator 6y ago
    If you fork quietly, you can avoid the drama. Just do your thing and don't respond to anyone (in any forum) who isn't reasonable and civil. Don't start drama, don't feed drama.
    - em-bee 6y ago
      if i am happy to just quietly run my private patched version, sure. but that's not the point, because the claim is that for a good Open Source (or Free Software) project, it must be possible to go public, and once you do that, if the original developers are unsympathetic then drama is unavoidable. there have been hostile forks in projects before, even those that eventually had a good ending. egcs for example. i was part of such a forked project too. it wasn't meant to be hostile, and the drama was limited to the project leaders, but it happened, and feelings got hurt. not everyone is willing to take that risk.
neilwilson 6y ago
That's what forking entails. It's a bit like Brexit. You don't get to stay in the club. If there are sufficient people unhappy with Elm but are cohesive enough to push the compiler forward, then why not?
- macintux 6y ago
  The author’s point is that other languages don’t (typically) kick people out of a club for forking.
  - tzjmetron 6y ago
    Precisely.
- cies 6y ago
  You dont even have to push anything forward. Example Redhat's compilation of code or "forked" by CentOS, who were providing just a little more freedom. We all know how that ended. Just keep in sync with the main project, and keep the annoying/proprietary stuff out. > You don't get to stay in the club. Or you become the club. I think LibreOffice has more club going than Oracle's OOo.
- lmm 6y ago
  The open-source ethos means welcoming the friendly competition that comes from a fork. Look at the grandparent's link for the attitude taken by awk and bash.
- amluto 6y ago
  I’ve never used Elm, but that’s not how reasonable open source projects work. Red Hat maintains several rather divergent forks of Linux and they’re still in the club. I personally run a fork of Linux that I maintain, and I’m in the club. The only people who attract serious ire from the club are people who distribute out-of-tree modules that play poorly with the rest of the system. Even in that case, no one gets excommunicated, but the upstream kernel makes no particular effort to keep problematic modules working.

That's right[1]; and the author of "Why I'm leaving Elm" understands this, yet claims that it's not possible somehow because the Elm people are hostile to it, and that's one of the reasons the project supposedly isn't really "open source". Something seems a bit off in the reasoning. The only reason you can't fork something is that either you don't have all the code, or there is a license problem. One way not to have all the code is that there is a dependency on specific SaaS server installation, whose source code isn't available. If that's the case with Elm, I missed the coverage of it in the article somehow. I did get the part that the packaging ecosystem depends on a particular server controlled by the Elm project. 1. Well, not a solution for the project, but for some of its unhappy users. The project, as such, perhaps doesn't even feel that it has these problems that require solving.

billjings 6y ago
He doesn't claim it's not possible, he claims that the Elm community will excommunicate you for forking. I can't think of a language or platform that doesn't have some degree of "soft" forking that maintains communion with the language community. It's common for proprietary reasons (linux kernel, anyone?) as well as experimental reasons (e.g. PyPy). So this is an eyebrow raising claim.
- jlokier 6y ago
  On the face of it, my impression is that excommunication, if it happens, is more likely to be caused by the author being burdensome to deal with, than code forking per se. Of course the author is unlikely to present it that way. And although I felt the author was moralising in this critique, it may be they are not particularly rude the rest of the time. But even writing a plethora of well-reasoned but difficult to handle posts about what's wrong with your project can be too much. Well-established languages, platforms and projects such as Linux that have a large labour pool with socially-established patterns of working don't have the same problem, because there's enough labour to deal with it. Smaller projects just have to turn people away when they become hard work beyond the capacity of the project's core maintainers to handle it, though. The solution found via FLOSS is to license software so that forking is always possible when a project cannot sustain different visions for the project's direction. This diffuses the tension when people have incompatible needs from the project. Sometimes it comes with drama, particularly if people are competing for attention and trying to persuade others to follow them, but that seems inevitable because of the competition. It is still understood that forking is permitted and intended to be part of the solution, and the social niceties are that you may be encouraged, perhaps strongly, to go away and run your own fork yourself with your own resources, under a new name/domain/etc. while acknowleging where it came from. Then it's your own job to build a reputation too; it's only fair. It's very difficult to keep running a project while your competition lingers on the same mailing list, constantly funnelling people towards their fork in the hope of making it more popular. That's a very good reason to "excommunicate" some people, or to forbid some topics such as advertising the other project repeatedly.
  - asdfasgasdgasdg 6y ago
    > Of course the author is unlikely to present it that way. I don't really get this accusation in light of the author leading the article with admissions of their own failings in terms of how they communicated with the maintainers of the project?
    - jlokier 6y ago
      I'm writing in response to this remark, presented in the parent to my comment: > he claims that the Elm community will excommunicate you for forking. If that is correct, what I said is less accusation and more descriptive, and should really say something stronger: "the author hasn't presented it that way." However if the parent to my comment is mistaken, then I agree that would make that sentence in my response unfairly speculative.
      - asdfasgasdgasdg 6y ago
        The bit about "excommunication" is very explicitly linked to the author's plan to fork Elm. Now, I don't think "excommunication" is necessarily the correct descriptor. The Elm maintainer who made the threat said that he considered making a fork on "attack" on Elm's goals [1], and that the project would not be greeted with open arms. (Although in the original comment it was a little less clear whether it was the project or the person to whom arms would not be open.) In any case, I think the comment is very clear that the hostility is to the action of forking, irrespective of previous communication problems. [1]: https://github.com/gdotdesign/elm-github-install/issues/62#issuecomment-415860947 https://github.com/gdotdesign/elm-github-install/issues/62#i...
        jlokier 6y ago
        I don't see anything about making a fork in the linked GitHub issue. (The word "fork" appears once elsewhere, in an unrelated context in a different comment.) The thing about open arms is not about forking (or if it is, it's not obvious to me), and reads to me more like "assuming you are not making your own fork, can you please stop pressuring upstream to accomodate designs which are explicitly against our clearly communicated design goals". The quote is: > @spookylukey It's one thing to build tooling around an implementation flaw without knowing the history, but that's all pretty well communicated at this point. > If you understand the design goals, but don't agree with them, why not channel that in a positive way - e.g. by building something that fits your vision instead of directly working against Elm's design goals? > As someone who has spent a lot of time collaborating with many others to help Elm achieve its stated design goals, intentionally working against those goals feels to me like an attack on our efforts. We have been really clear about our design goals in this area, and you shouldn't expect a project that works against those goals to be greeted with open arms—especially not from those of us who have been working hard for years to achieve those goals.
- whelming_wave 6y ago
  What would they do? I'm not sure there's an actual threat to follow through on. They can't block a forked compiler from, for example, using official packages without close-sourcing their own compiler (to prevent it from bringing in whatever change makes it work again). At that point, why bother respecting the threat? A forked compiler isn't going to get maintainers? A package depending on the forked compiler isn't going to be maintained? The social cost is possibly something to think about, but if one is set on leaving the community anyways then it's a choice between you choosing to not interact with the community and them (possibly!) choosing to not interact with you.
  - dnautics 6y ago
    It's still worth knowing that they're being jerks about it, since that falls outside of the social (but obviously not the legal) aspects of open source.
    - carapace 6y ago
      > falls outside of the social (but obviously not the legal) aspects of open source. Not really, IMO. Forking a project used to be a really aggressive thing to do back before GitHub made it so common among younger waves of developers. If you go to Evan and say, "Look, I want to use your thing but do it my way." and he says "No, I have a clear vision of what the thing is and it's not that. KTHXBYE." I don't think that's "being a jerk".
  - billjings 6y ago
    The community is more valuable than the code, because the community writes the code. So being cut off from the community is a major blow to a fork, and substantially increases their work burden.
    - whelming_wave 6y ago
      Your fork isn't a significant amount of work, unless they've really threaded in the must-be-in-Elm-Kernel check throughout the entire compiler. Versus trying to rewrite your dependency in Elm rather than enabling importing JS, enabling JS is likely to be simpler since the functionality already exists to let Kernel modules do it.
- deleted 6y ago
  [deleted]
em-bee 6y ago
the last thing i want is to get into drama with developers of a project, so if my choices are to give up and leave or fork and face drama, then i'll give up and leave. how that affects the Open Source status of a project is irrelevant, this is simply not a project that i could use, and thus for all intents and purposes, for me at least, it's a project that can't be forked.
- kazinator 6y ago
  If you fork quietly, you can avoid the drama. Just do your thing and don't respond to anyone (in any forum) who isn't reasonable and civil. Don't start drama, don't feed drama.
  - em-bee 6y ago
    if i am happy to just quietly run my private patched version, sure. but that's not the point, because the claim is that for a good Open Source (or Free Software) project, it must be possible to go public, and once you do that, if the original developers are unsympathetic then drama is unavoidable. there have been hostile forks in projects before, even those that eventually had a good ending. egcs for example. i was part of such a forked project too. it wasn't meant to be hostile, and the drama was limited to the project leaders, but it happened, and feelings got hurt. not everyone is willing to take that risk.

neilwilson 6y ago

That's what forking entails. It's a bit like Brexit. You don't get to stay in the club. If there are sufficient people unhappy with Elm but are cohesive enough to push the compiler forward, then why not?

macintux 6y ago
The author’s point is that other languages don’t (typically) kick people out of a club for forking.
- tzjmetron 6y ago
  Precisely.
cies 6y ago
You dont even have to push anything forward. Example Redhat's compilation of code or "forked" by CentOS, who were providing just a little more freedom. We all know how that ended. Just keep in sync with the main project, and keep the annoying/proprietary stuff out. > You don't get to stay in the club. Or you become the club. I think LibreOffice has more club going than Oracle's OOo.
lmm 6y ago
The open-source ethos means welcoming the friendly competition that comes from a fork. Look at the grandparent's link for the attitude taken by awk and bash.
amluto 6y ago
I’ve never used Elm, but that’s not how reasonable open source projects work. Red Hat maintains several rather divergent forks of Linux and they’re still in the club. I personally run a fork of Linux that I maintain, and I’m in the club. The only people who attract serious ire from the club are people who distribute out-of-tree modules that play poorly with the rest of the system. Even in that case, no one gets excommunicated, but the upstream kernel makes no particular effort to keep problematic modules working.