3 ms·

As I've participated in Elm's growth over the years, more and more I feel for the React devs who are pulled in many different directions by impassioned voices o

As I've participated in Elm's growth over the years, more and more I feel for the React devs who are pulled in many different directions by impassioned voices on every side. People have really strong feelings about how open source software authors should spend their time. I read the GitHub issues linked in the OP of that thread. Two are feature requests, and one is a bugfix for a behind-the-scenes problem which apparently has no noticeable symptoms. I understand OP's frustration that these haven't been merged or closed; nobody wants to do workarounds, and everybody wants feedback when they post on GitHub. I'm also personally sympathetic to the idea that Elm core libraries should have more frequent minor releases, which I agree with. The thing is, I also understand that when open source authors prioritize engaging on GitHub, that implicitly means not prioritizing other things. People think "how hard can it be to write one sentence of feedback as to whether this will get merged?" but that's not how GitHub works socially. An under-appreciated reality of OSS is that maintainers have two options: engage in a back-and-forth with issue posters until the issue is resolved to the poster's satisfaction, or brace for complaints that you're unresponsive. If authors conclude other priorities are higher than seeing that issue through to its eventual conclusion - however much time that may take up - it's understandable why they wouldn't even begin that conversation in the first place. (Naturally, those who prioritize responding on GitHub are subject to complaints that ambitious long-term projects are taking forever and perhaps deserve to be labeled vaporware.) If you have a BDFL, some will say things are moving too slowly because the BDFL doesn't have enough bandwidth. If you have a committee instead, some will say things are moving too slowly because there's too much bureaucracy. Trade flexibility for guarantees? Some will call that stifling. Trade guarantees for flexibility? Some will call that dangerous. We programmers have every possible combination of preferences, and those whose preferences already align with a given project tend not to bother posting about it online - because they're off happily using the thing that's worked well for them. I think this is why I've found contributing to open source consistently rewarding but frequently exhausting. For reference, here's what Evan said about the big picture topic here: https://www.reddit.com/r/elm/comments/73ubxo/an_explanation_of_elms_policy_on_native_code/ https://www.reddit.com/r/elm/comments/73ubxo/an_explanation_...

tazjin 9y ago
Some loose thoughts: A lot of this boils down to figuring out a delegation model that works for Elm. Does the BDFL of the language really also need to be the only person maintaining core libraries? The only person maintaining project communications? In this particular case it feels like the Elm team is afraid of "losing control" over the language. That's often in direct contradiction with the project becoming more popular, so for a while maintainers need to choose between advocating the thing they're building and advancing it in the way Elm is currently being advanced. Once things like [1] start appearing in the codebase you're basically asking people to fork your project and what happens after that is unknowable ... [1]: https://github.com/elm-lang/elm-compiler/blob/d07679322ef5d71de1bd2b987ddc660a85599b87/compiler/src/Elm/Package.hs#L72 https://github.com/elm-lang/elm-compiler/blob/d07679322ef5d7...
- always_good 9y ago
  I've been using Elm for years now and it's always been openly admitted that core abstractions are still being decided. You can just look at the change log between versions (which are all sub-1.0) to see that. You have to be okay with that to use it in production. Else you would have used something more stable instead of decided to gamble. I think Elm is still too early to bike-shed over governance model. And people seem to think Elm is a lot farther along than it really is. Else they wouldn't have the expectations that they do. Or they wouldn't go "I don't have these issues with React." I think the social issues Elm has are just what it's going to take if Elm wants to arrive at something more compelling that just another language. If there's a continuum with BDFL on one side and design-by-committee on the other, then you're going to have issues no matter where you move the needle. The upside of the bus-factor-of-1 approach is that you have a visionary in the Hickey hammock. And the unavoidable downside is that you have to deal with the bandwidth of one person which describes a lot of the social issues. I think that anyone who is uncool with that reality chose the wrong language. And a lot of the criticism that results from that, like this: https://www.reddit.com/r/elm/comments/7zk0dy/is_evan_killing_elms_momentum/ https://www.reddit.com/r/elm/comments/7zk0dy/is_evan_killing..., starts to reek of the hot air of entitlement, to use Rich Hickey's words.
- rtfeldman 9y ago

tazjin 9y ago

Some loose thoughts: A lot of this boils down to figuring out a delegation model that works for Elm. Does the BDFL of the language really also need to be the only person maintaining core libraries? The only person maintaining project communications? In this particular case it feels like the Elm team is afraid of "losing control" over the language. That's often in direct contradiction with the project becoming more popular, so for a while maintainers need to choose between advocating the thing they're building and advancing it in the way Elm is currently being advanced. Once things like [1] start appearing in the codebase you're basically asking people to fork your project and what happens after that is unknowable ... [1]: https://github.com/elm-lang/elm-compiler/blob/d07679322ef5d71de1bd2b987ddc660a85599b87/compiler/src/Elm/Package.hs#L72 https://github.com/elm-lang/elm-compiler/blob/d07679322ef5d7...

always_good 9y ago
I've been using Elm for years now and it's always been openly admitted that core abstractions are still being decided. You can just look at the change log between versions (which are all sub-1.0) to see that. You have to be okay with that to use it in production. Else you would have used something more stable instead of decided to gamble. I think Elm is still too early to bike-shed over governance model. And people seem to think Elm is a lot farther along than it really is. Else they wouldn't have the expectations that they do. Or they wouldn't go "I don't have these issues with React." I think the social issues Elm has are just what it's going to take if Elm wants to arrive at something more compelling that just another language. If there's a continuum with BDFL on one side and design-by-committee on the other, then you're going to have issues no matter where you move the needle. The upside of the bus-factor-of-1 approach is that you have a visionary in the Hickey hammock. And the unavoidable downside is that you have to deal with the bandwidth of one person which describes a lot of the social issues. I think that anyone who is uncool with that reality chose the wrong language. And a lot of the criticism that results from that, like this: https://www.reddit.com/r/elm/comments/7zk0dy/is_evan_killing_elms_momentum/ https://www.reddit.com/r/elm/comments/7zk0dy/is_evan_killing..., starts to reek of the hot air of entitlement, to use Rich Hickey's words.
rtfeldman 9y ago