The call for "If you're not happy you should fork the code" comes because this is a explicit expectation of the Elm core team and Evan.

What does "open source work" really mean? Open Source talks strictly about the licensing and distribution of the code itself, not the community and everything around. It feels like everyone are having two conversations at the same time. Open source as we currently know it, is just about the code. Open communities (or whatever you want to call it) is a separate discussion, and not needed to "make open source work" as you just have to license your code in a specific way to be open source.

Then we can discuss what makes open communities around open source code work, but I think that's a separate thread.

That's pretty much the central thesis of the article. With detail and examples on exactly what the leadership problem is and why it causes challenges for users.

The call for "If you're not happy you should fork the code" comes because this is a explicit expectation of the Elm core team and Evan.

And yet any attempt to do so is described by them as knifing Elm in the back.

What does "open source work" really mean? Open Source talks strictly about the licensing and distribution of the code itself, not the community and everything around.

What I mean by "work" is that it leads to successful projects. By a variety of metrics for success.

It feels like everyone are having two conversations at the same time. Open source as we currently know it, is just about the code. Open communities (or whatever you want to call it) is a separate discussion, and not needed to "make open source work" as you just have to license your code in a specific way to be open source.

Then we can discuss what makes open communities around open source code work, but I think that's a separate thread.

You have it exactly backwards.

You are right that "what is open source" is a different discussion from "what makes open communities around open source work". But this is the appropriate place for the second conversation. And more specifically for discussion of what it is that the Elm leadership is doing that leads to failure, and what it is that users should or shouldn't do given that Elm is being so badly lead.

It's only a problem for the ones who misunderstand the model. It's not a problem, it's by design. It's explicitly setup so that Evan has the final say in everything.

> What I mean by "work" is that it leads to successful projects. By a variety of metrics for success.

I'm always interested in hearing what metrics people are using for "success", so do please list them so we can be on the same page.

> You have it exactly backwards.

The author is the one using "Open Source" in their article, not "open communities" or "open governance". I understand it can be confusing, but let's not change the meaning of already existing terms.

Do you have an opinion on open source communities that threaten and seek vengeance against their own forks?

> It's only a problem for the ones who misunderstand the model. It's not a problem, it's by design. It's explicitly setup so that Evan has the final say in everything.

The fact that they intended to do a stupid thing does not stop it from being a stupid thing.

The core development team of Elm is an echo chamber of smart people who only listen to each other. When they are working on problems in their area of shared expertise, they should be very effective. But when they step out of their shared expertise they are predictably both ineffective and have no way to discover their mistake.

In this case they know little about i18n and therefore are unable to take feedback from people who know how it works. And there is no way to get them to see their mistake. These faults, left unchecked, will undo all that they hope to accomplish.

> > What I mean by "work" is that it leads to successful projects. By a variety of metrics for success.

> I'm always interested in hearing what metrics people are using for "success", so do please list them so we can be on the same page.

That is a fair question. For me success means, "I can use this to solve my problem, and be able to trust that this is something that will be maintainable in the future."

There are different routes to being maintainable. The smaller it is and closer to my own expertise, the more I can be confident that I can maintain it myself. If it is complex and far from my expertise, I won't.

Maintaining a language someone else built is not exactly the kind of thing I want to do in maintenance. (This is from experience, not ignorance. At my last $job I did exactly that with an internal language. And that language was much less ambitious than Elm.)

> > You have it exactly backwards.

> The author is the one using "Open Source" in their article, not "open communities" or "open governance". I understand it can be confusing, but let's not change the meaning of already existing terms.

You are seriously going to let a quibble about terminology prevent you from understanding what the author clearly meant??

Now that you know what I think that the author meant, go back and re-read it to see if you think I am right. If I am, you can see that what I am talking about is on topic.

But since you want to open up the terminology issue, Open Source BEGAN as a marketing term for a particular software development philosophy BEFORE there was a settled definition for what open source software meant. To this point, one of the founding inspirations was http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral.... Furthermore the practices for how Elm is being developed are exactly against that philosophy. (ESR is an idiot in other ways, but that is a discussion for another time.)

That this started as a philosophy and not a mere licensing term is obvious in things like the free software community's response to the phrase. If you want to dive down that rabbit hole, read https://www.gnu.org/philosophy/open-source-misses-the-point..... (Written by the person most directly criticized in ESR's essay. Ironically, also the person who probably did the most to create the foundation that open source built upon.)

So you learned something today. You learned that, from its very inception, there has always been a lot more to the phrase "open source" than just a licensing definition.

If you're going to bring up the origins of "Open Source", the above is NOT CORRECT.

It began as a marketing term for "Free Software" principles, as it was realised the FSF marketing wasn't convincing people in corporate environments.

From Wikipedia (I think this is accurate):

>> Netscape's act prompted Raymond and others to look into how to bring free software principles and benefits to the commercial-software industry. They concluded that FSF's social activism was not appealing to companies like Netscape, and looked for a way to rebrand the free software movement to emphasize the business potential of the sharing of source code.[35]

Not as a marketing term for Bazaar principles, despite ESR's involvement in both around the same time. Obviously the Bazaar paper added significant inspiration to the movement and to many projects, and informs some people's expectations around Open Source. But I have heard ESR talk about the origins of "Open Source" and it was quite clearly because "Free Software" wasn't getting the message across; the latter was too ethics focused for the corporates.

Btw, you can have Open Source without a Bazaar, and you can have Bazaar-style development without Open Source too (a lot of companies do so without giving it that name).

Note in particular that a lot of people who jumped on the open source bandwagon were people who wrote some free software but did NOT want to only write free software. And there was a lot of messaging around social norms for how projects worked, why open source made sense, and how to do well by it.

Of course they can do that, but then they are not Elm users, which makes them off-topic to the question of what Elm users should do to move forward as Elm users.

> requires a lot less energy and commitment.

We don't actually know that for sure without looking at the size of someone's Elm code base.

Maybe some users also think that Elm is otherwise fantastic and want to stick with it.

For various reasons, changing tooling is not like changing what shampoo you use, except for some language-hopping butterflies who are experimenting with a new thing every week.

> Of course they can do that, but then they are not Elm users, which makes them off-topic to the question of what Elm users should do to move forward as Elm users.

The topic was someone saying in detail, "Here is why I have chosen not to be an Elm user, and why you shouldn't be either." Which means that the experience of people who are not committed to being Elm users is on topic.

> > requires a lot less energy and commitment.

> We don't actually know that for sure without looking at the size of someone's Elm code base.

Fair enough.

Of course in this case he says that he is walking away from an 8000 line project that can't upgrade to 0.19 because of the native code issue. So we know how much code he is talking about, and also know that a rewrite in a new language is simpler than trying to upgrade.

In this case maintaining a fork certainly exceeds the benefit of the project.

> Maybe some users also think that Elm is otherwise fantastic and want to stick with it.

I am sure that there are.

> For various reasons, changing tooling is not like changing what shampoo you use, except for some language-hopping butterflies who are experimenting with a new thing every week.

No, it is not.

However if you will have to make the change some day, then it is probably better to bite the bullet and accept the pain now rather than adding to it for a future date. And if the leadership problems described continues, it is clear that the Elm community is going to fall apart and any project in Elm will dead end.

Therefore if you are an established Elm user, you should be ready to accept that tooling change pain as a question of when, not if.

When someone is saying divisive things, I think it's important to be clear and precise about what they're actually saying. Some of the burden rests on themselves, and some of it rests on the commentators.

And so I think it's important to note here, that I don't think he said the "you shouldn't either" bit. He specifically denies saying it:

> I should also note “Your Mileage May Vary” etc. It would be entirely possible to use Elm and find it adequate for your needs, and therefore never bump into the things I hit very quickly.

What he actually said was, "I definitely cannot recommend it to anyone else." Which is fairly translated as, "You probably shouldn't either."

But he explicitly didn't say that it was inappropriate for anyone.

A good chunk of everything you hear and read revolves around people trying to get others to be like them and do as they do, implicitly so. (Another good chunk is made up of people justifying, explaining and defending themselves.)

This is not obvious to me. Why do you assume the motivation is "to help other users make the same decision" and not "to help other users make the decision that's right for them"? I promise you that some people have sometimes written with that motivation in mind. If any denial is taken as proof of guilt, how do you tell those people apart?

All of these leavers could've maintained that fabled community fork they want with the features they want if they all got together.

Choosing to hard-fork Elm and create lots of internet drama just doesn't make sense compared to moving to one of the above.

Forking a language isn't like forking a tool. Forking gcc doesn't make C any better or worse. Forking C (if you could) would make the C worse.

But "if they all got together" is waving away the difficulty of getting them all together, cooperating, and working together. Open source projects are a lot more difficult to run than you might expect.

Indeed. You pour thousands of hours of work into something and give it to the world for free, only to be met by “give us synchronous IO or we will throw our toys out of the pram!”