
The Strange Birth and Long Life of Unix - naish
http://spectrum.ieee.org/computing/software/the-strange-birth-and-long-life-of-unix/0
======
fendrak
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.

------
jamesgeck0
I can't remember a time before CVS (and now DVCS). Distributing patches via
geocache sounds awesome.

~~~
sixtofour
"Never underestimate the bandwidth of a station wagon full of tapes hurtling
down the highway." —Tanenbaum, Andrew S.

<https://en.wikipedia.org/wiki/Sneakernet#In_media>

~~~
eru
The latency is the problem, not the bandwidth.

(By the way, considered as a means of transferring information sex has lots of
bandwidth, too. Not, yet, useful for sharing patches, though.)

~~~
sneak
Well, not consciously-designed ones.

------
plessthanpt05
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!

------
Getahobby
Ok. Awesome article. Even more awesome that I didn't have to click "next page"
12 times.

------
vorg
> By the mid-1970s, the environment of sharing that had sprung up around Unix
> resembled the open-source movement so prevalent today.

Not sure what percentage of today's open-source movement has an environment of
sharing. Much of it is cathedrals in bazaar's clothing.

~~~
thwarted
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.

~~~
vorg
> 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.

------
cygwin98
Not to nitpick on the author. But 16KB was quite a bit memory in early 1970's.

~~~
ajross
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.

