That is acknowledged in the article. But the fact is that you can BE open source without doing the things that make open source WORK.
[...] Elm users who are not happy should fork the code --- everything, including the ecosystem's dependencies on an ELM internet domain --- and maybe produce something that is completely self-contained. Software that relies on "phoning home" is a risk regardless of where that is hosted and whether the people are nasty or nice.
Why should unhappy Elm users do this instead of going to a language+environment that they don't have to fork to get something usable for them?
Leaving, even leaving with a long essay like this one, requires a lot less energy and commitment. And being in an environment where you can benefit from the future work of others is part of what makes open source work.
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!”
> The second is that if you advertise something as Open Source, there is a common set of assumptions about what that means, some of which are explicit in accepted definitions of the term.
It seems the "common set of assumptions" is around that people can get involved and actually have impact on the direction of the project, but that's not at all included in the actual definition of open source. https://opensource.org/osd
And I'm starting to see this sentiment crop up more and more recently, where someone open sources something just to share the code, while people expect the maintainers/creators to fit their project to their worldview. I think this misconception is the source of many throwing a fit on GitHub in issues/PRs where the maintainers won't change something based on the user's views.
Open source is and should continue to be about that you are free to fork the code if you don't like the direction. Otherwise, assume nothing from others work they publish for you to use for free.
Edit: I continued reading and found bunch of more passages where the authors understanding of open source seems to be incorrect. Some examples:
> Bu I think this claim is increasingly hard to defend. For me, real Open Source goes beyond a LICENSE file.
> I’d like to see some kind of openness in the development process before I considered something to be Open Source
> It seems that Evan and the core team have forgotten that languages, especially Open Source ones, operate as platforms, and in these platforms contributions from other developers and reputation are critical.
> Fairness must be a central principle in any Open Source project
While I agree that these things are nice, they are in no way required to called a project Open Source. Open Source is strictly about the software that is under the license, not the community/company around it. The creator and maintainers are free to accept/deny any patches they feel like, and project should still be considered open source, as long as the _actual_ requirements of open source are followed.
The author is one of the "core team" members of Django[0]. So, it is safe to say that whatever assumptions he has about open source is not a fantasy and cannot be compared line-by-line to a text book definition of open source.
Why not? The OP claims that his opinions are explicitly mentioned in accepted definitions:
> some of which are explicit in accepted definitions of the term
If the OP is going to make that claim, why should we not expect to be able to find validation for his assumptions in a written definition of open source?
I no way am I going to accept anyone's opinion based on what project they are associated with. If Linus Torvalds says something about open source or free software, I'll read what he says and make my opinion based on what he is saying, not based on that he was the original creator of Linux.
Anything else is just appeal to authority and we would do much better in discussions if we didn't do that.
The article does not require you to share that definition. And haggling over the precise definition of open source does not change their argument one bit. You can say that you use a more restricted definition, and that is it.
Thanks for putting it like that, it's completely true and I agree. Many people have an understanding and expectation of Open Source that not even the definition of Open Source agrees with (https://opensource.org/osd), which is contributing to this problem. That was a bit of the point of my comment.
The article doesn't require anything, but in general, most people see OSI as the organization who stewards a lot of things around in the Open Source world. If people cannot even agree about the definition of Open Source, we're in for a real treat now when companies start to abuse it.
> You can say that you use a more restricted definition, and that is it.
Again, I'm not going by my own vision of Open Source (as the article's author does), I go by the Open Source Initiative's definition of open source, which again, you can read here: https://opensource.org/osd
Looks like I've accepted that it's a broad term used in a lot of contexts. So having somebody give their angle on it before using the term is already pretty good by my standards. But maybe I'm being too liberal here. What parts do you see people expecting in open-source that go against the OSI definition?
(I can't help but note that you and the author write Open Source with caps which does actually suggest there is a specific meaning.)
> It seems the "common set of assumptions" is around that people can get involved and actually have impact on the direction of the project, but that's not at all included in the actual definition of open source. https://opensource.org/osd
To add to that, the OP's argument seems to hinge on Elm "advertising" itself as open source. I don't see "open source" mentioned on https://elm-lang.org/ or anywhere else. I'm curious where the OP thinks Elm crossed the line from having an open source LICENSE file to "advertising" itself as open source.
If the answer is that an open source LICENSE file counts as "advertising" a project as open source, then why use the inflated language in the blog post? Why not say, "If you [release something with an open source license], there is a common set of assumptions about what that means, some of which are explicit in accepted definitions of the term?"
Also, explicit in which accepted definitions of the term? The OP seems to be stating that without linking to these accepted definitions that would back him up.
That feels a bit silly - why make a project open source if you're going to get upset when someone forks it?
While you may have a point, language developed with closed process and just the source published in one of the famous code hosting sites need not emphasize on having a "community"[0] if it is not really looking to hear things from the "community".
Good projects die because of bad leadership.
Something seems a bit off in the reasoning. The only reason you can't fork something is that either you don't have all the code, or there is a license problem.
One way not to have all the code is that there is a dependency on specific SaaS server installation, whose source code isn't available. If that's the case with Elm, I missed the coverage of it in the article somehow. I did get the part that the packaging ecosystem depends on a particular server controlled by the Elm project.
1. Well, not a solution for the project, but for some of its unhappy users. The project, as such, perhaps doesn't even feel that it has these problems that require solving.
I can't think of a language or platform that doesn't have some degree of "soft" forking that maintains communion with the language community. It's common for proprietary reasons (linux kernel, anyone?) as well as experimental reasons (e.g. PyPy). So this is an eyebrow raising claim.
At that point, why bother respecting the threat? A forked compiler isn't going to get maintainers? A package depending on the forked compiler isn't going to be maintained? The social cost is possibly something to think about, but if one is set on leaving the community anyways then it's a choice between you choosing to not interact with the community and them (possibly!) choosing to not interact with you.
If you fork Elm, an already tiny ecosystem, you'll realize that the hard part is building the community, not adding your pet features.
Everyone who has threatened to fork Elm has realized this at the end of the day. It's also why people overlook the lack of their pet features: because ecosystem is far more important.
One of my coworkers once edited the elm compiler to remove the native code restrictions, and placed it on NPM. Evan emailed him and asked him to take it down.
There may be more to the story that I don't know, but from what I know it sounds like Evan does care.
The article cites a comment by one of the elm core maintainers where that maintainer says he is opposed to the author forking Elm, and will consider it an attack on Elm's goals if he does. So I think we can safely discard this conjecture.
It's important to remember that they aren't being removed from the Elm community - they can still use the packages, the compiler will still get updates they could presumably rebase their patches on.
Not really, IMO. Forking a project used to be a really aggressive thing to do back before GitHub made it so common among younger waves of developers.
If you go to Evan and say, "Look, I want to use your thing but do it my way." and he says "No, I have a clear vision of what the thing is and it's not that. KTHXBYE." I don't think that's "being a jerk".
Of course the author is unlikely to present it that way.
And although I felt the author was moralising in this critique, it may be they are not particularly rude the rest of the time. But even writing a plethora of well-reasoned but difficult to handle posts about what's wrong with your project can be too much.
Well-established languages, platforms and projects such as Linux that have a large labour pool with socially-established patterns of working don't have the same problem, because there's enough labour to deal with it.
Smaller projects just have to turn people away when they become hard work beyond the capacity of the project's core maintainers to handle it, though.
The solution found via FLOSS is to license software so that forking is always possible when a project cannot sustain different visions for the project's direction. This diffuses the tension when people have incompatible needs from the project. Sometimes it comes with drama, particularly if people are competing for attention and trying to persuade others to follow them, but that seems inevitable because of the competition.
It is still understood that forking is permitted and intended to be part of the solution, and the social niceties are that you may be encouraged, perhaps strongly, to go away and run your own fork yourself with your own resources, under a new name/domain/etc. while acknowleging where it came from. Then it's your own job to build a reputation too; it's only fair.
It's very difficult to keep running a project while your competition lingers on the same mailing list, constantly funnelling people towards their fork in the hope of making it more popular. That's a very good reason to "excommunicate" some people, or to forbid some topics such as advertising the other project repeatedly.
I don't really get this accusation in light of the author leading the article with admissions of their own failings in terms of how they communicated with the maintainers of the project?
> he claims that the Elm community will excommunicate you for forking.
If that is correct, what I said is less accusation and more descriptive, and should really say something stronger: "the author hasn't presented it that way."
However if the parent to my comment is mistaken, then I agree that would make that sentence in my response unfairly speculative.
[1]: https://github.com/gdotdesign/elm-github-install/issues/62#i...
(The word "fork" appears once elsewhere, in an unrelated context in a different comment.)
The thing about open arms is not about forking (or if it is, it's not obvious to me), and reads to me more like "assuming you are not making your own fork, can you please stop pressuring upstream to accomodate designs which are explicitly against our clearly communicated design goals".
The quote is:
> @spookylukey It's one thing to build tooling around an implementation flaw without knowing the history, but that's all pretty well communicated at this point.
> If you understand the design goals, but don't agree with them, why not channel that in a positive way - e.g. by building something that fits your vision instead of directly working against Elm's design goals?
> As someone who has spent a lot of time collaborating with many others to help Elm achieve its stated design goals, intentionally working against those goals feels to me like an attack on our efforts. We have been really clear about our design goals in this area, and you shouldn't expect a project that works against those goals to be greeted with open arms—especially not from those of us who have been working hard for years to achieve those goals.
I still see no objections to maintaining a fork or local patch from rtfeldman. Just "if you go against our explicit design goals don't expect us to want to merge it upstream for first-class support".
TBH a locally patched compiler sounds like not a huge deal to me. I have lived with locally patched GCCs before :-)
But maybe I'm unusual. I surprised someone, once, when they found some code not working and I suggested they look at their compiler source for the cause. Their response: "Wow, I hadn't ever thought of the compiler as something that might have a bug, let alone read and modify it".
how that affects the Open Source status of a project is irrelevant, this is simply not a project that i could use, and thus for all intents and purposes, for me at least, it's a project that can't be forked.
there have been hostile forks in projects before, even those that eventually had a good ending. egcs for example.
i was part of such a forked project too. it wasn't meant to be hostile, and the drama was limited to the project leaders, but it happened, and feelings got hurt.
not everyone is willing to take that risk.
It's a bit like Brexit. You don't get to stay in the club.
If there are sufficient people unhappy with Elm but are cohesive enough to push the compiler forward, then why not?
Just keep in sync with the main project, and keep the annoying/proprietary stuff out.
> You don't get to stay in the club.
Or you become the club. I think LibreOffice has more club going than Oracle's OOo.
quoting: "And a further consequence of this is that non-English developers and end users are discriminated against, due to the difficulty of formatting numbers and dates in correct ways for non-English locales."
The issue seems to be hypocrisy of the Core team and not that it isn't true open source. Forking a language is suitable only for extraordinarily situations, Elm language might be good but ultimately it's not that extraordinarily good.
Open source means you have access to the source in the preferred form for making modifications (and not e.g. dumps of generated code). IMO that should include any design documents that the original maintainers would consult when making modifications themselves.
Interaction style and personalities are also not part of the definition of open source; open source doesn't mean nobody is brusque or abrasive. Some communities have additional codes of conduct and social contracts and what not for that sort of thing.
Here is a balanced viewpoint from the GNU Awk and Bash maintainers:
http://www.skeeve.com/fork-my-code.html
Elm users who are not happy should fork the code --- everything, including the ecosystem's dependencies on an ELM internet domain --- and maybe produce something that is completely self-contained. Software that relies on "phoning home" is a risk regardless of where that is hosted and whether the people are nasty or nice.
If the Elm core developers don't like it and kick people out of their project for forking, you just have to bite the bullet on that.
(From the description of what that project is like, why would you care about being kicked out. Kicked out or not, your 20 line bugfix still isn't getting looked at for another two years.)