Funding Open Source with Evan Czaplicki

Evan shares what he's learned about Open Source funding and the tradeoffs of different models.
March 15, 2021


Hello, Yaron.
Hello, Dillon.
And, well, today we're talking about something that we haven't directly talked about, which
is Elm itself.
And we're very happy to have on the show with us today, Evan Ciplicki.
Evan, thank you so much for joining us.
No problem.
Thanks for setting us up.
Our pleasure.
Well, yeah, so I was hoping to, like, one thing I've been wanting to talk about a lot
is the funding stuff.
So that was, I actually had a conference talk scheduled for, I think it was like March or
April of 2020.
And I like ran a version of it in December 2019 around where I live for some compiler
I don't know if it went over well because they're just learning about like how to generate
assembly and I'm like, well, Google has all these ads.
But yeah, that's something that I think feeds into a lot of the conversations around open
And like, I think I've been like pretty naive about it for many of the years I worked on
the project.
So it's something that I think I'd be excited to talk about.
I don't know if you guys had thoughts.
I know you saw the recent panel discussion with Elixir and Julia perspectives.
So yeah, I was curious like how that hit your ears and what you thought of that.
I mean, it was awesome to hear about it.
I thought that that PL talk panel with Jose and Jeff.
Yeah, it was super interesting in particular.
I thought it was really cool to hear you talk, Evan, about the pros and cons of the patronage
And just like one of the points you brought up that I was really interested in was how
you've wanted to support other people contributing to Elm more regularly.
And you're just kind of like with the patronage model, you were saying it's sort of a limitation
that you're like, sorry, I'd love to pay you to contribute, but it's already hard to make
a business case for somebody to pay me a full time salary, let alone to pay more people.
So that's one of the things that's been a I've sort of understood the contours of the
bargain better.
So like, from my perspective, personally, it's a very easy setup where it's like, it's
an under market thing, but I get to work on it full time and everything's under an open
source license.
So it's can't be like claimed by some company if it gets bought or whatever in the future.
So I'm like, wow, that's great.
And I mean, 22 year old me was like, wow, that's amazing.
But as contributors who have made really cool stuff have followed, you know, the classic
arc of open source, which is you start on something on your own, it's very exciting,
you get to implement it, there's no deep considerations besides like what you're excited about.
And then when a couple people get interested, it's really exciting, because, interestingly,
it's like it's similar with YouTubers, it's like the that first content you're making,
the people who show up are really there because they want that.
And then it gets to a certain point where a broader set of people know about it.
And it's not necessarily for everybody.
And the sort of conversation online changes.
And then it's like harder for the creator, whether it's a, you know, technical or entertainment
content, it's like harder for them to participate in those conversations.
In the same way, and then that can start taking a toll on their mental health or physical
health or relationships outside of it that, you know, they don't necessarily talk about
on the internet.
And it's like, everyone I talked to who has been an open source, like some number of years
can talk about this story to some level, I don't know what how you guys relate to it
So I'm currently in the happy phase, where a lot of people are very interested, not enough
to give me a lot of contributors, though.
But I'm still in the happy phase.
But I've noticed I've been in the later phases in other smaller projects.
And I mean, the volume is also like a part of it, where it's like when you're getting
like one interaction a month or two or three, you're like, Oh, cool, you know, I got a little
blue notification dot in my GitHub.
Oh, someone found a bug.
Okay, let's let's fix it.
Let's take the day for that.
Yeah, that's and at the end of the day, it's done.
I'm still in that happy phase for me.
Is it the same for you, Dillon?
I mean, I know it's everyone has their own.
I've gotten both.
I've gotten both sides.
But I've definitely gotten I've seen a lot of people express appreciation, which always
makes me really happy.
I've also had days where I get pulled down by some comment that's like, I expect this
thing or like, why isn't it this way? or why did you make this decision?
And it really drags you down.
I can imagine with like, supporting something is broadly used as a language because like
with tools like Elm GraphQL, like the scope is kind of narrow enough that I can say like,
this is what this project does for you.
And this is like, these are the the goals of the project.
And if things are outside of it, I can say like, okay, great, maybe another thing can
do that.
And you can almost say that it's done at some point.
Whereas with a programming language, you can never get to that point.
And I think it's also like being able to draw those boundaries with a language is like,
should this feature be in the language?
It's like, it's hard to like have a predefined answer to that, right?
It's like, I mean, for things you've seen before, it's like, you kind of know the landscape
there and know what the problems are.
But it can be really complicated to like convey that.
So I think another component to the like, arc of open source is like time component.
So that's the kind of thing where at a certain point where the kind of thing you're talking
about where like, you can really get down for like a day based on, you know, someone
who wants something and is like, excited about the project, but like, it was read in a way
that was like hard to take in in a positive way.
Right, right, right.
It takes a toll, right?
So it does.
I've noticed my threshold for those kinds of interactions is like, it's more painful.
Over time, like it's not Yeah, I always hoped I did get stronger with it.
And it's like, it's not always that way.
Yeah, one of the things that I've noticed, I'd be I'd be curious to hear your experience
with this, Evan, is like, the things that get me down, probably, probably most often
are just like, sometimes people frame things, and I really appreciate it in a way where
they're like, hey, these things are awesome.
I'm not sure if you've thought about this thing, there are probably challenges.
But you know, here's some things to think about if you haven't, do you think you might
ever consider supporting something like this, yada, yada, yada.
And I'm like, super appreciative when people strike that tone.
And sometimes the tone is like, why doesn't it do this thing?
Or why does it do this thing this way? or and sometimes the thing about that is just
the tone, it can feel like it's, it's not acknowledging all the things that are there
that are good about it.
And sometimes when you've poured your heart and soul into making these things awesome,
they're like, Oh, the docs don't really talk about this thing.
Do they?
And it's like, yeah, like, it's just I just added this feature.
I've been like working for three months on my weekends to build this thing, which I thought
was super exciting and all you have to say about it is like, Oh, the docs don't tell
me how to do this.
Yeah, it feels it takes the wind out of your sails, you know?
I know the exact thing.
And it's like, in my mind, I have to do the like, it is, you know, technically, it's a
constructive comment, and it is a thing that can be better, you know, and it's like, you
know, being in a certain kind of position, it's like, I can't, if I'm feeling frustrated,
like I need to be really careful about how I'm communicating.
Because like, ultimately, my, my goal is to make a cool thing that people like, and they
have as good as possible and experience with it.
And so like, I don't want to be because I'm feeling bad, or I'm feeling hungry, or, you
know, something, you know, my mom's feeling sad about something that like, someone's experiencing
that, and they're just trying to make a cool program.
But I think one of the things that happens when in the unpaid one, oh, oh, yeah.
I think the root of it is like, at least for me, I've become come to think of it more as
like, knowing what kinds of sacrifices or choices, not, not sorry, but like choices
I've made to work on the language and do the things I'm excited about.
So it's like, in my case, walking away from the Google job, I wanted to do that.
But it's like, that is a choice that costs a lot of money, if you if that's how you look
at the world.
And so it's like, okay, like, that's a price I want to pay to pursue this.
And that's like, being on the patronage model, you have this sort of like uncertainty, even
more so than if you were on your own doing a consultancy or something, because it's like,
I don't really have agency over my salary, you're relying on someone else's like good
will, and hopefully it fitting into their business model somewhat.
Yeah, or like whatever they imagine I do, you know, whatever it is.
So like, being in a case where it's like, okay, like, hey, like, you know, I want to
have kids with my wife, it's like, when does it make sense to do that such that the Elm
work can continue as we want as well.
So it's like, that's the kind of conversation I might be having about something not necessarily
on an online forum.
And so I think when it's like, hey, why isn't there this?
Why isn't there more?
I can't, you know, have seen that conversation.
It's like, you know, there's, there's like physical limits, there's mental limits.
And like, it may, it's uncomfortable to talk about that in like a GitHub issue about right,
Yeah, yeah.
String encoding details.
Like, like you said, you can have a technically constructive comment that's giving useful
information about something, but it can feel there's like this whole emotional context
that gets missed.
So it can feel like it's shooting down all the other things that are going on.
Yeah, and so, I mean, it's been interesting to see how that's played out over like the
pandemic where I think tech, Twitter, at least what I saw got a little kinder or less active
And like, since, you know, beginning of this year, it's gotten a little bit more active.
So I don't know, I think that all like changed a lot of the dynamics.
But in terms of like getting back to the patronage model, which is how we started this, it puts
me in this lucky position where it's like, if I'm struggling emotionally with something,
it's like, okay, well, I can take a rest and I can come back and it's my job, you know,
I need to come back.
But for people who aren't in that situation, they say, hey, it's my Saturday, and my spouse
would like to see me this weekend.
And it's like, what am I gonna do?
Or kids, you know, people with kids, that's a tough call to...
Yeah, so I think that's another component.
So to go back to that point of like, seeing other people struggle with this and not knowing
how to help is like, I see other people in open source goes through this.
And having to come to a point where they say, hey, I have a kid on the way, like I need
to have different interactions with people online.
And you know, I hear that and I say, that's great, like that someone's choosing their
kids, that someone choosing their family, or their physical health or mental health
as the top priority, like, I can only be happy for that.
And in a patronage model, you say, hey, like, this was a conversation I had explicitly,
it's like, people are getting to limits, you know, and, you know, people who work at the
company too, but have open source stuff, what do we do?
And it was just like, well, that wasn't how they looked at the support of how they thought
of the patronage model.
And it's like, you know, that's just one of the things that you have to be aware of.
So like, if I could give myself advice, whatever, nine years ago, I think I would have been
a lot more aware of trying to do some kind of consulting outside of it, or being much
more aware that having full support from the engineering organization isn't good enough,
because like, that's not where the decision stops, right?
Like everyone in the whole org can be like, this is a mistake, this or that choice.
But it's a classic case of the tragedy of the commons, which for anyone who doesn't
know what that is, it's just this idea that, sorry, there's a teapot over here.
It's all good.
You have like, these fields that cattle can openly graze in a community in a village,
and you're supposed to limit how much grazing you do to make it sustainable for the whole
community, but there's nothing preventing one person from overgrazing, and then actually
causing the pastures to go dry and become useless.
And since there's nothing preventing, like any person can go and, you know, it doesn't
benefit the community, but there's nothing incentivizing you to behave in a way that's
going to benefit the long term longevity of the community.
And similarly, like with open source work, there's so much value that's being created
by it, and if it can be supported even more, there's a clear monetary benefit.
But who pays that and what causes you to be incentivized to pay for that?
And what's interesting is like, depending on the specific project, like the norms about
what are acceptable models varies very widely.
So like, I have the sense that in programming languages, there's some price to pay for having
a consulting firm.
I think people are somewhat skeptical of that in a way that they aren't with operating systems,
It's like Red Hat can be this massive business, and it's like, oh, well, that's an operating
But when languages do it, it's like the conversation is not quite the same.
And then like with databases, it's like, hey, we have this hosting thing, and we have all
this open source stuff, and that's fine.
And with scientific computing, some of them just have straight up licenses where it's
like different universities pay for access to Mathematica or Stata or whatever.
And then with like individual packages, it's like, I don't know the extent of people who
have figured that one out.
So the thing of the patronage model is that like your bounds or whatever are set around
So I think personally, like one of the things, you know, it was my like December 2019, I
was thinking a lot about this topic.
And my big thing was like, I want to move away from patronage and explore what other
things can work.
And this question of like, how do you connect yourself to a system that's going to like
be healthy?
So like, the ones that the ideas that I had were like, you can have the donations, which
I'm very skeptical of, you can have consulting, you can do some kind of like, something kind
of like Netlify, where it's just like, hey, really easily get your ELM app online.
And each of these has different sort of trade offs and time costs.
So it was actually interesting to do the PL talk panel, because like, I hadn't talked
to someone who was doing a language that had explored some of these models so explicitly.
But one of the things I found interesting was that neither of those two folks from Elixir
or Julia were doing donations for engineering work.
And that was one thing I noticed is that like, it's very, I don't know of a language that
does that.
It's common for languages to have like a nonprofit to run the conference.
I think that's a somewhat defensible use of nonprofit status.
But I would feel really weird like being a software engineer, and like running that through
a charity, but the people who benefit from the charity are like, often like companies
with the money.
It's like, it feels weird.
I don't know.
I mean, some countries don't do nonprofits in the same way as us.
But it's something I personally have like ethical reservations about.
It's like, we don't have to get into that.
Yeah, it's tricky because with open source, like language or tool or whatever, being open
source makes it better.
So who would use a language that's not open source?
It would feel like very risky.
You know, Microsoft learned that lesson at one point and open sourced everything because
it created a lot of ill will.
And it wasn't working.
Like if there's like, you know, you can't look at the code and see what's going on and
But then, you know, it makes it really challenging to have funding models to sustain it, which
everybody wants.
Everybody wants to be able to sustain this thing.
So it's a weird situation.
So at least for what I'm trying is, so my wife happens to be a very skilled programmer.
So we're trying a little family business and the sort of like the ranking of things we're
interested in is like trying to do like some sort of easy hosting where like, instead of
the Elm Try page, it's like, hey, you can press a button and it's on the internet.
GatsbyJS sort of has that funding model as one of their core things, it seems like.
And next to that might be some level of consulting where like, I have my particular skills, which
like, I don't know if there is broadly useful, you know, it's like, but talking to Jose from
the, from Elixir, it was really interesting to hear how their like developer subscription
mod thing works, where you have like a direct line to some small set of like people who
are working on the compiler and core libraries and stuff.
And what's interesting about that is like you then in spreading the information that
it's good to spread to the community, it's like that's also supporting the work on the
I definitely know there's different, I don't know if I'm like the ideal consultant dispositionally,
I think I'd need to do a lot of personal work.
Just a specific skill set for sure, like the coaching tool chain and yeah.
So, but I think those two are kind of what we're, we think there's some thing that can
work there and it's like, you know, we're not here to make a bunch of money.
Like if that was the case, I wouldn't have done any of this, right?
This is not a lucrative path for someone who works on compilers, but like hopefully we'll
be able to figure something out there.
And like, I think this comes back to like, no, like the sacrifices you make and not like
choices you make to do the things you want to do is like, Hey, I'm, I have savings to
make it happen.
And like, I'm confident in our technical skills and our, that we can make that work.
But that's like, all this is kind of like a hard conversation to have in a text format,
you know?
Cause it's like, there's so much personal stuff and it's like, I don't necessarily feel
comfortable having that conversation with someone who thinks of Elm as like a technical
artifact that you submit issues to and they come out completed in some.
So for somebody who's listening to this and wants to support your, you know, your experiments
that you're doing with different funding, like, you know, let's say I'm, you know, at
an Elm company and I like, who would you want to hear from or how could they support you?
Like if that, would it be helpful if they reach out to you with like, Hey, if you're
looking to do some consulting stuff, here's something, whatever, like maybe we're doing
a parser, maybe we're building like an Elm parser thing and like, can you consult with
us on that?
Would you want to hear from someone like that or like, what do you, what do you envision
for that?
I mean, I think with the exploratory work I'm doing personally, it's still just too
Mm hmm.
Mm hmm.
And then my wife is doing the hosting experiment and also it's, it's, it's too early.
Like I think she'll in her own way, reach out to people and find that when it, when
it's ready.
I actually, I actually have done a little like consulting on compiler stuff and it's
very fun.
I'm happy to do that kind of thing.
So I think with these kinds of things, it definitely makes sense to reach out directly.
If you have a idea or something you're interested in.
And I know like with Prezi and Norit Inc and the other company I did a little, little bit
of consulting with, it's always been that way of reach out, Hey, I was thinking about
And I think with a, with compiler work in particular, it's like having that kind of
focused conversation is really good because you can have more shared context and have
a more focused conversation.
But yeah, I would encourage people to like DM about stuff if they're serious about that
kind of thing.
And also like there's no need for people to worry.
Like I, I can take care of myself, you know, and if I need help, I'll ask.
So I think part of why, part of why I'm hesitant to talk about these things is like, you know,
with a feeling of gratitude, I know that people will be interested to want to help, but sometimes
it's like, it's too early to be at that phase yet.
Does that make sense?
I don't know if you guys have had that experience with like stuff you're designing where like
the thing you have just like isn't good.
It's like not worth showing to someone yet.
And you'd have a whole discussion about how it's going to be and how this thing is gonna
work and right.
And yeah, when you're in the exploratory phase and to be clear, you're not talking about
Elm as we know it right now.
You're talking about some experiments.
So, but yeah, I totally can relate to that.
I want to be clear.
Like part of why I'm doing this exploratory work is like, I feel like Elm for browsers
is like, I like it.
I think it's great.
I don't really have a lot of cool ideas, right?
You know, it's like, I don't want to break it.
I want, I like it.
The core pieces are mostly in place.
So I kind of, at least yeah, beginning of this year, I was trying to, I was doing a
lot of exploration of like, what's something that is really special that I could do uniquely.
And I'd spent, you know, like two straight years doing like cleanup or not cleanup, but
like solidifying, you know, like making the parse very fast.
Which had amazing results, but probably was tedious for you.
It's not necessarily that it's tedious.
It's that it's like, I think there's something so exciting about, you know, coming to functional
programming for the first time, seeing that and being so excited about it.
And I felt like my projects were less and less connected to that feeling.
And so, yeah, so I wanted to do something where it's like, Oh, the magic of more side
effects, you know?
And so, you know, I was exploring, like I mentioned in the little roadmap doc, like
the integrating testing or integrating the formatting stuff or fixing the equality thing.
I think for my passion for the project, and I know this happens with other open source
authors, it's like, I need to prioritize the passionate work in balance with this other
kind of work that exists out there.
So that's kind of where I was coming from.
And so I forget if I said earlier, but like just thinking about how do we communicate
with, how does Elm, how do the borders of Elm fit together nicely with a server or database
in a way that like, it would be no change to Elm, but it could be really valuable to
someone using Elm that, Hey, things got a lot easier over there.
So, and I have that feeling of excitement again, but I don't know, it's still so early
where it's like, you know, Oh, like if I do this inlining thing and I'm generating,
nah, nah, nah, it's like, the question is like, does that work?
Regardless of what designs it may produce at some point.
So it's still very speculative.
Yeah, where does it fall apart if you pull on the thread or does everything come together
You have to sort of go for a while before you.
And I guess I can say like, you know, I'm like, one of the things I'm exploring is like
very aggressive inlining because there are contexts where that can be helpful.
And so I've been following the WebGL work and I'll chat with the people who are pushing
that and sometimes it'll be like, Oh, like that kind of inlining could be really interesting
in the context of like GLSL, like the shader language for 3D stuff.
So like, that's not what I'm working on, but it's like this sort of exploratory compiler
work at this stage, the only thing it can produce is like these possibilities.
So I think it sort of, you know, I've seen open source projects that like, well, I don't
want to, I never want to be talking really big about what I can do later.
I want to have done it before I.
Before you share the results.
And I know not everyone open source feels the same way, but right.
You don't want to make promises that may not be kept.
And I mean, this ties into like funding stuff as well, where like, if you want to be like
crowdfunded, I mean, people who have been in like programming language circles long
enough can probably think of examples where they saw like a crowdfunding thing and they
had really cool demos and then it turns out those demos are not like possible to implement,
but the money went there and you know, that to me is a situation I would never want to
be in the center of.
So like, that's part of why I think like having a nonprofit for like conferences makes sense,
but like tying people's labor, like development work to it.
And that's, you know, I've asked around people like, Hey, if we could do like a year contract
through crowdfunded stuff, would you be interested?
And a surprising number of people will be like, definitely not.
If you don't have anything to showcase or to promise, then like, what are you selling?
Yeah, exactly.
So I think it's like, and because I have sort of personally struggled with taking it really
hard, not meeting people's expectations, even if those expectations aren't my goals for
the language, tying that to my livelihood seems like it for me would be not a viable
I mean, it seems like a key part of like the secret sauce of Elm from my outsider's perspective
is like you explore big ideas, which I've got to imagine some of those explorations
we haven't heard about because they didn't work out.
I mean, just based on the kind of crazy, really like radical in some ways, features of Elm
that we now think of as the norm and it's our baseline.
I've got to imagine that there were some crazy ideas that didn't pan out too in that process.
I mean, I have an easier time talking about the ones from before because it's clear I'm
not promising that.
Also with the commands and subscriptions, that was one where no one was doing it that
I don't know.
I think there's a story around this I don't tend to tell publicly.
I'll keep it that way, but it's just like people were curious about how to do that,
generally speaking.
And I was thinking like, there's a way to design it where it's much more like type heavy.
So the designs I had, it was like you have to have open union types and you can express
with each kind of effect, it'll show up in the type.
So you can give permissions to particular parts of your code to say you have permission
to use the HTTP effect and you have the permission to use the logging effects or whatever.
And that would be clearly documented.
We go through how to do that in the type system and I'm looking into, I guess they call them
polymorphic variants in OCaml, but there was a discussion about it in Elm recently, like
open custom types where you can just arbitrarily add more variants.
And we sort of went to the limit of that.
And then we were like, what if we didn't do any of that?
And then we were like, oh yeah, that's nice.
So I think that's one of the things of like, I know with, I want to say like larger languages,
we'll have these discussions more publicly.
But I think part of that is because when you're on like a corporate funding model, there are
benefits to like, so many of the considerations shift in subtle ways.
So like if I'm a VP of engineering at Google and I'm putting some of my budget towards
open source project, I'm asking like, well, why am I not putting that towards features
on the products in my org?
So if they're not getting a certain level of usership, it's like, well, we really should
phase this out.
What I'm saying is like, the goal is like, you want it to be big.
You want it to be as big as possible in those kinds of environments.
Like part of why like Apple has their Objective C and Swift is like, they want everyone to
be using their stuff and not someone else's app ecosystem.
And the reason Google is putting all this money in their JavaScript is they want people
to use the web and not apps.
And so when you have the full set of people programming online, there's certain avenues
that make sense, especially if you have billions of dollars to spend.
And so like you can hire the dev rel person to be social media person, to handle the GitHub
They can like organize all the issues and add the nice labels and organize, Hey, this
would be a patch, but this would be minor and this would be major.
And then bring all that information into a meeting with the core developers and try to
hash out like what can fit in the capacity.
And then the dev rel person goes and has those conversations.
And so it's like, you have a more traditional like corporate product kind of structure where
it's like, there's a support team, there's developers, there's a CEO who is like the
You know, it's like, you don't call them that, we don't think of it that way.
And so I think...
There's a direct line through the incentives.
I've heard you talk about that, how like there are billions of dollars at stake for Google
being the default search engine in different browsers and that sort of thing.
So they can sort of justify large budgets for ensuring that they're good stewards of
the web.
The support team, if you want to look at it that way, can be big.
So like Chrome, I think is like 60 in Mountain View last I heard.
I don't know the actual number.
It's been years since I've been in that world.
But I think that's one thing that like on a patronage model, it's like super hard to
argue for those kinds of roles.
It's like not only you're not writing software, you're just talking online.
Like what?
And so, yeah.
So I always viewed patronage as a very nice model, as like the nice spot to be in.
And that's kind of what I aimed for previously.
So even at this company, they knew I was working on Elm Review and they may have thought they
would help me out working on it.
But in practice, I don't get the time to do it.
So I feel like I'm getting patronage, but I'm not getting anything or much out of it.
And I'm not even working, designed to work on it full time where I would have other limitations,
I'm sure.
So on that PL talk, there was a Jose Valim.
That with his Alexa support subscription.
That sounded amazing.
Like he gets a lot of feedback from the community and he helps them.
And that just sounds awesome for all parties.
Well, I talked with him a bit more.
And one of the things I noticed is like there's personal disposition that fits into that as
So like he's an inbox zero person.
I think that's like that it makes sense that that goes with that kind of relationship or
running things in that way.
And like I have a harder time with that personally, just because like in a deep way, like I surprises
me very deeply troubled.
I am with you on that page.
And Jose, he's consulted to start with, right?
So I think he I mean, he says, I think like Dillon mentioned earlier, it's like it's a
skill that you learn, which I believe, but I also do want to, you know, say like the
way both of you guys communicated.
I was like, I could hear more than skill.
Like it's like you have some like wisdom about that, that I don't I don't see in myself necessarily.
But yeah, I'd be happy to talk to you about it more in depth at some point.
But my background is in coaching and consulting.
And I mean, they're learnable skills.
Well, I think this connects to one of the things Jeff was mentioning, which was like,
with Julia, they had four people who all had like different, different ways of behaving
and different strengths.
And so that's something that like, for people who are interested in pursuing some kind of
goal with Elm, seeing how those can fit together, right.
So like, one thing that was really powerful for Elm reaching more people was like, Richard's
Yeah, definitely.
Getting that to in a practical way, like in a way that I can't, I am not deeply in
the culture of like, front end development, to be able to do the kinds of things he was
able to do.
And so that was his, you know, special ability.
And so I think that's something even though we don't have as formally as like formal relationships
as the Julia people had early on is like, that's kind of how I see it.
Richard clearly played a role as a sort of, yeah, and it was not a public face.
But it wasn't like I said, you've been selected, Richard, you are the one.
Like, he just totally to the point where at one of the Elm conferences, me and Richard
were sitting at a table like outside the conference venue.
And someone walked up and was like, Oh, Richard Feldman.
Wow, I've seen all your talks on Elm.
And then I was like, Oh, yeah, it's awesome.
Really good ones.
That's amazing.
So I think like, and we see that with like, people doing these ambitious tooling projects,
the WebGL stuff that's happening, where Ian's really like finding a way to make it progress.
And like, I don't, you know, I don't, I don't know how much he talks about in public, but
you know, making choices to make that kind of stuff happen.
So that's what I'm hopeful about.
And like, thing that I, I sort of, I don't know, I want to share is just like, in working
in this way for almost a decade now, I've sort of learned my personal limits through
like people being disappointed and me wanting to do more and doing more, but then paying
the price somewhere else in my life.
And sort of like learning how all those things are related.
And I think if I get into this debate today, I'm not going to be good when I sit down at
You know, I don't want to bring that energy into, into these other places.
And so like, I have to be careful about these things.
And so I'm hopeful that in talking about that and like talking about the difficulties in
funding, maybe that's helpful to other people in the community who are facing similar issues
or I don't know.
I wanted to follow up on what you're saying about having the patronage time, but not actually
having the time.
That's a super common story in open source.
I've heard from many people is like, even with 20% time, the, you know, if you're doing
static analysis kind of stuff, it's like to load that in to your head.
It's like, okay, that was my day.
So, and I know with a lot of problems, it can be that way.
So it's like certain kinds of work you can do in that way, but I know people struggle
to find the balance.
And so it's something where I think you have to have really clear boundaries and like expectations
with the person supporting the work.
But yeah, so I don't know, like, I wonder if having a more like distributed network
of people doing consulting setups creates more space for that kind of stuff.
I honestly don't know.
I think the Julia person was saying, it's like, we all need a Verall.
I think, you know, yeah.
I mean, it's a, it's a challenge to tie the incentives back to the thing itself because
ultimately at some point there's a natural push towards doing more of the thing that's
incentivized by the business and the business model and all those things.
And if, if that thing is like, you're getting paid to ship this product, then even if they
say your 20% time work on this open source stuff, that's great.
If that's actually not helping with that business goal, then eventually it's, it gets squeezed.
That's just the, the, the natural dynamic that's set up there.
And it's the same with the patronage model.
So like some, I like, I feel like the goal is somehow if you can like relate the value
that you're creating and be paid for that, then there's a natural incentive where it's
like, Oh, that thing that you're doing, that's creating value for us, do more of that.
And like have more money.
That's the, that's the dream, right?
If you can tie those things more directly together.
And so that's, I think why me and my wife are exploring the particular stuff we're exploring.
And I think part of the like culture clash is that so many languages are on the like
big company model and in that one, like growth and market share, no one necessarily like
says it explicitly, but like those are huge factors for people making choices about headcount
where it's like, if you are bringing 70% of people, right?
So a concrete example, like if the developer tools in Chrome are so much nicer that it
drives developers to Chrome, well then the websites work better on Chrome and that will
drive users to Chrome and the developers will tell their friends and family to use Chrome
cause it's nicer.
And Hey, that's default search.
That's something that you can look at like the financial filings of Google, how much
they spend per order.
It's incredible.
And it's like, how are there so many ads making, they can spend that just to give to Apple,
you know, and that like Apple makes about the same amount of money on default search,
selling default search as they do from like app store, the 30% they take on app purchases.
It's crazy.
So like the quantities we're talking about, but like, so when you have your mindset of
like, well, in the context of JavaScript, they would do this.
It's like, well, this whole structure that they fit within like 5% market share, 1% market
share, all these things are like numbers that when you go to negotiate your traffic acquisition
costs like matter millions of dollars.
So I think that's part of where there's like a culture clash between, and I do also think
like because there's so much more money, if you're willing to do things that way, like
I personally have come to feel that like marketing is a big deal.
If you want market dominance or growth or that kind of thing.
And I don't know if you can have market dominance in programming languages without also having
comparable funding.
So that's something that like when I started on Elm, I didn't believe that, you know, I
had this image that like, if I make a really nice thing and it solves problems, well, people
will see that and they'll like, and I never wanted to everyone to use it necessarily.
I just, my thing was like, I want people to know about the option, make a more informed
choice to use it or not.
But the more I've worked on it is like, if you really are doing like a, I don't know,
there's just these like nonlinear returns to marketing, especially if it's tied to a
money machine, like it is it, Microsoft or Facebook or that kind of stuff.
So I don't know, that's a question that I don't have an answer on, but it's something
that I'm like more persuaded by over time.
I also wonder if there's inherently like certain design choices in Elm that are not going to
be as, you know, popular.
Like if you're saying like, we're constraining what you're doing, a lot of people are going
to say like, oh, that sucks.
Like why won't you let me do that?
People don't want to hear that, but a certain set of people are like, oh my God, that's
You mean I can't do this thing in that context?
That's brilliant.
Like then I won't get shot in the foot there.
But do you think that that's inherently a quality of the like language design that it
won't appeal to certain people?
I think like the more I thought about like if I was designing for growth and market dominance,
this the limiting features is a loser strategy.
So like the great thing about you can sort of pejoratively say kitchen sink, but in a
more friendly way, say like, you know, languages that are eager to add features over time.
It means that you can have all these different sub communities of different preferences and
dispositions and you see that where like a lot of different companies have their own
style guide.
So they say, we use these 10 features and we explicitly don't use these 20 features.
So that exists in like the C and C++ world where it's like, yeah, we don't check in any
code that does this kind of template stuff and we don't do any kind of code that uses
like prototype stuff.
And so it's a strategy that creates a space for every disposition.
But the price is that for any given disposition, you're actively asking questions about where
are those boundaries for you and where should they be for people in the company and new
people are coming into the company.
So I think at least from my perspective and the things I'm interested in, like I like
types, I like no side effects.
It's like my preferences can't really be well represented in the like super, you know, choose
your own adventure way of interacting with a language.
So I do think that's like, I mean, could a language exist someday that was statically
typed and had managed effects?
I mean, I imagine if like Facebook or Microsoft, I mean, Microsoft tried with F sharp, but
well in which F sharp you can interact with object oriented and imperative code.
And you know, like it's more additive than like creating a sound sandbox where all the
types are sound and you don't have, you know, side effects and that sort of thing.
I mean, that's a bold position for a language and which is what we love about it.
But then in terms of making a popular choice, like TypeScript is the perfect formula for
a super popular growth trajectory because you're like, Hey, take this thing, you know,
change the extension to dot TS or actually you don't even have to do that.
And now it's TypeScript and you've got better intelligence and people are like, Whoa, that's
Which it is.
TypeScript is brilliantly designed for its goals.
And interestingly, I saw this talk from Bjarne Stroustrup, I think I'm saying right, who
did C plus plus in the eighties and he was saying like every C program was a C plus plus
program like, and you know, that's a massively successful language if you're, if what you
consider success is market share and growth, right?
And so it's, it's just like, it's a winner of a strategy for those kinds of goals.
And so I think that's one of the things that's like when people come in with, you know, everyone,
when they're sort of new to programming languages, they have an idea of what languages should
And so when they come and they see a language that's not doing those kinds of things, it's
like, what are you doing?
You're totally blowing it over here.
It's obvious this would work better.
And so I think that's one of the interesting things I've noticed as I've like learned more
languages and talk to more language designers is like, once you know what their goals are,
the languages always make more sense.
And it's like, so I have come to this place where it's like, I want to have respect for
every language.
And if they want to do it, you know, I have my own opinions, but like, Hey, people have
their opinions about what my stuff too.
And it's like, it's going to find its audience or it's not, or it's going to fulfill the
goals of that person or it's not.
So I don't know.
So my, my exciting one was like when I became a PHP defender, I was like, you know, people
are really not appreciating how easy it was to build what you wanted, you know, and it's
like, you can make all these language criticisms and that's fine and true, but like you can't
in getting caught up in that.
It's like, essentially, I think it's a mistake as a language designer to let your personal
preferences blind you to what people find exciting in other languages, right?
Like it was a, it's a cool lesson to look at PHP and see the power of ease of getting
Are you not blinded by your love for static types?
I don't think so.
I mean, like, I look at like Julia, like if you say, Hey, we're going to do a language
for scientific computing.
I would say, all right, one of the key issues is like, we want addition to work nicely with
floats and in on all these different platforms.
And we're, we have scientists who say, Hey, I care about whether not about, you know,
Turing, what Turing had to say about anything.
So like, and you look at the history of that thing.
So it's like, I look at it and I say, is there a way to do like matrix math in a type functional
way that's like really feels amazing.
And it's like, I don't know, I don't know.
So I think when you look at the different domains and you see the choices they make,
it's like the way that I find like valuable and enlightening is to see what everyone else
is seeing in it, you know, cause it's the same with like, I can appreciate a lisp, you
know, and it's all the things that people say about it.
Like it's so, it's so concise and you have this beautiful syntax that's rebindable in
these cool ways.
And it's like, I see that.
It's not my preference, but I can enjoy as like an aesthetic point in the design space
that coheres.
Does that make sense?
I don't know.
I think it makes sense.
Like any, any language or tool or whatever it might be should have a, there's no right
or wrong answer, but there are compelling stories or not so compelling stories and a
compelling story could look completely different than a different compelling story.
They could both be compelling.
I honestly, now that I think of it, I have the most trouble with languages that are really
focused on lots of ways to say something.
I know people really love that.
It's hard for me to like fully step into those shoes in the way that I can sort of step into
the mind of like someone who just wants to do their weather simulation or run their like
employment statistics graph.
But yeah, I mean, same like with the dependently type stuff, like those languages are really
I personally struggle with them sometimes, but like I can see the beauty there.
So I don't know.
We went to a bit off of funding there.
I mean, that was a great, that was a really good conversation.
Maybe we can change gears.
Maybe this will be our last topic unless there's anything else you want to cover, Evan.
So I know that, you know, Yaron and I, as people who are very passionate about tooling
are very interested in sort of the Elm tooling ecosystem and you know, I think you made a
point about this in a talk, Evan, that like use Elm to do cool things.
Like Elm is this language that has these design features that make for really interesting
use with tooling.
Yeah, for sure.
So like maybe let's talk a little bit about like the tooling landscape and how Elm fits
into that and what's going on in the ecosystem.
For example, you know, we've got some really cool stuff in the IntelliJ plugin for Elm
We've got the Elm language server doing a lot, you know, adding a lot of features.
We've got, you know, Yaron is doing a lot of cool stuff with Elm review these days with
static analysis.
With great tweets as well.
Great work on that.
Yours are better apparently.
No, no, no.
It's like you know the tricks, right?
You got to get that GIF, you know, immediate comprehension.
His marketing team is on top of it.
There's a lot of like cool stuff going on there and like I'm sure the people who are
working on those tools appreciate the like joy of having a typed language without side
I certainly do.
So like, like no, no question here.
And I think like as a compiler person, it's like I very deeply know like the price of
some something that looks little in terms of like all the optimizations you can never
do because of it.
So yeah, so I think it's been really interesting to see that develop and especially in cases
where like I think a while back we had this question of like, well, the compiler has this
information like can the compiler expose it?
And my challenge was like, I don't, I'm not a IDE person.
I don't necessarily know what people are looking for and what they want from that.
So like I couldn't, I just didn't have an intuition of what, how that would work.
And like, you know, I have questions like I want your CI compile times to be as fast
as possible.
How does that match with the goals of an IDE that wants type information in this or that
So I think there was a point, I don't know what happened, but people sort of decided
like we're going to pursue this in the like editor tooling space and have been making
really cool progress with type inference and the features that can come from that stuff.
And you know, I think I ha it sounds like I have bad intuitions for ID stuff basically,
because I'm like, why do we need to keep anything in Ram?
Why can't we, you know, and I think for like for compiler stuff, it makes sense to view
it that way.
Cause it's like, well, I need to save everything to disk between runs no matter what.
So if like, if I can make that so fast that it's not an issue to get things under your
cursor, Hey, that's cool.
But maybe that causes all sorts of problems that I don't appreciate.
And so I think over time we sort of found that like that's something that I don't know
how to do and they do.
And I think that in general has been a cool way for things to work.
So like, I know there's little explorations of like, what would it look like to run Elm
on what's it called?
Um, and it creates all these questions of like, well, you need to write to files, but
files don't work in browsers.
And so in the package ecosystem, you'd have to have a way to market, not just as an application,
but as like a browser application versus electron application.
So before you even start on the project, you're, you're asking these really intense design
questions that would have an impact on every person using Elm in the whole ecosystem.
And so with those kinds of things, it's sort of, in some ways it makes sense to say, Hey,
like try and experiment, call it pine and run it as like a super set that has this.
And then once that's like born out in reality, then talk about how to bring it back in and,
and in doing, in doing that project, you can start to build a relationship with the people
who you'd need to coordinate at some point in the future and say, Hey, you know, like
people can see your work, they know what your, what your style is in terms of what you're
So what, instead of having that discussion on day one, you have it much later on.
And at that point, you yourself might find, Hey, I don't, I do want this to be a separate
So that, that, like that kind of mirrors my own story with Elm where I wanted typed functional
programming in the browser.
And I was like, well, should I make a Haskell compiler?
Should I make a OCaml compiler?
And as I thought about the problems and what my goals are and what was interesting to me,
I ultimately was like, well, I do want to make a separate thing, you know, like, and,
and it'd be so hard to meet the needs of everyone in Haskell and what I'm looking for and the
people who I'm interested in having some sort of interaction with through this work.
I have to admit it's a bit embarrassing to think back on this now, but I built a project
called Elm TypeScript Interop a few years back.
And you know, I mean, it's, you know, it's a handy project.
You know, you point it at your Elm code base and it statically analyzes all the ports and
it generates a TypeScript declaration file that gives you IntelliSense and types around
registering your Elm ports, you know?
And I remember thinking like, wow, like that the goal was like, wow, this would be cool
if this was integrated into the compiler.
And fortunately I never, I never suggested that or, or requested that.
But in retrospect, I'm really glad that I just went off and I was building it as an
independent thing and got to the point where I realized that wasn't actually my goal before
going forward with that.
Because in retrospect, it, it, well, it was an experiment that actually now I'm deprecating
in favor of a new library that I'm building for, for typed, interrupt with TypeScript that
I think is like a far better approach, which hopefully will be announced by the time people
hear this episode.
Normally this, this, that would have been the previous episode.
Yes, that's right.
Our previous episode, hopefully we'll, if you listen to our last episode, you'll know
what I'm talking about.
But my point being that that worked really well to really have an experiment that, I
mean, I didn't have to get permission for that experiment.
I, I just, I built it, people used it.
Some people thought it was useful.
Some people thought it didn't quite work for their project.
And then I later realized that there, there's a way that I think is far better to, to accomplish
that goal.
And fortunately it wasn't built into the Elm compiler output that it also gives you a TypeScript
declaration file, which at the time I thought would have been a good idea, but seems silly
in retrospect.
I think one of the things that's been like a challenge for me conceptually is like, I
want everything to fit together just right.
And so I think that like suggests that integration is the optimal path in more cases than it
necessarily is.
It seems like that's something that like, especially in tooling, we're starting to like
be aware of the like, Oh, like I'm glad this is separate.
It's like that, you know, you don't have to worry about 19.2 verse 0 20 and like what
that means to, and it's like, look, I just want to do this patch.
Like it's not so serious.
So yeah, I think that's something that like we're, we're learning more about like collectively
how that balances and fits together.
And it is really interesting, like the fault tolerant parsing and hyper fast parsing are
two different goals between the Elm compiler and you know, the Elm language server and
all the tooling.
I do see for sure that there is like a lot of reinventing the wheel happening when I
see people like Yerun and Kolya and Keith and all these people like, and Aaron Vonderhaar
with Elm format, like figuring out compilers and getting this stuff, but that doesn't necessarily
mean that Elm needs to do it.
But I know that I believe Aaron Vonderhaar is working on some format that gives you a
JSON format of the Elm syntax tree, which is another great example of sort of, you know,
like filling in the gaps in the community in a way where we can rapidly iterate and
figure things out without being blocked on core features.
But I do think that like there's, there definitely seems to be a need to create some shared things
in the tooling ecosystem to prevent reinventing the wheel.
But I think that's happening in that group of like people who are passionate about tooling,
like, you know, Yerun and Aaron Vonderhaar and these people.
Yeah, which isn't to say like, I want to not be a part of it.
It's just like, I don't, I'm like, it's always interesting to like sit in the meeting, but
not like I can't lead them usually.
Like with, cause it's like, I'll have a little insights about, you know, oh, like laying
out your binary files in this way is going to be slow for this particular kind of user
who lays out their pack, like their files in this way.
As I know that, but like, I don't have the feeling of what the features need to be.
Totally, totally.
For instance, like you don't know much about WebGL, so you can't lead it, but you can help
people who are actively working on it.
You can sit in the same room and follow.
So that's something I'm very excited to see what happens there as a person sitting in
and some of it borders on compiler stuff, like with, you know, it's a, it's a shaders.
It's like, wouldn't it be cool if they type checked as well as, it would be very cool,
you know, and that's something that's like, oh, you're telling me I can write a type checker,
but for a different language that works in a cool different way.
So you know, I have to restrain myself with some of them where I do have enough overlap,
but yeah, but some it's like, if you want like rendering to a texture and then using
the texture back in another, you know, I don't know.
I don't know how to, I made a cube, you know, there's limits to what I know.
Well this has been an amazing conversation.
I've enjoyed it a lot.
Thank you for saying this.
Thank you so much for coming on and chatting with us, Evan.
We really appreciate it.
Are there any sort of closing thoughts on, I mean, so, so we, we kind of talked a lot
about the role that the community can play in sort of furthering Elm without needing
to wait for anybody.
So like, do you have any, any thoughts on, on what you think people could do to pitch
in and further the Elm community in some way?
Yeah, sure.
I'm, I'm always hesitant to suggest people do stuff because I can, I know, I can, I know
it can have a personal price.
So I want to be upfront about that.
But if you know that and you say, okay, I think like pursuing the thing that you're
really passionate about is just the path is like to be able to sustain these kinds of
projects on weekends and evenings.
It's like, you have to, you have to care.
And so like, if you're deeply excited about like sharing how fun it is for you, it's like,
is there a way you can share some demos, right?
Like tweet, like tweeting about demos and doing a video of it can be really cool and
inspiring for people or like demo applications.
Or if you're, you have a consulting firm and you want more of your clients to be using
My personal feeling is like, if your client doesn't want to use it, then like just end
it there.
Like just don't do it.
Like, I, like, I don't know.
I mean, maybe that would be my approach, but if you're working on making a case so that
more of your particular clients are interested, like I think a really cool thing that I would
love to see is like, here's the expenses we have on our react projects and here's the
expenses we have on Elm projects.
And this is the time we spend on bug fixes.
And this is the time we spend on, you know, after the project is over revisiting for subsequent
fix up.
So you can like put it in dollar amounts that a client could really say, Oh, like, I don't
know what Hinley Milner type inferences, but like, I would like to the lower price.
And even just sharing like case studies and success stories can be compelling for people
to see.
And then from a technical perspective, like, I mean, two of the talks, I was going to do
these two talks at Elm Japan and Oslo Elm Day.
One was about data visualization.
Like the talk was going to be called Elm for science.
So it's like, I know if there's someone out there who's like loves statistics or loves
data visualization or loves communicating in a visual way, they can do something really
special with data visualization.
And I looked into that project for a decent amount of time and ultimately kept hitting
this barrier.
They're like, I don't love statistics.
I tolerate statistics.
And that was like a fundamental barrier for like the level of passion I'd need to sustain
that kind of project and be the person making decisions.
Like if someone comes to me and say, Hey, I need this diagram for my like, you know,
genome protein production analysis.
It's like, I need to be able to have a conversation with that person about key values or whatever.
You know, obviously I don't know this stuff.
So like finding those passions and finding that niche where the things you're excited
about match the things that you are good at or the things you want to be good at and the
things you want to be pursuing in your free time.
So that'd be kind of my advice there.
And like, you know, know that the people who are doing it are doing because they want to
do it, you know, like so.
And I think it's, it feels really nice when people go a little bit out of their way to
show a little appreciation when they're reporting something that could be improved.
So, but yeah, hopefully that's somewhat helpful.
That's great, great stuff.
And it was a, it was a pleasure just having you on the show and catching up with you.
So thank you so much for coming on.
Thank you so much for organizing everything.
Our pleasure.
And yeah.
All right.
Well, until next time you're in, talk to you later.
Until next time.