Subject: Re: Back to car repair (Was Car Repair) Debian GNU/Linux...
From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
Date: Mon, 7 Jun 1999 23:42:59 +0900 (JST)

>>>>> "Brian" == Brian Behlendorf <brian@hyperreal.org> writes:

    Brian> On Fri, 4 Jun 1999, R. Brock Lynn wrote:
    >> "Stephen J. Turnbull" wrote:
    >> 
    >> > Software doesn't wear out, it doesn't go out of tune, and
    >> > it doesn't break in the present tense; any analogy that
    >> > requires that those characteristics are violated is suspect.
    >> 
    >> Yes.

    Brian> I don't know about that.

Sorry; I anticipated this line of argument, but didn't have an answer
to that when I posted.  I expected to, and do ;-).  It was a bit
underhanded of me to leave it open.

    Brian> The statement above presumes that the conditions within
    Brian> which the software is used are static, when in reality,
    Brian> software components both below and above in the hierarchy
    Brian> are constantly changing.

True.

    Brian> I don't see this as functionally too different from
    Brian> "wearing out" - both in the case of software conditions
    Brian> changing and in the case of car parts wearing out over
    Brian> time, effort must be spent to even maintain the status quo.

False.  What you have just made is an argument for adherence to
standard interfaces.  Note that when a ball bearing becomes pitted,
the interface has changed.  Software doesn't have that problem.

It is true that if the interface is going to change anyway, it would
be nice to have source.  But the software is not wearing out; the user 
has thrown a monkey wrench into the system, perhaps quite innocently.
But it doesn't _need_ to happen; adherence to standards is just as
effective a remedy as open source would be.[1]

Note that this is one place where we _do_ see massive demonstrations
by users.  Companies that violate standards in ways noticable to users 
typically are forced to back down, even Mighty Microsoft.  And even
where they don't they suffer big loss of trust.

Hmm.  Users care vocally about standards.  Even industry "standards."
But they don't speak up about source.  Why not?  (Please don't rehash
the "simply because they're ignorant" line; I think discussion is only
worthwhile if it brings up new ideas, especially with respect to how
"need for source" could be made to have the same visibility as "need
for standards.")

Aside:

    Brian> I think we're just plain lucky that no one's submitted a
    Brian> port of Apache to MS-DOS to us, or we'd have to have a big
    Brian> long debate about whether that platform was worth
    Brian> supporting or not.  =) Again, I'm not sure if this would
    Brian> fall into your definition of "planned obsolescence".

Only because Brock doesn't have one.  He "knows it when he sees it."


Footnotes: 
[1]  First order approximation.  Second order two effects.  (1) Bugs
happen.  Source allows fixes to unexpected failures.  (2) Source
allows the user to choose to fix one or the other (or both), thus
saving negotiation over who owns the bug, and who fixes it.

But in the presence of standards adherence, these really are second
order.  And I hope nobody here would deny that whether to take a
standards-conformant proprietary implmentation vs. a non-conformant
open-source implementation would be a tough choice.

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
__________________________________________________________________________
__________________________________________________________________________
What are those two straight lines for?  "Free software rules."