Hello Dillon.

This conversation is provided as is, without warranty of any kind.

Just wanted our listeners to know that.

Alright, alright.

A pun at every start of the episode.

I really don't know how you maintain this pace for your puns.

I mean, you really pull your weight for them.

But I just want you to know, if you ever stop doing them, it's not an issue.

Just, it's fine.

I have a license to pun.

What are we talking about today?

Today we're talking about the human side of open source.

And I believe you and I have perhaps dabbled in open source a little bit, I would say.

Yeah, I'd say so.

I mean, how long has it been for me?

I think I started in 2017 with open source.

Yeah, that's starting to be quite a while already.

Do you remember what your first open source was?

Yeah.

First contribution was fixing a license.

Oh!

It was fixing the dates for a license.

Nice!

For someone's blog.

And the next one was doing the documentation for lodashfp.

Which was more ambitious already.

Yeah.

I believe my first open source project was in 2013.

And it was a random little Ruby executable for helping you with an interface to git.

Which probably two of my co-workers used.

Which is less than zero.

Right, yeah.

Oh, I guess I did publish an npm package or something around 2014 or 2015.

But getting really involved in other people's projects in 2017.

And that's when my project started as well.

Yeah, it definitely changes the game when number one you have users and number two you have contributors.

It doesn't really feel like open source if you don't at least have people opening issues and telling you about problems they're experiencing.

Or things that could be improved or discussing things with you.

Right, yeah.

If you only publish your package or your code and you put it on github.

It's very different from people interacting with you.

Making suggestions, making pull requests.

Telling you your code is crappy, your project sucks.

Right, exactly.

Which thankfully I have not had.

I've had a very good interaction with all of my open source projects so far.

That's awesome.

One of the things on my mind today is like, why do open source?

Like why do we even bother making a tool open source when we build one?

What are the motivations for us, for the community?

What's the benefit, what's the point of making something open source?

Right, well there are several.

One of them is feeling like you are helpful to people.

I think that's one thing that we tend to like as software engineers, as humans as well.

Just being helpful to others.

Like I'm making a project, I'm making a website, I'm making a tool that helps other people.

Any software project is basically to help someone.

It's usually you, even if it's just like making a video game.

It's helping you entertain yourself for an hour or two or two hundred.

So yeah, I feel like being helpful to other people.

So if something is open source, it's really accessible, people can use it.

There's also the recognition part.

I want to, I've made a tool or I've made something which I think is useful.

And I want other people to know about it.

Maybe to get my career going, to get, to have recruiters think that I am very qualified.

I have actually, for instance, like made a tool once.

Oh, that was in 2014, which I put on GitHub and it helped me land a job because they asked me like,

Hey, do you have some code that you have available that we can look at?

And I'm like, sure, you can look at this one.

And they hired me pretty much because they said it had tests.

So, you're running tests, you're qualified.

That's awesome.

Pretty low bar. I mean, I was quite junior back then, but yeah.

So yeah, recognition through multiple forms, like being just a junior who knows how to code quite well

or being a very famous maintainer who you can hire for consultancy on one of your projects.

Yeah, yeah, those are the two I can come up with.

It's mostly like helping people though.

I like that. I feel the same way.

I think helping people is really, there is something at the core there that you're right.

Like when we're building software, like if we're building software that doesn't help any single person in the world,

like why would you build it? It doesn't really solve any problems.

So you want to solve some problems.

And, you know, you mentioned like accessibility and I feel the same way, like with open source projects,

it's just, it's more usable and accessible.

It's whether that be going and installing something on NPM or copying part of the source code,

because some, you know, some module in your code is doing something that somebody else needs for another project,

or they want to go look at it for reference and see how you implemented something.

Maybe you're using the same framework under the hood and somebody just wants to go look at the code

and see how someone else did it.

Yeah, there's definitely like a learning aspect to open source as well,

where you look at other people's code and you learn from that.

Yes. Right.

And I definitely feel like doing more open source has helped me reach new levels,

which would have been hard to reach if I only did programming at work.

Yes, absolutely.

And, you know, to your point of wanting to build things that help people, you want to leverage that too.

So the more leverage you have, the more your thing can help people.

And if it's open source, it can help people in these different ways.

It can help people by them looking at the source code.

It can help them by them being able to use it as a dependency in another open source project,

because it's just an open source thing.

They don't need licensing.

They don't need to think about any of these considerations,

but they can also use it in a proprietary project and they don't have to think about that.

And, you know, for me as an open source maintainer, that gives me great joy.

If people use an open source tool that I built in their business, that makes me very happy.

I mean, honestly, if no businesses used the tools that I built, then I might not build them.

That's like one of the main motivations.

And it makes it a lot easier for businesses to build them.

Like these days, it's hard to imagine a business betting on a programming language that's not open source.

This has not always been the case, but there's been sort of a revolution where that's the expectation,

because, you know, how are you going to feel confident about the security of a project

if you can't look at the code and see what it's doing?

I think there used to be sort of the opposite view maybe a decade or two ago.

For languages or for projects or tools in general?

For both, yeah.

I mean, there's also just like the fact that it's very cheap because it's costless.

Like, it doesn't cost you any penny to use it.

Well, until you have to maintain it a little bit because the quality might be a little bit more,

a little bit worse than if you use a proprietary solution, which should hopefully be better.

Like it can go both ways, right?

Right. I mean, if it's open source, then it's open to contributions.

But if it's not open source, then it might be more sustainably funded.

So that's sort of getting to the other side of what might be some of the downsides of open source

or perhaps not strictly downsides, but challenges that I think,

I feel that we're at a pretty novel stage of open source.

And we have a lot of maturing to do as a software community in figuring out,

like we've kind of decided that open source is the way to go for most projects,

for languages and frameworks and libraries for the most part, for 95, 99% of them.

But we haven't really figured out how to make the huge ambitious open source projects

we depend on sustainable and avoid burnout for the people maintaining them.

Burnout.

Open source little friend.

Yeah. So that's another side of it.

And I mean, I recently spent a year and a half working full time on the on-page V3 release.

And it was very rewarding. I got to build this thing that I really cared about.

But it was, I mean, and I was fortunate enough to have a company helping to fund my work,

but I was still the primary sponsor of my work. Right.

And I think a lot of people in the open source community end up doing that.

There are some projects that are lucky enough to have massive sustainable funding,

but the majority of open source is not that way.

I mean, when you say massive, I'm like, it's still pretty small.

Like any project you can think of has very little backing compared to any projects that you can find at work.

Yeah. I mean, like React, for example, would be one of the big ones that comes to mind

where they have enough budget to hire full time teams of people building documentation.

But it's rare and that might not last forever either.

Yeah. I think actually some of them are moving towards other companies.

So it's diversifying in a way, which is probably good.

My memory might be wrong about this, but if it is, then yeah.

No. Yeah. I mean, Dan Abramoff recently left Meta.

So and he was one of the key people in the React team,

but he's still going to be on the React core team just at a different company, I think.

So it's just the difference is who pays him, I guess.

Yeah. Yeah. And perhaps whether he'll be paid for it.

I'm not sure in that particular instance, but it's definitely a challenge for the open source world.

And of course, in the Elm community, we are particularly aware of this

because we've seen different permutations in the life of Elm

with how Evan has been funding Elm's development.

And we had an episode about funding open source with Evan,

and he talked about a lot of different ideas there.

And a lot of the challenges of aligning the incentives between a business

and an open source project is very difficult.

So another thing that comes to mind for me with open source is,

so what should users of an open source project expect?

And what should maintainers of an open source project expect from their users?

Perfection.

I expect nothing less than perfection from anyone.

Sometimes it feels that way.

Do you mean like, for instance, if I open an issue, what should I expect?

Yeah.

Or if I'm a maintainer, what do users expect of me? What do I expect of them?

Yes.

I have a feeling you want to lean me towards someone.

Well, I have opinions, but I'm curious what yours are.

I mean, I know that one of the things that people dislike with open source

is when you're a maintainer and there's a user who doesn't ask for something,

who doesn't open an issue or make a pull request on something,

and says, could you please look at this,

but who would demand that you look at something,

basically as if they were owed something.

And that is obviously not a great expectation,

which if it works out for the maintainer, sure.

If it doesn't, then refer to the license.

There's no warranty.

The maintainer is not getting paid for any of the work.

They are not compensated, so you should not expect anything from them

except their benevolence, I guess, in a way,

like their empathy and their willingness to work for free

just to make some people happy.

So is that where you wanted to lead me?

Yeah, it kind of is.

I knew it.

I definitely feel the same way.

So what should users expect from an open source project?

And yeah, to me, the answer is you shouldn't expect anything.

But that's obviously not great if you're just like, whatever,

I don't care what this project needs.

Obviously, I don't think that's the right answer either.

But I think the question for me is what do you want out of the project?

If you put an open source project out there,

if you publish your blog as an open source project,

what should people expect from you?

Clearly, that's kind of it.

It's like, this is my blog, and you can look at it,

and you can copy some of the code if you, whatever,

put the license in the right place.

But that's it.

People don't really expect much more.

But somehow, when it's publishing a library or a framework,

people can start to expect that they can set the agenda.

I don't think that doesn't feel good as a maintainer

when that's the vibe you're getting from somebody.

But at the same time, if you create a project that people are depending on,

then I think if you want that to be a sustainable thing

that people are going to continue to engage with,

you are somehow going to need to earn the trust of users.

So that's how I look at it.

It's like, what do you want this project to be?

And it's totally fair if somebody wants to make a project

and ride off into the sunset.

That's totally fine. They're allowed to do that.

And I don't blame an open-source maintainer who does that.

But I think that everybody's going to have a better experience

if they can set those expectations.

If that's what you're doing, then say, hey, this is it.

This project will never have any more commits.

Don't bother opening issues because I'm not going to look at them.

I think you should express that.

Which in GitHub you can do through archiving, for instance.

Yeah, right. Absolutely. Yeah.

So I think there's somewhere in between those two extremes.

But either way, I think setting expectations is a good thing.

And I think...

So for me, with my open-source projects,

I often find that things work best

when the roles are operating a certain way.

So I don't see my role as an open-source maintainer

as being to do everything that everybody wants for the project.

And in fact, I couldn't if I wanted to.

Because if I did everything that everybody wants for a project,

then one person would want this,

and another person would want another contradictory thing.

So it's literally impossible.

And that's one thing that I, as a maintainer, really appreciate,

is when people recognize that I am, as a maintainer,

balancing conflicting desires for a project, conflicting directions.

And so while somebody might have an opinion

that a particular direction is good,

and I want to hear about that opinion,

I really appreciate it when people recognize

that it is one opinion that I'm going to need to balance out,

as somebody leading an open-source project,

with my opinions and other people's opinions.

And theirs is just one possible direction.

So I really appreciate that sentiment,

because if people are coming at it in that way

where they expect their preferred direction to be executed on,

then it's giving you a whole other hurdle to have to jump over,

where now not only do you have to potentially work on something,

but you need to do all this extra effort to communicate that

and set those expectations.

So when people make it clear that they are not expecting you

to do whatever they're asking for,

it just makes it less work for the maintainer.

So that's one thing you can do as a contributor,

is make it clear, like,

I'm just making sure these options are there for your consideration.

I don't expect you to do this free labor.

I don't expect you to choose my direction.

But I wanted to put this out there for your consideration.

So, Lint, I find it really nice when people are thinking about it

as not just, like, what should you do as a maintainer,

but how do we make this project operate smoothly?

And how do we make sure that this project

is kind of having all these great ideas presented

so they can be considered?

I feel like that touches on something

that I quite enjoy with my projects,

or at least the feeling that I get with my projects.

I feel like everyone who interacts with mine,

they all want, just like me, the best from the project.

And we all know that that is made of trade-offs.

So some people might say,

I would like to have this,

and then I respond, or other people respond with,

well, if that is true, or if you want this,

then you're going to have a problem with this situation,

you're going to have this to handle as well.

Plenty of trade-offs to think about

and to figure out the best solution

that works for the most people,

or a custom way that works for you

but will not work for others.

That might be a solution as well.

Yeah, I just feel like people have this understanding,

which I love.

If you have interacted with me on ElmReview

in any way, shape, or form,

you're a part of this.

And I really appreciate it.

People are thinking of what is best.

And me, myself, even though I'm the maintainer,

I am just someone with one opinion.

In practice, I will probably make the end decision

because they're my projects,

but people are allowed to fork them.

But I am successful at convincing people of my opinions

that they're not totally wrong.

And sometimes I'm just convinced that that can also happen.

And I'm really happy when I get convinced as well.

So that feels good.

The expectations I have with people

who interact with my projects

is that we will have a conversation.

You are submitting an idea, a bug report,

and fixing or adding that feature

is not necessarily going to be simple.

So let's talk it out.

Let's figure out a solution.

And let's implement it.

And that implementation part might be me by me, you,

might be in a few years from now.

I am spread thin,

and I'm not doing this full-time

because Meta is not doing Elm and is not paying me.

So I'm happy that I'm getting these interactions.

And that's why I feel like I have very good interactions

with the Elm community, the open source.

Yeah, that resonates with me a lot.

So, you know, like the recognizing trade-offs,

recognizing that the timeline,

like users of an open source project

don't get to dictate the timeline.

That's not the role of the user.

And they also don't get to dictate the agenda

because, as you said, like they can present trade-offs,

but ultimately, like the person leading an open source project,

they're going to come to some conclusions

that might be different than somebody else.

Many times there are different ways

to approach an open source project.

And I think open source projects work best

when they recognize that, to me, a project is a perspective.

You can't try to incorporate every perspective into it

because that's just watering it down.

A project is choosing a perspective

and committing to that.

And I think they work best when they do that.

And I think open source projects work best

when the communication also recognizes that.

When you say, this project goes with this approach.

The approach you're talking about here

sounds like a totally valid set of trade-offs,

but here are the core values that

are laid out for this project.

Here are some examples that show that.

Here's ideally where some of these values are written down.

Or let's write them down now because I'm

realizing that we have these values for this project

now that this might not be aligned with.

And I think the more somebody depends on a project,

the higher the stakes are.

So if you make it a little extras helper package

in the Elm ecosystem, if somebody

has a different perspective on it, then you say, hey,

that sounds like a great idea.

It's just not what I see for the vision of this particular

extras package.

So somebody else can go and make another version of it.

Maybe it starts as a fork.

Maybe it's a totally different thing.

The stakes are very low.

If you're talking about the programming language itself,

Elm, the stakes are very high.

And I think that emotions can run high as well when people

are saying, I depend on the future of this project

because this is the language I'm using.

Not only is it the language I'm using,

but it's a highly constrained language with the philosophy

of not providing escape patches.

So if you don't provide an escape patch for me,

or if you don't provide a path for me,

then I'm highly dependent on that.

So it feels more emotionally charged in cases like that.

Yeah, I think it's important.

Well, I don't know if it's important.

I think it's helpful, very helpful,

when projects convey their goals and their non-goals,

which you kind of said with the perspectives.

Like my goals with Elm Review is to have something,

blah, blah, blah, that is blah, blah, blah.

And for my goals, but some of what people can perceive

as goals are not goals.

Like I don't want to turn Elm Review into a language server.

That is a non-goal.

Maybe that will evolve.

Who knows?

I don't think so.

But at the moment, there are non-goals.

And the same thing is for extra packages.

The same thing is for Elm.

Like some of the goals for the Elm language

is that we make something that is really maintainable,

easy for beginners, and fun maybe in a way, delightful.

And those are the goals.

If something makes those goals disappear,

like adding a new feature that makes error messages really

hard to read, type classes, for instance,

is one example that I've heard of multiple times.

Well, that conflicts with the goals.

So the trade-offs have to be, like the benefits you get

from adding such a feature have to be really high in order

to compensate the loss of error-friendliness.

But something that is a non-goal,

like for instance, having direct FFI,

direct interrupt with JavaScript,

is not a goal of Elm.

You have to go through these escape hatches, ports,

that are available.

And they are a goal of Elm to set up a nice barrier

around your code.

And that's the way that things were thought of.

It is not meant to provide direct FFI,

unless that happens to be easy, nice,

and without any judgments to other features.

Right, like guarantees, which is a huge part of the language.

Safety and guarantees.

So I'm sure, for instance, Evan would be all for type classes

and FFI if we didn't lose the guarantees,

and if we didn't lose the ease of use of the language.

Exactly, yeah.

So if someone can come up with solutions to that,

then that's probably going to happen one day.

If they don't, or if they conflict too much in trade-offs,

it won't.

So yeah, defining your goals and your non-goals,

that can help people know whether they even have

to suggest an idea, or how much they have to push it,

or if they get pushback, like understand,

we're not going to go with this approach because we have

these goals.

And I think that helps explain it.

I don't know if I make my goals clear enough with Elm Review.

I'm thinking probably not, but who knows.

What about you for your project?

I mean, I've definitely made an effort to lay out my goals,

and I do sometimes reference them in poll requests or issues.

Sometimes people will say, hey, it would be really great

if ElmGraphQL could support aliases.

And I'll say, well, if there were a way to support that,

that was in line with these goals,

then that would be great.

But I've found that it makes it a lot easier to communicate

when it's all around these goals.

Like, you know, there's something called nonviolent communication.

Sometimes people call it compassionate communication,

which interests me a lot.

What did you say?

What did you call it?

And the basic idea of it at the core is that you're basically

recognizing that everybody universally has certain universal needs.

You know, a need for entertainment and a need for ease and peace

and things like that.

These are basic core human needs that we recognize in everybody,

and it's not something we would dispute.

The need for rest.

But just because somebody has a need for entertainment

doesn't mean they can say, hey, Jeroen, do a dance right now.

Because, well, okay, maybe you can.

I am doing a dance right now.

He's doing a dance.

Pseudo-Jeroen, do a dance right now.

But basically these needs, these universal needs,

don't have a specific person, place, or time for how to fulfill those needs.

So you can still recognize that the need is there.

I have a need to be entertained, but I can't require you.

It's no longer universal when I'm requiring you right now

to meet that need for me.

So in nonviolent communication, that would be called a strategy.

That would be one strategy to meet that need,

but there are multiple strategies to meet the need for entertainment.

So I see it as very similar in open source,

and that's really helped me navigate a lot of these open source communications.

I mean, not even communication, but just receiving requests

in an open source project is like understanding,

okay, I get why somebody might be dependent on this particular project.

And so what is their need?

They're trying to solve a problem.

But similarly, this happens a lot in communication with communicating needs.

Often the point of conflict in communication is when we try

to demand a particular strategy.

I say, you're in a dance right now.

If I just instead said, like, oh, man, I could go for, like,

something fun and entertaining right now.

If I started with that, then we could explore different ways,

different strategies for meeting that need,

and we would have a much easier conversation.

And I feel it's much the same thing in open source.

If we can start with the universal needs, it just reduces the conflict level

and it makes it less stressful for the open source maintainer

and the user, I believe.

For example, I think the user, I want to hear what is their pain point,

what is their experience, what is the problem they're solving.

But often a request, a GitHub issue, starts with this project needs this,

this project needs to do this.

If instead they said, context, I'm using this project,

I'm trying to solve this problem, I'm not sure how to do it,

this is what I tried, this is what I ran into, possible solution.

What if you had an API that allowed you to do this?

And that gives the open source maintainer or somebody else

who is looking at the issues for the project the opportunity to perhaps

the solution takes the form of, oh, well, here's an API that maybe

you haven't tried.

Why don't you try using it this way?

That might solve your problem.

Or maybe there's another API, the API could take another form.

Maybe we could explore that.

So now it's an exploration and the tensions are less high because it's not

like my way or the highway.

We can explore options together without feeling like it's winner takes all,

zero-sum game, one of us is going to get our way and one of us is not.

And also, even if you went with this project needs this new feature

and the maintainer is like, okay, sure, I'll add it.

Well, maybe the feature will not be what the person requested in the

first place or exactly like, oh, no, I actually wanted it to return

this value when this argument is given.

Oh, but that's not what I understood.

But if you start with a problem to solve, then things become clear.

I mean, just like in an open source project, at work they tend to say

like, don't come up with, don't present solutions, present problems

and present ideas.

Exactly.

And as you mentioned earlier, there could be different ways to address

the underlying problem or maybe solving that problem is not in the scope

of the project.

Maybe it's a non-goal of the project or maybe it's a goal of the project

but it's not a goal for the maintainer or the maintainer doesn't have time

to work on that or doesn't have the motivation to work on that particular

thing.

And that's okay, too.

And I do think I'm not saying that maintainer, I mean, obviously I believe

you and I have put in huge amounts of our free time to trying to do things

in response to requests people have made.

Right?

So we're obviously not opposed to responding to people's requests and

building something for them.

But I think it just is really healthy for a project to recognize that, hey,

you can request something and I can say, hey, that sounds like a great idea,

pull requests are welcome.

Or maybe I decide to build it.

And I think for me, especially like as, I mean, I have a lot of open source

projects.

I get a lot of feature requests in my inbox.

And I can't, I literally can't do every single feature request everyone puts

in my inbox.

It wouldn't, if I did, I would implicitly be saying no to somebody else's

feature request because by starting to work on something, I wouldn't have time

to work on the other thing.

And that's even if I'm working full time, like literally, it's just not

possible.

When you say full time, do you mean only eight hours a day?

Right.

Probably not.

And not on weekends?

Come on, put in some effort.

Yeah.

I mean, often not.

And even then.

And, you know, so I think it's, I think it depends on the type of issue,

right?

If there's like a blocking issue, it's a core feature of the framework and

it's blocking people from solving basic use cases with the tool or library.

Right. Obviously that's going to change your prioritization on it compared to

some nice to have feature.

Hey, this would be a really handy thing to have.

And in cases like that, I'm much more likely to say, hey, that sounds really

interesting.

I would be glad to like do the work to review a pull request and then for the

rest of this project, maintain this code, which is actually a very large cost.

Right.

Like when you're, when somebody is, it's not free to just pull in somebody's

code because, oh, they wrote this code.

When somebody writes the code, you're now committing to continue to consider

how that feature affects the project.

So any new features that are added, you need to consider that feature and how

it interacts with new features you're adding or new bug fixes you're doing.

And reviewing that code is not free.

Somebody might make a pull request that has several subtle bugs.

Right.

So it's, it's actually, you know, there's less investment needed to make a pull

request because you're not taking on responsibility for the project's long

term.

Like if somebody makes a pull request and there are bugs that result from that,

are they then going to fix them?

Or are you going to revert the feature if you find that there were bugs with it?

Probably not.

You might be spending some of your weekends and evenings fixing that bug,

which actually happens to me frequently.

Right.

So it's, I think it's really good to recognize that open source, there is a

cost to, to it.

It's not just reviewing a pull request, but to, to taking on new scope.

So I think it just helps to recognize, to have empathy for that, you know?

Yeah.

I feel like some of the best features that are requested and which will

motivate me the most is the ones that I want myself.

Like for instance, I make Elm Review and I'm a user of Elm Review.

And there are some people who say, well,

it would be nice if we could make a rule that does this,

or if there was this rule.

And I'm like, yeah, I want that as well.

Like the no news record fields, for instance.

Doesn't exist, would be amazing to have.

And it's more likely that people that that will happen if you get me on board

with the, the intent of your, with your idea.

And me as a maintainer,

I want my project to work as best as possible for my users because empathy,

I guess.

So if there are bugs that are, that I can solve, then I will solve them.

If there is a pull request, even better.

But yeah,

if you get me on board because I want my project to be as flawless as

possible,

and,

or you want a new feature that I also want because I want my product to be

as useful as possible,

then that's going to give you the best changes to, to get your idea in.

I don't know how you can affect what I want though.

But yeah, I guess that's part of the goals of the project as well.

Like you probably know where I want to go in a way where you can kind of

guess. And well,

through discussion we will figure out whether I do or I won't.

Yeah.

I would say for me, like one,

one thing that makes me far more likely to either roll up my sleeves and,

and implement something myself or,

or,

or be interested in somebody making a pull request about a particular feature

and wanting to whatever,

have Slack messages coordinating that and that sort of thing is how much are

they invested in it? Like if somebody,

if somebody opens a GitHub issue and says, Hey,

this would be really cool.

And there's nothing laid out of like, what problem does this solve?

Why do I have this problem? What are possible trade-offs?

What are possible downsides to this new feature?

What are possible approaches and implementations?

Like I'm not very likely to consider a feature request if it's just a sort of

not, if it's not giving me that motivation of why,

why is this important? It's like, well,

if you don't care enough to really lay out what problem this is solving and,

and really dig into like, how would you do this?

Why should I be interested enough to do that for you to,

to flesh out this feature idea more deeply?

So I'm probably not going to prioritize that over something else where someone

has done that.

Are you saying that if you get a issue saying as a title,

add feature X and that the comments of,

of the issue says no description,

the when it's empty, but you're not getting passionate.

Like you don't have a fire burning and causing you to roll up your

sleeves and get to work. Really?

I say that not, not just as a, like, you know, old man yells at cloud.

Although partially I also say it is that, but I also say that as like,

and I actually make an attempt to,

to communicate those types of things on issues and say, Hey,

if you think this is interesting, I'm,

I'm willing to like accept a pull requests.

If you can help me understand like what problem this would solve and how you

would do this and how the trade-offs are going,

going to look and how it's going to interfere or not interfere with this

feature, you know? So I try to communicate those things.

And actually pretty often people do say, okay, great. Yeah.

I'd be happy to do that.

And they write out super thoughtful comments and get some prior art and show

me how other projects have solved this problem and maybe make a pull request

or make a pull request that has some failing tests. So it,

I think giving users the opportunity to do that and communicating like what,

what you need as a maintainer is really good too,

because at the end of the day, as you said, like, I mean,

I think open source is a tool for making our projects more accessible,

but also like helping people more and contributions are a tool for that.

And the way we build our open source projects,

the way we communicate in our open source projects are tools for that,

because at the end of the day,

we're putting time into this because there's something we care about putting

into the world.

We care about being able to have more guarantees in an Elm project by doing

more powerful static analysis. That's like,

I believe that's something that you care about at your core and managing an

open source project effectively leverages you to be able to do that better,

to, to put that vision into the world in a more effective way.

So I think communicating can help people do that. And I think also like,

so I often think about like the role of a,

an open source maintainer or lead on an open source project as kind of like a

CTO for, for a mini company. And as that company scales,

the role of the CTO also changes. So, you know,

if you're CTO in a company of two, then,

then you're, you're the developer of the company, right?

You're also making technical decisions that if that company were to take off

and become a company with a hundred developers, a thousand developers,

those technical decisions are going to impact the long-term roadmap for the

company and the long-term success technically of the project.

So that's the hat I'm wearing early on in an open source project when I'm

maybe not even sure it's going to be successful, right?

Maybe it'll be a failed startup. Maybe it'll be an open source project that

nobody uses and, and that can happen and that's okay. But,

that's the hat I'm wearing when I'm early on in an open source project.

And as the project scales,

I tend to play a more strategic role and I'm thinking about how do I make

technical decisions? How do I help mentor people? You know,

how do I get on call?

Like maybe I'm going to be spending more time getting on video calls with

people who want to make contributions to help them,

to pair with them to help talk through certain trade-offs or technical

questions.

And I'm also like thinking really hard about high level strategic choices,

like what's our testing strategy going to be?

Are we doing some snapshot tests? Are we doing fuzz tests on this?

Like what's going to ensure quality and make that high bar for anybody

contributing to it? Not just me, because if it's a,

if it's a big project that a lot of people depend on,

I want to make it easy for a lot of people to contribute to it.

And so that's something I'm really focusing a lot of my time on that.

I think I uniquely need to be focused on as the CTO of the open source

project as it grows.

Right. So when you get someone to contribute a pull request,

how much do you care about like the quality of the contribution?

What are the types of things you're thinking about with quality?

I'm curious.

So whenever you get a pull request,

you will wonder a few things like is it code? Does a code look okay?

Does this handle all the different cases?

Are there any obvious bugs that can be found? Is it co-style okay?

Like all those things. Which ones do you care about?

Which ones do you not care about?

Yeah. I tend to be fairly trusting about contributions.

I look for ways that a contributor can show me that they're,

that they're taking ownership of those considerations.

And if I'm not being given signs of that,

then I'll ask to be communicated with in a way that gives me signs of that.

Like, what are the things you're thinking through here?

Like, can you lay that out for me?

Because in general, I don't want to micromanage people's contributions.

I generally want to trust them and give them some level of ownership.

And, you know, there are certain quality standards that I have for the project

that are pretty superficial to check.

Did you write tests? Is the CI green?

Right. Like, but I try to automate those as much as possible.

Like I'm not going to go through and check code style and things like that

because Elm format in my CI and Elm review in my CI and my approval test suite

and my unit test suite do that.

In the pull request, I am going to say, hey, I noticed this doesn't have tests.

I'm not going to merge this until it has some tests.

But other than that, I generally like to trust people.

But I do try to make sure that we're having the conversation where I see

that they're taking ownership and considering all these things.

Because I want to give contributors ownership.

Like I don't want to take that away from contributors.

I want to allow them to have some flexibility in how they approach something

because it's their thing.

They are contributing it to a project I maintain.

And so that does mean that I'm committing to taking on maintenance of it.

But I also want to trust people.

Yeah, I haven't thought of the ownership aspect and considered it.

But otherwise, I do pretty much the same thing.

Like as long as the CI is green and as long as there are tests,

I'm usually okay with it.

Sometimes if I'm worried about something, I will ask them to add a few tests

and to fix them if needed because they need to be green.

But other than that, especially if it's like a new contributor,

if the code style is not to my liking for the things that Elm Review doesn't report

or Elm Format doesn't report, I will tend to let those pass.

I will merge their pull request and then I will go fix them afterwards.

I feel like it's hard to get pull requests in sometimes

as someone who is like a first-time contributor.

So since the first time is the hardest, let's make that one easier.

We still want something of high quality or of decent quality,

but I will try to make that easier on the person.

And if that puts some strain on me, I'm fine with that.

And then if that person contributes more, then I will make more comments

because they will also understand how I work, how the project is written,

and we want things to be consistent.

They will understand the various trade-offs.

But on the first few pull requests, that's maybe not the essence of the contribution.

Right. Yeah, that makes sense.

Yeah, I'll definitely help push along first-time contributors as well in that way

where if there's something that they just were missing, like,

hey, there's a module that abstracts away some of these details

that we use in this code base, then I may make a commit on the PR

or point them to it depending on how involved it is.

And yeah, regarding the ownership, I think the more you give somebody your trust

and ownership over something, the more they step up to it.

That's just something I've noticed.

I definitely feel that way as well.

So I think as maintainers, we can really set the tone where if we're not trusting

our contributors, they feel that, and they feel constrained and like,

we're going to check everything and basically redo their work.

So they don't really look at the big picture because that's not what they're being asked to do.

They're being asked to just give some code, but we're going to be micromanaging it anyway.

So why would they be thinking about the big picture of how it fits in and everything?

There's a TED talk I saw by this author of a book.

I think it's called Turn This Ship Around.

And the author was a commander or admiral or something of a nuclear submarine, I believe.

And his first day on the job on this nuclear submarine, he actually was given a different type of vessel

than he thought he was going to be commanding.

And so he started to give these orders.

And people would look confused sometimes and he'd say, what's wrong?

Is there a problem?

And they'd say, well, we don't have that unit on this ship or something like that.

And he would realize when he was giving orders, people would sort of shut off their thinking

because they'd just be like, well, it's my duty to do what was asked of me,

even if it doesn't really make sense.

Because you're not being asked to think about the big picture.

And so he ended up realizing that if he was going to successfully run this vessel,

he would need to do things differently.

So he started to say, it's my intention to submerge the vessel.

And what am I going to ask you?

And they would start thinking about his goals.

So, OK, well, is everybody going to be safe?

And whatever. His checklist of things.

So that was his way of mentoring everybody to make sure these are the,

this is the vision that I'm setting as the captain.

But I'm trusting you to execute that and take ownership over your part of it.

And I'm setting the high level vision.

And I think that that's a really good way to approach an open source project as well.

Yeah. Yeah, that resonates with me as well.

So when is an open source project done?

When the maintainer leaves?

When there's no maintainer left?

When the maintainer gets hit by a bus?

Apparently that's a thing that happens with maintainers.

Yeah, quite often.

Actually, I don't know any maintainer who's been hit by a bus.

Definitely stay away from buses, though.

No, no, no. Use public transport. It's good. It's good.

Be on the bus. If you're on the bus, your odds of getting hit by a bus are lower. Probably.

I mean, if you're on the bus, then you're probably trying to flee someone with a gun

and you jumped from a bridge on top of the bus.

Maintainers lead interesting lives.

I guess. When is a project done?

Honestly, when it reaches its goals and when it's perfect, in the sense of

whichever author said perfection is attained when there's nothing more to remove.

Something like that.

Which is very far from where our projects are, I think.

I mean, you have some projects that could be considered to be done or close to done.

Yeah, absolutely. I mean, and I think it depends on the scope of the project, right?

If it's a project that, I don't know, if it's a project that parses a URL or parses an ISO 8601 date, right?

Like, is Richard's ISO 8601 date parser package done? I think it pretty much is.

And I think that sometimes a project can be done when it has a particular vision.

It sort of meets that vision.

And then sometimes it's better, rather than trying to reinvent that project,

sometimes it's better to create a different project with different goals,

rather than completely transforming the goals of that project.

But I think that happens quite often, and I think that's a natural part of the cycle as well.

But yeah, for ElmGraphQL, for example, I think it's at a phase where it kind of delivers what it promised.

And small improvements come up, and I do actively work on it,

and merge pull requests and small bug fixes come up.

But it's much less frequent, and the core features are there, and they're pretty much solid.

Not that it's... I don't think it's a perfect project, but I think it's a dependable project.

You can basically use it to do what it promises.

So it's more in maintenance mode, I would say.

Not that I could never ever feature.

Yeah, because the project is doing pretty much all that it needs to.

Right.

So yeah, ElmGraphQL wanted to allow you to interact with GraphQL endpoints in a specific way.

And as long as you reach that goal, and no one finds anything that needs to be added,

like new support for ADSes maybe, I don't know if that's a new thing, then yeah, you're done.

Right.

Or close to done.

Like, yeah, maintenance, fixed typos in the documentation that no one has seen before, that can happen.

Nothing really big, right?

Yeah, and I think that's...

I mean, the scope of ElmGraphQL is definitely like...

I mean, it's a non-trivial project, but it's also like a pretty clear scope.

Like frameworks like ElmPages, it would be a lot harder to ever call ElmPages done.

Because it's a framework.

Because the goal is much bigger.

I mean, you say that, but for instance, Backbone, back in the day,

which I've never used, but I've heard people...

I went to a Backbone meetup once in Paris, and they talked pretty much about anything else.

I didn't learn any Backbone there, because Backbone did what it had to do,

and they talked about other projects that worked well with Backbone.

I think, for instance, Lodash or something.

So the project was simple enough, in a way, and it did what it needed to do.

But it was inadequate for some use cases, and therefore died out.

That might be one of the reasons why it died out, I don't know.

But yeah, it is possible for it to finish, if you lay the right groundwork.

Or don't know how you say that.

Yeah, if your vision wants to allow users to do an enormous amount of things

that you're not doing, then yeah, you're far from being done, right?

Yeah, I think it's extremely valuable to put a lot of thought into how you scope a project.

Because, at the beginning of the episode, we talked about what should users expect from maintainers.

And of course, the software comes as is.

If you really don't want a big commitment, then don't take on a large scope of the project.

Try to narrow the scope down.

Or at least communicate what you plan to contribute to it over time.

But I think, we talked to Ryan Haskell-Glatz about his approach in LMSPA

with just trying to not make people blocked on his technical decisions by providing extension points.

Where the framework isn't responsible for everything they want to do.

And Ryan was even talking about it, he's almost afraid of taking on that responsibility of

users don't have a way to do things unless I give it to them.

And I think that's very wise.

And I think that's a good way to run a project.

You should really consider if that's what you want to do.

And avoid it if at all possible.

Yeah, LMSPA is one of those projects where if you limit what people can do,

it's going to kill the project or it's going to frustrate users.

Right.

If it's an auctioneering tool, then that's a lot more accepted, I would say.

Exactly.

For instance, for Elm Review, I feel like if I don't allow rule authors to make something,

then it's a shame.

If it's something that could have been useful, then it's a shame, but it's okay.

If you do that with Elm Pages or LMSPA, that's not going to float.

Exactly.

So one thing we haven't talked about yet at this point is how do you get feedback from users or from contributors?

So, I mean, we come up with plenty of tool or feature ideas,

and we know we're not always perfect in our decisions.

And sometimes it takes us years to think of some things.

And therefore, we need feedback.

We need to know what people will want to use something for,

and we need to ask them their opinion.

So how do you go about that and doing that?

Yeah, well, I love feedback, and I think that feedback is essential for the health of a project, in my opinion.

And it's a role that users are uniquely able to play.

Of course, we can give ourselves feedback, but we're kind of biased in the way we perceive things.

Yeah, I mean, we are still users of our own tools.

We are users.

Thankfully.

Otherwise, like, yeah.

But there's also a huge value to getting feedback from different uses of the tool.

And so I think it's an essential process.

And I mean, for me, the first thing that comes to mind is just ask.

Ask for feedback.

I try to ask for feedback all the time.

Like, you know, I would love to hear what you think of this.

And I often ask that on Slack when I release a new feature.

Also in GitHub issues.

You know, that's another like if somebody opens an issue, then again, that conversation of somebody opening an issue and saying this needs to do this,

and then peeling that back and saying, well, what problem are you trying to solve?

Sometimes that turns into understanding the experience people are having more.

What about you?

Yeah, I guess nowadays there's a sufficient number of people who roam the Elm Review Slack channel.

So there are people responding to my questions, and that feels good.

Unless they're very technical.

My questions, I mean, and I'm the only person who cares about this thing.

Then I don't always get answers.

But usually, yeah, just ask questions.

I do have ideas that take months to complete.

And then I write an RFC or write some kind of blog post in my notes, you know, and then I make an issue of that.

I don't do that nearly enough.

I have plenty of ideas that I should make available for people to comment on.

And maybe they would just add like one simple comment.

And I would be like, oh, yeah, that's a solution.

But that just takes a lot of time still, right?

Just to get it to a point where you can share it.

Yeah.

For instance, like the other day, I was like, here's an idea.

I've thought about this for a while.

I don't know if it's perfect.

And it's a very long thing.

I'm like, ah, I don't know if I'm in the mood of writing, of adding an example to this.

Like a few use cases.

Let me just get it over with and send it.

And a few minutes later, someone comes down and asks, do you have any use cases or examples for this?

Like, ah.

Well, OK, well, now I'm going to add those.

But at least the idea will get out.

So, yeah, it takes a long time, especially to present ideas in a way that's still, that are still open for discussion.

Right, because I don't want to have a problem that I want to solve.

I have some solutions I have in mind, but I don't want to close it to other solutions, which could be better.

And I hope are better because I'm not necessarily entirely satisfied with my own solutions.

And sometimes the solution is like, I have an idea.

I have a problem.

Here's a solution I'm suggesting.

And maybe the result is that is a pretty bad solution.

Let's just not do it.

Let's not solve this problem.

Yeah, I'm a fan of the RFC process as well.

I think like opening up a GitHub discussion thread and just saying, like, I even like it, even if nobody comments, which happens.

Like, I find it useful as a document to outline my thoughts.

And as I'm writing it in a way where I'm trying to present it in a way that's easy to understand for other people and that, you know, lays out all of the possibilities.

So people can say like, hey, here are three different paths we could go down here, I think, are the tradeoffs of all of them.

I might be missing some, but that process of trying to like exhaustively brainstorm all of the different approaches that are possible and all of the tradeoffs for them is valuable in itself.

And it's to me, I believe it's more valuable when I believe I'm communicating it to real people, not just in my notes.

Yeah, it's like when you have a duck, right?

And you're explaining your problem to a duck.

Right, right.

Yeah, exactly.

It's different when you're trying to communicate it and make sure it lands.

And often I do get amazing discussions where people are sharing their use cases and ideas.

So yeah, RFC processes are really valuable.

Yeah.

And regardless of whether they're in your notes or on GitHub, if you've written them down and you come back to it a few weeks or months after, or a few hours maybe even, you're going to come up with new ideas.

So it's always quite interesting to put it in writing in a way that is well articulated.

Now you can come up with new ideas.

Right.

And you might forget all the things you probably will forget, all the different possibilities you considered.

And then down the line, a couple of years from now when somebody says, hey, why didn't we do it this way, then you dig through, you search through GitHub and you find that RFC and you're like, oh, actually I talked about the cons here.

And maybe you missed a consideration or maybe you already thought it through and you just point to that.

So having those historical documents can be very valuable.

And now I have FOMO, I'm wondering, did I do that enough?

It's a good habit.

So one thing I noticed with, and I'm sure you have as well, noticed with the Elm community is that we like to tend to batch work.

Evan made that quite explicit to talk about batching work.

And I feel like we do it too.

I don't know if we do it for the same reasons.

And I was wondering, so one thing I really don't like is breaking versions.

I say I really don't like them.

I just mean, I tried very hard to avoid them because, especially in the case of Elm Review, there's a lot of packages that depend on Elm Review.

So if Elm Review releases a new major version, then all of them need to be updated.

Some of them are mine, which I can do.

It will just take me a few hours more.

But some of them are for other people, and that will take longer to, that will cause others pain to upgrade.

And I want to avoid that as much as possible.

So Elm Review has not had a major version since April 2020, which is quite an achievement in a way.

I know I will want a v3 at some point.

I just don't know when.

I wonder whether this fear of breaking changes causes us to batch work.

Because Elm enforces semantic versioning, and that means that there are some changes that I can't do without making a new major version.

And if I want to avoid them, I need to think really hard about how this feature will be used in the future.

How this feature will affect other things.

And in that sense, I need to carefully think about things.

Make RFCs, write down notes for months or years.

And once I feel like I have everything thought through, then I can implement it.

And I'm sure get some discoveries still.

But I wonder, if you care about avoiding breaking changes, do you batch work more?

What do you think?

I think you do. I think that's definitely one reason for batching work.

I don't even think it's the main reason for me though.

I think the main reason that I tend to batch work is...

First I'll say, if there's a pull request that's a typo in the docs, then I'm just going to click merge.

Because I want to get that off my radar as fast as possible.

Because it's just like, having it sitting around...

There's this idea in getting things done, which we talked about in our productivity episode, of the two minute rule.

Which is that, if you can complete something in two minutes or less, then managing that in your to-do system is going to be more costly than just doing it.

Because you accrue some sort of tax by having more things in your system.

So I definitely try to push things through when there's not a lot to think about.

But when there are deep considerations that I need to go through, then sometimes those need to sit with me for a little bit.

And I need to sleep on it, and I need to read through a bajillion RFCs that other open source projects and other language communities have made.

And watch some conference talks, and read some code books, and read some non-code books, and drink a Mai Tai, and think about these things.

Specifically Mai Tai?

It couldn't hurt.

I just don't know what it is, so yeah, maybe.

Try one out, it's good.

I think there's a lot of background processing for decisions for me.

Have you heard this story of the man who asked for a painting of a horse?

And so he asks this painter, he says, I want to commission a painting of a horse, it's like a birthday present for someone or something.

And the painter says, okay, yeah sure, I'll have that for you in a month or so.

And he goes back to the painter, and the painter says, are you done with the painting yet?

No, no, no, I'm still painting it.

And a couple weeks go by, and the painter says, hey, are you done with it yet?

No, no, no, I'm still working on it.

And he keeps going back, and he's not done, and eventually he goes back, and the painter gets so frustrated, he says, okay, okay, okay.

And he gets out an easel and paints a horse, and then gives it to him.

And he's like, well, if you did it so quickly, why didn't you just do that before?

And he says, well, I've been, you know, observing horses, and watching how they run, and thinking about them, and dreaming about them.

So all this time, he was working on painting the horse, even though his brush was only touching the canvas for however long, that was part of the process.

And that's how I feel with coding projects, is like, it needs to sit with you, and you can't just juggle a hundred different things and really consider them.

Like, you have to really get that cash into your brain about all of these things you're thinking about.

And so it's more efficient in a lot of ways to, like, think about a related group of things in a project before moving on to something else.

So that's how I tend to think of it.

So is there any feature that I have to rush you about?

You know, I actually don't mind when people politely ping on something, too.

Because for me, like, it is valuable to know that somebody actually cares about something.

Yeah, definitely. It gives you some motivation, like, oh yeah, yeah, no, I want that too.

At least for me, because I want those things as well.

Yeah. Or if somebody's blocked, I want them to be unblocked, and that's valuable information.

So, you know, sometimes it's okay to just say, hey, just making sure you're, you know, having lost track of this in a polite way.

Yeah. Don't write a comment saying ping, but...

Otherwise it's fine.

Yeah. Yeah.

All right. I don't know what else we can add to this conversation to maintain it.

Are you saying this conversation is done?

This conversation is done.

Well, then you're in. Until next time.

Until next time.