If you're using/contributing to a open source project that is famous for it's non-community development and BDFL leadership style, it should come as no surprise when that continues.
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.
If you're using/contributing to a open source project that is famous for it's non-community development and BDFL leadership style, it should come as no surprise when that continues.
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.
> 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.
> 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.
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).
I'm describing how I experienced it as a young developer at the time. It was a weird combination.
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.
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.