Elm & Open Source: What's Next? • Evan Czaplicki & Kris Jenkins
Evan Czaplicki, creator of Elm, discusses the sustainability challenges of open-source that led to Elm's development pause, his new work on a full-stack typed functional language, and his thoughts on improving developer experience to make functional programming more accessible.
The State of Elm and the Realities of Open Source
The five-year pause in Elm releases stems from a fundamental challenge in open-source sustainability. As Elm’s creator, Evan Czaplicki, found himself in a position where the language’s success created an unsustainable workload. His professional value at his sponsoring company was not tied to the growth of the Elm community, meaning a surge in users and their associated needs didn’t translate to more resources or support for him.
This disconnect led to a critical realization: to continue investing in the language’s growth, he needed a model where that investment was correlated with an ability to support that growth. He decided to step back from public development to find a more sustainable path, rejecting donation models which he felt would still tie his value to public perception rather than the technical merit of his work. This period was about working on his own terms, ensuring long-term viability for himself and his projects.
A New Direction: Full-Stack Typed Functional Programming
During this hiatus, Czaplicki shifted his focus based on feedback from companies using Elm. A recurring theme was that while their Elm frontends were stable and successful, they consistently struggled with their backends. This insight prompted him to explore what the principles of Elm—type safety, helpful error messages, and a focus on developer experience—would look like in a full-stack context.
He has been developing this new backend language and system privately to avoid the premature scrutiny and expectation-setting that can plague new technologies, citing the difficult public reception of Google’s Dart as a cautionary tale. The core vision is a deeply integrated system where the compiler can analyze the entire stack.
“If I can make a change in my database and see the nice helpful error message in my front end and in my server is like I think that could be really huge.”
He is now at a point where he is confident in the core ideas and has begun sharing demos in private talks, preparing for a more public release when he feels ready to sustain the attention it will bring.
The Flawed Economics of Open Source
A significant portion of the conversation delves into a critique of the modern open-source ecosystem. Czaplicki argues that the foundational ethos of open source, rooted in the 1990s and writers like Eric Raymond, is insufficient for protecting independent creators today. He posits that this ethos, while framed as anti-corporate, has been effectively co-opted by large corporations.
“When you go and publish code for other people to use you’re really putting yourself out on a limb to say like I trust that the people benefiting from this will take care of me. And what I kind of got the message with Elm was that that’s not true.”
He points out the personal cost for maintainers, who often face a choice between handling an issue for a stranger and spending time with their family or getting enough sleep. The expectation of free, perpetual maintenance is a path to burnout. His advice to new open-source developers is to be wary of the fact that many companies use open source as a business tactic—a funnel into paid services—and to ensure there is a path for the value they create to come back to them, perhaps by partnering with someone with business acumen.
Improving the Accessibility of Functional Programming
To spread the adoption of typed functional programming, Czaplicki emphasizes the need for immediacy. He contrasts the often steep learning curve and complex setup of some functional languages with the “get a website up in 15 minutes” experience offered by frameworks like Ruby on Rails.
The goal should be to make the initial developer experience as frictionless as possible, allowing programmers to achieve their primary goal (e.g., building an app) quickly. The learning of deeper concepts can then become an “exciting side quest” rather than a frustrating barrier. He suggests creating a well-defined, simple subset of a language for newcomers, much like how most people initially learn a very small, simple part of Python. Advanced features should be compartmentalized as an “expert area,” allowing a clear path for beginners that doesn’t overwhelm them.
The Origin of World-Class Error Messages
Czaplicki’s famous focus on high-quality compiler error messages was born from personal frustration. While learning OCaml and Haskell, he felt “betrayed” by how opaque the systems were, which suppressed his confidence and made learning take far longer than necessary. He and his colleagues found themselves constantly apologizing for the poor error messages to newcomers.
The breakthrough came serendipitously while working on a feature to output errors in JSON format. While deep in the compiler’s code, he realized he could re-engineer the process to provide far more helpful and humane feedback. This highlights his philosophy that rigid roadmaps can sometimes close off opportunities for unexpected, high-impact innovations.