> Similar to SQLite, diagrams.net is open source but closed to contributions.
> The level of complexity of this project means that even simple changes can break a lot of other moving parts. The amount of testing required is far more than it first seems. If we were to receive a PR, we'd have to basically throw it away and write it how we want it to be implemented.
> We are grateful for community involvement, bug reports, & feature requests. We do not wish to come off as anything but welcoming, however, we've made the decision to keep this project closed to contributions for the long term viability of the project.
Emphatic agreement.
Bryan Cantrill touched on this too:
"...we [now] know that OpenSolaris didn’t go far enough: even though the right to fork was understood, there was not enough attention paid to the power to fork. As a result, the operating system never quite got to being 100% open"
http://dtrace.org/blogs/bmc/2010/08/03/opensolaris-and-the-p...
I experienced this first hand while being paid to work on FOSS. At the time, I just couldn't figure out why our very well resourced, well intentioned project was chowdering. Cantrill's illuminating insight, per usual, was spot on.
--
To the pedants arguing with u/derefr: Stop it. Step back, get curious, ask u/derefr to clarify. u/derefr is trying to say something important.
Some of us have actual experience with this stuff, not covered in the manual. It often takes great effort to reflect and articulate novel experiences. Especially when those experiences don't meet anyone's expectations.
"In theory, theory and practice are the same. In practice, they are not."
--
Further, definitions, rules, bylaws, and code of conducts are just starting points. Ever DM a role playing game? Tried to get your local party to approve a resolution? Had your day in court?
As if some formal definition somewhere is the last word on running a successful FOSS project. Please.
Human projects are at least as complicated as the humans themselves.
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral...
From Wikipedia:
>In 1998, the essay helped the final push for Netscape Communications Corporation to release the source code for Netscape Communicator and start the Mozilla project; it was cited by Frank Hecker and other employees as an outside independent validation of his arguments.
Netscape's public recognition of this influence brought Raymond renown in hacker culture.
> 1. Your project starts accepting code contributions from the community (if perhaps after a gruelling code-contribution process); or
> 2. Your project’s codebase becomes licensed in a way that allows people to fork it, add their own changes, and then use the result themselves to achieve their own ends (if perhaps only non-commercial ends.)
There is a formal definition of Open Source by the Open Source Initiative:
Only 2 is open source (but the no-commercial condition means this it is not), while only 1 is not open source.
This is not the conventional meaning of the term, and has repeatedly been used as an avenue to attack the concept in general.
As a comparison, how happy would you be calling a system where you can only vote for candidates approved by a single leader a "Democracy". Under these standards, both the USSR and China are democracies.
The differences matter, it is not pedantry and it is not some organization enforcing "their definition" overtop of what people "commonly think".
I’ll restate. My descriptivist definition of the term “open-source”, was that something is “open-source” if you are free to do at least one of either forking the thing for your own use, or modifying the thing and pushing those modifications upstream. In other words, “open-source” software is software where you’re free to notice a flaw in the program and, by some mechanism, get it fixed in such a way that other people can benefit from the fix.
And yes, the OSI definition of “Open Source” is an organization enforcing an arbitrary definition, because it disagrees with many uses of the term “open source” — specifically, the OSI considers GPL-licensed software to not be capital-letters “Open Source”, despite everyone conventionally considering it regular-adjective “open-source”. (The FSF does a similar brain-damaged thing with the term “Free Software”, which has not-much to do with what people would call “free software” — but at least “free software” isn’t a very common term in modern parlance; people aren’t constantly talking about “free software” with the FSF then misconstruing their words as if they had said “Free Software.” Which is exactly what the OSI does when people talk about “open-source software”, and then the OSI misconstrues their statements as statements about “Open Source software.”)
Yes, this is exactly why pedants use the term “FOSS” — i.e. “Free and Open Source Software”, a union-ing of the set of software that is FSF-jargon “Free Software” with the set of software that is OSI-jargon “Open Source Software.”
Regular people, who aren’t trying to be sycophants toward these two organizations, on the other hand, just use the uncapitalized adjective open-source to refer to this larger set.
What? OSI disagrees with you.
https://opensource.org/licenses/alphabetical
"Free software", "open source software", and "free and open source software" are often used interchangeably because they refer to software that is largely protected by the same set of licenses. The terms differ by emphasizing different aspects of the philosophy behind FOSS.[1]
[1] https://www.gnu.org/philosophy/open-source-misses-the-point....
Respectfully, this definition of "open-source" does not match common use, even with a loose colloquial interpretation in mind. As commonly understood, an "open-source" license requires the ability to acquire the source, and to modify it, and to redistribute it.
Your definition, quoted above, would call open-source a license that allowed for personal modifications to source but forbade redistribution of those modifications. Your definition would also call open-source a license that required all modifications of the source to be made through a single point of central control. I think both of these cases fail even loose understandings of what "Open Source/open-source" is. I do think they both describe "source available".
You draw a distinction between "open-source" as a colloquial term and "Open Source" as defined by the OSI, but I don't think this isn't very compelling or useful. Sure, language evolves and people use terms incorrectly all the time, but that doesn't make erroneous use correct. In particular, "Open Source" is used as a legal criteria for a set of software licenses, so precision in its definition is important. Also, I have not personally come across any cases where there was any material difference between colloquial use of the term open-source and precise definition of Open Source as defined by the OSI. Do you have anything to cite that justifies a distinction here?
So I beg you to reconsider the idea that the OSI is "some organization who just decided to name themselves after the term" and the idea that "Open Source" is a term "defined loosely by how people use it." In point of historical fact, the term was first used by the people behind the organization, who formed it to popularize it as a new concept, and an alternative to "Free Software": https://web.archive.org/web/20021001164015/http://www.openso.... The OSI is not some organization formed to co-opt and redefine the term for their own purposes after it was already in common use.
I do agree with you that often times people think of specific project management structures when talking about open-source development. I.e. the debates about what makes for a successful open-source project, cultivating a community, making it easy for community members to contribute, etc. There can be non-open-source projects using open-source development methodologies, sure, but it doesn't make them "open-source" even in a colloquial sense. The sole criteria is always the license granted to users of the software.
As others have said, #1 is not really necessary since no open source project needs to accept contributions from anyone. #2, on the other hand, is absolutely necessary because open source software must allow users the freedom to copy, modify, and use the code as they wish.
> (if perhaps only non-commercial ends.)
However, software under licenses that forbid users from using the code for certain purposes (including commercial purposes) are not open source. Both the OSI[1] and the FSF[2] object to this type of restriction. Allowing arbitrary restrictions on use would raise the question of the types of discrimination that should be allowed in FOSS licenses, which is something many in the free and open source software community prefer not to deal with.
[1] https://opensource.org/osd#fields-of-endeavor: The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
[2] https://www.gnu.org/philosophy/free-sw.html#selling: “Free software” does not mean “noncommercial.” On the contrary, a free program must be available for commercial use, commercial development, and commercial distribution.
> SQLite source code is in the public-domain and is free to everyone to use for any purpose.
That being said, I agree with your sibling poster that "open contribution" is not a requirement for "open source".
“Open source” is a different thing than “source-available” or “shared-source.” Many closed-source products are “source-available” in the manner you’re talking about, but this does not make them “open source.”
You’re not really an open-source project, in the conventional meaning of the term, until either
1. Your project starts accepting code contributions from the community (if perhaps after a gruelling code-contribution process); or
2. Your project’s codebase becomes licensed in a way that allows people to fork it, add their own changes, and then use the result themselves to achieve their own ends (if perhaps only non-commercial ends.)
Which are two sides of the same coin, really; they both imply that people will be tinkering inside your code; and that the “canonical” version of your code in everyone else’s mind might then become the version that the community thinks is better, rather than your official release.