Should it be GNU/Linux

Posted Mar 24, 2007 17:48 UTC (Sat) by landley (guest, #6789) [Link]

IBM didn't make the existing versions proprietary, they stopped releasing
new open versions. (Keep in mind IBM didn't accept outside contributions
to their OS. The modern equivalent of this is that the sole copyright
holder were free to issue new licenses, as Sun is doing with the GPL.
But the code that was out there stayed out there.)

IBM's big change of heart was called the "Object Code Only (OCO) Policy",
issued February 8, 1983. Here's a copy of their original announcement:
http://landley.net/history/mirror/ibm/oco.html

Here's the final report of SHARE's attempt to get IBM to change its mind
(essentially giving up 5 years later):
http://www.redbug.org/dba/sharerpt/share71/s987.html

And an history article putting it in context:
http://www.itworld.com/Comp/1369/LWD000606S390/

> > I repeat my earlier assertion that for most of the 1970's proprietary
> > software wasn't even an issue on the hobbyist programmer community's
> > radar.
>
> True, that is precisely why Stallman was being visionary by being
> concerned before the rest of the world saw the problem of the
> proprietary approach everyone was taking.

Going from a world that had less than a hundred thousand computers in it
to a world that has more than a hundred million in the space of about 15
years led to some impressive culture shock on the part of the programming
community. What happened is that most of the existing programmers didn't
see alternative ways of doing things as a _threat_, because they didn't
realize they were about to be outnumbered by a factor of 1000.

> > Which gets us back to "the FSF wasn't being visionary, it was being
> > reactionary and conservative from day 1".
>
> A bit contradictory (or again I'm not following you), Stallman saw the
> problem not only with proprietary development, but also with public
> domain and BSD-style licenses. That is why he created the GPLv2 and the
> FSF. Why is that "reactionary"?

He was striving to maintain the status quo. Return to the glorius past.
The way we did it in the good old days was superior to these newfangled
professional software development businesses.

He may have been right, but that doesn't change the nature of his
actions. And how right he was when what he was originally trying to
defend was the ITS system against the MIT administration, and the rebase
to Unix only came about when the PDP-10 hardware line and
proposed "Jupiter" follow-on project were cancelled (also in 1983),
rendering ITS (written entirely in PDP-10 assembly) a clear dead-end.
His move to Unix was forced upon him when ITS died, he just wanted to
move as little as possible.

Fast forward to _today_ and people are going "oh, what great new insights
do you have for us with your keen eye for the future" when all he ever
did was prefer 1977 to 1983. I do not look for great insights from this
man, I look for clever hacks to defend ideas from the 1970's, often with
long elaborate rationalizations for things he's already made up his mind
on. (Show me the last time he _changed_ his mind due to new information.
Yeah I know, he's not inflexible, he's making a stand on principle. I
honestly thought he might take up the cause of deCSS in 2000, but ITS
couldn't play DVDs. There still isn't a GNU deCSS implementation. Not a
battle he wants to fight.)

> > The Cathedral and the Bazaar was a paper about how Linus's working
> > style differed from that of the FSF. (The cathedral was specifically
> > the FSF.)
>
> I have seen this assertion of yours a couple of times, and it is what
> made me answer this post: where do you get this impression?

From Eric Raymond directly, while editing The Art of Unix Programming
(check the intro for my name), and outright co-authoring things like the
OSI reaction paper to the SCO lawsuit, Halloween 9, and the 64-bit paper
(which he insisted on titling "world domination 201")...

It's in the book, though, if you look for it:
http://www.catb.org/~esr/writings/cathedral-bazaar/cathed...

> But few of us really thought very hard about what we were doing, or
> about what the very existence of that archive suggested about problems
> in the FSF's cathedral-building development model.

A couple times he's talked about a specific 1996 conference that Tim
O'Reiley put together (and that he, Linus, and RMS attended) where worked
it all out for the first time, seeing them next to each other and
thinking about the differences. I could ask him for details...

> I don't see why not. The piece of paper is just needed once per
> developer;

Needed at precisely the wrong time.

I touched on it here: http://lkml.org/lkml/2002/1/29/9

Most developers start out as casual contributors. A line here, a bugfix
there. The less they have invested in participating in a project's
development, the more easily discouraged they are. Needing a sign-off to
get cvs commit access is one thing, but needing a sign-off to take your
five line function? Eh, it wasn't that important anyway.

> developers do not change that much,

In a project with 1000 semi-regular contributors, the top 20 don't change
that much month to month. Call the newspapers.

The point is where do they come from? Let's look at a couple of
examples:

Con Koliavs: scheduler dude. When he got into Linux his day job was as
an Australian anesthesiologist, he started poking around Linux for fun.
First time he wandered away, two years later he tried again and got
hooked:
http://kerneltrap.org/node/465

Andrew Morton, current #2 in the development community. Only got involved
in the project in 2000, because a NIC he was using had been declared
obsolete and he sent in a patch fixing it. (Was anybody other than him
still _using_ that NIC? Dunno. He could have maintained it out of tree,
but it was easier to get it merged so it wouldn't break again.)
http://kerneltrap.org/node/10

Even the early adopters did stuff before Linux. Alan Cox used to do
Amiga stuff and MUDs, Peter Anvin first used Linux to put together
terminal servers...

Back when I read the first year or so of the linux kernel mailing list, I
collected a few interesting posts (with links back to the originals in
the archive):
http://landley.net/history/mirror/linux/1991.html
http://landley.net/history/mirror/linux/1992.html

Now ask yourself: how many of those people would have just wandered away
again if Linus had asked them to fill out paperwork as a condition of
participating?

Attracting and breaking in new developers is extremely important to the
long-term health of a project. This is why things like kernelnewbies.org
exist.

Rob