The rebellious nature of Unix sharing in the early days taught an important lesson for would-be sharers today: either take pains to make sure your software can be used by anyone who wants to, or risk being shackled by lawyers and corporations who don't want it to be used.
other than unix (clearly) being one of the most important technological leaps forward in computing, which is just a given at this point, well, that pic is just awesome!
Code availability and development methodology are independent axes of sharing. One is sharing the output and the other is sharing responsibility.
Since you don't even need to even ask for the code for open source projects, it's there for the taking, the sharing is actually better than it was in the 1970s. Largely this has to do with the greater ease of communication and distribution. It's easier for me to share my code by putting it on github or providing a .tar.gz and forgetting about it, than it for me to have to cut a tape every time someone asks for it. In fact, when companies honor the letter of many open source licenses by only making their modified source available if you actually ask for it or assert your identity by filling out a web form, rather than putting it on a publicly accessible site somewhere, they are often chided for making the user have to jump through hoops to get the source (notwithstanding the companies that actually violate the license and don't make the source available via any means, of course).
That the development style of not directly/immediately incorporating various changes from other parties may be a more cathedral, rather than bazaar, but nothing is stopping the recipients of the code from forking it and distributing and sharing their own changes with each other. In fact, the very definition of open source is such that that is encouraged; that few do, or that people are not motivated to fork, has nothing to do with the culture of sharing the code, and, again, most likely has more to do with the ease of which it's possible to get the canonical version of the code and the branding behind the consistency of that canonical version.
I can bring a baseball bat I turned on my own lathe to the park and let other people use it, but just because I don't let someone else customize my bat or use my lathe doesn't mean I'm not sharing the bat.
> Code availability and development methodology are independent axes of sharing. One is sharing the output and the other is sharing responsibility.
They're different degrees of sharing, rather than independent axes. Sharing responsibility is a greater degree of sharing than sharing output because you generally don't have an open development process without shared source code.
My comment about "a cathedral in a bazaar's clothing" describes projects which start out as open process, but after a while become less and less open so they end up as open source only. The people taking them over keep up the appearance and terminology of the original open processes, but without the reality.
Indeed: 147456 (probably plus some for parity; not sure what the PDP-7 memory bus looked like) tiny little beads threaded onto tiny wires by human beings. That amount of memory in an SRAM array (almost a million transistors!) was unthinkable in a minicomputer, and DRAM had just been invented and was even more expensive than core.
