"The Hard Parts of Open Source" by Evan Czaplicki

For me, the best thing I got from this critique was the link to this 2018 talk by Evan: The Hard Parts of Open Source, [this video] I found Evan's talking style really entertaining and enjoyable, and I totally relate to the first part about "why don't you just..." and "have you thought about delegation..."! The HN comments here are near uniformly negative towards Elm and supportive of Luke's criticisms. Fair enough, it's a reasoned critique and those are definitely issues that would affect users. I found the critique informative and useful. I don't use Elm though I've watched with passing interest for a while. Now I feel there are gotchas or expectations I should be aware of if I'm considering using it, about the way the project is heading. But I felt it came off way more entitled than I'm comfortable, mainly when Luke starts moralising , placing ethical obligations upon Evan. 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".

There's a great Strange Loop talk by Evan Czaplicki (of Elm fame) where he alludes to the challenges of maintaining an open source project.[1] In it he describes how feedback often starts as an innocuous "Why don't you just...?" where the person making the request doesn't have the full understanding of the system as a whole and may see their request as a simple one-off that can be done quickly. To answer them fully, the open source maintainer has to respond with a long explanation of why their suggestion isn't an option. Or, maybe they don't respond and now the original poster doesn't feel the community is supporting them. This asymmetry can lead to poor communication in the community. I've been working on an app and was reading about the pros and cons of going freemium vs. pay up-front. I was surprised to read that people suggested the pay model is better for indie devs because with free, you'll have more users, but you'll also get worse feedback from the free users. Maybe there's a correlation between seeing something as free and feeling that the work behind it is trivial? [1] [this video]

I've used Elm professionally for about a year, having done full rewrites of both a bloated React/Redux SPA and a map data visualizer with complex JS interop using ports to Leaflet, AWS Cognito, etc. Luke Plant's blog post doesn't at all reflect my experiences with Elm or my feelings about the core team. For those not privy to the Elm tea, a brief primer: this blog post is primarily concerning a months-old issue regarding the removal of the ability to use native modules, which are effectively patches to the Elm runtime[1] which circumvent the core features of the language that provide its greatest strengths: a genuinely helpful compiler and ironclad runtime guarantees (still have yet to encounter a production runtime error that wasn't on the JavaScript side of things!) This "feature" (used loosely) was largely undocumented, always verboten from distribution in user packages, and never intended as anything more than a stopgap measure in extremely rare cases.[2] It was /officially/ not a core language feature intended for widespread usage, and consistently advised against by the Elm team. The removal of native modules was spoken about publicly months before the breaking upgrade. It came as no surprise to me. As an engineer who tries really hard to be responsible, I do not build software which relies on features which are advertised as 'do not use unless absolutely necessary' and are soon-to-be deprecated unless I'm willing to accept the inherent risk of doing so. The core Elm te