Agree. I'm gonna be honest and say I haven't finished the entire article so author might have elaborated further after, but I got a chill when reading the following passage:
> 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.
> I continued reading and found bunch of more passages where the authors understanding of open source seems to be incorrect.
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.
> 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?
It doesn’t tell me which or his opinions he thinks are backed up by accepted definitions or what he considers an accepted definition. So no, it doesn’t tell us anything. It sounds more like a weasel word to get out of providing citations to back up his arguments.
> whatever assumptions he has about open source is not a fantasy
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.
I find you're being needlessly formalistic here. The author is explaining where they are coming from. What their understanding and expectations in the open-source world are. This helps to understand their position. That initial part was intended (I guess) to make comments like yours redundant. Because that way we can understand what the author means without guessing about their usage of the term.
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.
> What their understanding and expectations in the open-source world are
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
The OSI definition is useful as a baseline. When people argue over what open-source means, I think they can mostly agree on that definition. On top of it we see frequent arguments over authors' responsibilities and appropriate stewardship.
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.)
>> 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
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.
Part of the problem here is that he suggested forking (he used the word "patching") the compiler in another project, and one of the core maintainers of Elm jumped into the issue and said it felt like an attack on Elm itself.
That feels a bit silly - why make a project open source if you're going to get upset when someone forks it?
I'm not sure people saying this know that the author is one of the "core developers" of Django. It is safe to assume that his expectation of "open source" is not far-fetched at all.
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".
The terminology is irrelevant. If you have certain expectations from the open source communities (among the diversity of possibilities that are open source) the narrative of what happened (especially with regards to being considered persona non grata if you fork) are worth knowing about.
> 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.