"The Hard Parts of Open Source" by Evan Czaplicki on HackerTube: recommended by 8 Hacker News commenters across 6 separate months, 2018–2021.
talk · evergreen
Evan Czaplicki, creator of Elm, discusses the hard parts of running an open source project: online community conflict, why its patterns arise, and a cultural history of open source. He offers ideas for more civil, productive communication.
HN recommends it as an insightful look at the people side of open source maintenance, especially in Elm and maintainer-burnout threads.
“Regardless of whether you agree with his approach to developing a programming language, it is a talk worth listening to. Very insightful.”
9 Hacker News comments link this video. Each one links back to its thread.
For those interested in hearing about Elm creator Evan Czaplicki's experiences with developing open source software and the complexities of internet social dynamics, there is an exceptional talk 'The Hard Parts of Open Source Software'. ▶ this video Regardless of whether you agree with his approach to developing a programming language, it is a talk worth listening to. Very insightful.
in “Elm Roadmap” · View on HN
I enjoyed "The Hard Parts of Open Source" by Evan Czaplicki (the creator of the Elm programming language) a lot. ▶ this video It's not a talk about technology, but it's a talk on people _in_ technology. As an open source enthusiast, I found the discussion very important, especially in context where we easily tend to be distracted by technical details.
in “Must-See Tech Talks for Every Programmer (2014)” · View on HN
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
in “The Few, the Tired, the Open Source Coders” · View on HN
"why don't you just" is called out in Evan's "The hard parts of open source" [0] talk. He goes into some of the reasons it's a bad phrase and some of the problems behind it. I'd recommend the talk. [0]: ▶ this video
in “Adobe to remove Flash Player from web site after December 2020” · View on HN
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".
in “Why I’m Leaving Elm” · View on HN
Great talk indeed. I feel like it might be helpful to online communities to add a real "intent" field to their posting forms, like here in this video: ▶ this video
in “Why I’m Leaving Elm” · View on HN
Evan Czaplicki (Elm designer) has a great talk about this issue "The Hard Parts of Open Source" ▶ this video
in “Actix project postmortem” · View on HN
I think the 2018 Strange Loop talk "The Hard Parts of Open Source" by Evan Czaplicki hits on some things which SO should adopt. relevant screengrab: [link] full talk at ▶ this video
in “What does Stack Overflow want to be when it grows up?” · View on HN
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
in “Why I’m Leaving Elm” · View on HN