But claiming open source is totally about the source and the license completely erases the diverse and vibrant community that has formed around open source over the past 40 years. The license is simply putting the community ethos into a legal document. The source being open represents a meeting place which focuses and collects the community. But the real power of open source is the human element that drives it, and the development philosophy they hold, not the source code.
Linux for instance wouldn't nearly be the powerhouse it is if it were merely "source available". You're really misunderstanding the power of open source if you think it's all about the code, and not the development model.
I know you are stating this, but I don't agree.
The human aspects, the diverse and vibrant community that has formed around open source over the past 40 years are key, I just think that we should cleanly separate the concepts.
A piece of software is open source if and only if it's released under an open source license. It's necessary and sufficient. Also "source available" is necessary but not sufficient.
Then we can and should talk about how and why open source and free software appeared, and the other social aspects around open source and free software and how they are crucial.
I'm not stating that the whole thing is not important (clearly, it is), it's just that keeping the concepts separate and clean helps communicating clearly.
My stance is already mostly not technical actually. I would push for free software and the human rights it embodies way more than open source despite open source and free software concerning mostly the same actual software. The tools (licenses) are mostly the same, but the intent and the approach can be very different.
Even the open source definition and the free software definitions are tools. They must remain clear and simple to be useful and powerful.
If you mix everything, we can talk about nothing.
There are many ways to develop open source software, including alone from a garage by throwing the source code out of the window without never looking outside. If you make the community aspect part of the open source definition, you break this.
Maybe consider putting your energy into a good documentation inside the repository. I would love to have more projects with documentations which cover the timeline and ideas during development, instead of having to extract these information from metadata - which is what commit messages are, in the end.
How does this happen? I haven't run into this.
> Maybe consider putting your energy into a good documentation inside the repository
I'd say both are valuable.
I use git log and git blame to try to understand how a piece of code came to be. This has saved me a few times.
Recently, I was about to replace something strange to something way more obvious to fix a rendering issue (like, in some HTML, an SVG file was displayed by pasting its content into the HTML directly, and I was about to use an img tag to display it instead), but the git log told me that previously, the SVG was indeed displayed using an img tag and the change was made to fix the issue that the links in the SVG were not working. I would have inadvertently reverted a fix and caused a regression.
I would have missed the reason a code was like this with a big "work" end of the day commit.
It would have been better if the person had commented their change with something like "I know, looks weird, but we need this for the SVG to be interactive" (and I told them btw), but it's easy to not notice a situation where a comment is warranted. When you've spent a couple of hours in some code, your change can end up feeling obvious to you.
The code history is one of the strategies to understand the code, and meaningful commits help with this.