[unrev-II] DKR for Open Source: Viability

From: Eric Armstrong (eric.armstrong@eng.sun.com)
Date: Mon Feb 07 2000 - 14:18:58 PST

From: Eric Armstrong <eric.armstrong@eng.sun.com>

John \"sb\" Werneken wrote:
> Eric, my thanks for all the work you put in to your presentation!
Thanks. Great to hear from you.

> I am NOT a computer person (except in the sense that a fairly good
> driver might be a "car person", lol). But I have done DOS keystroke
> macros that went on to several thousand lines, so I have some idea
> of what you are talking about when you discuss linking design
> decisions comments and so forth in to the code in an acceptable way.
I disagree. You ARE a computer person.
Quite a good one at that.
The impetus to automate difficult tasks, and the tenacity to learn
a language necessary to do it, are all it takes. Plus the persistence
to get the d**** things working. You obviously have *all* the
required characteristics.

> And the Doug had to say what he seems destined to say about
> EVERYTHING: "I was doing it in the 1960's".
Yeah. You gotta love him or hate him.
If you're not inclined towards jealousy, there's only one option.

> Maybe he was. Maybe he's an RMS who never found his ESR.
Now you got me. What's an RMS? What's an ESR?

> By analogy, to Microsoft and to Apache: Microsoft made it possible for
> people like me to learn how to do mundane tasks with a computer. A
> 'faster-better-cheaper' by order(s) of magnitude, as far as how much
> training I needed before I could figure out how to get some kinds of
> things done. All of a sudden, Microsoft is everywhere; I think that is
> why.
Good observation. I think there attention to user interface issues is
responsible for their wide public acceptance, too. They were the first,
and still possibly the *only* software company to fully understand the
importance of the user interface. To otherwise is to disregard the
importance of *my* time, but Microsoft appeared (appears?) to be the
only company that "gets it". They invested millions in an interface
department, and gave them veto power over product shipment. The result
was a set of consistent interfaces previously unknown in the industry.
Since then, I've found they have a seriously impaired sense of ethics,
so I cannot in good conscience be an MS supporter, but up until then
I was an MS-rooter all the way.

> Then Apache and Eric S Raymond et al evangelizing open source. Apache
> makes it possible for the majority of world web sites to have a server
> that is beyond doubt cheaper and is apparently at least as stable and
> capable, maybe more so. Now Apache is everywhere. "faster-better-cheaper'
> by order(s) of magnitude.
Definitely a strong proposition. However, their revenue-proposition
lacks a little. I think there must be a way to combine "open source"
with a "profit proposition", but I'm not sure what it is just yet.

> Somehow using links to comment code does not strike me the same way.
> I don't see a ten or more fold expansion in the number of people able
> to do significant programming. Or a ten-fold increase in programmer
> production.
Another very good observation. I agree with this, to a point, but there
are some other aspects...

> So is the first "breakout" use really this?
> I WOULD agree that if programmer productivity COULD be increased
> ten-fold, that that WOULD be a real breakthrough killer use of the
> concept. I just don't see this, doing that. Perhaps because as I
> said I don't program.
In my book, you *do* program, and you are making astute observations.
Now for the counter points:

1) When it comes to coding a problem you understand, no, I don't
   think this is a "killer" app.

2) But when it comes to arriving at a consensual understanding of
   a problem you aren't sure how to tackle, I think the kind of
   system we are talking about will prove to be worth it's weight
   in gold.

   Example: There are many parts of the application that I am
   really unfamiliar with: mail protocols, for example. We have
   dozens of people with expertise in different areas, and we need
   to hammer out a design that works. That kind of collaborative
   design should be enhanced with this kind of system.

3) The Open Source environment currently does *not* work for such
   problems. Open Source works when you put out a small kernel
   early, so people begin to grasp how it works. Then they start
   improving it. Over time, it grows in complexity and scope, but
   at a body of expertise grows at the same time. When someone new
   jumps in, their email is answered by one or more knowledgable
   individuals, which allows them to come up to speed.

   Open Source currently does *not* work when a) There is no code
   to start from, and b) When a huge body of code which no one
   understands is put out all at once. (I'm indebted to "The Cathedral
   and The Bazaar" for making that clear. It's available in book
   form these days.)

   When no code exists, there is nothing that "brings it all together"
   for developers. An email/document that allows for *reduction* into
   new document versions would allow developers to a) explore the
   design space, b) record design decisions, c) save alternatives, and
   d) create a uniform "design picture" out of rambling discussions.
   To date, open source efforts have been limited to extending and bug
   fixing. This system could make it possible to initiate an open
   source design in an open source way.

   When a large body of code is released all at once (like Netscape's
   mozilla), the opposite problem exists -- no one can "wrap their
   head around it". You look at code and ask "Why is that there?" and
   there is no one around to answer the question. Linked explanations
   provide the possibility of answering "why", which means makes the
   code that much more accessible to new people. (Interestingly, open
   source code has much *more* documentation than is typical for the
   industry as a whole. This system provides better mechanisms for
   capturing the information.)

4) For large commercial projects, maintenance costs over the life the
   project *dwarf* the initial cost of development. A company can spend
   as much as 5 times on maintenance as it cost to build the project
   originally. The *majority* of the time spent by maintainers is in
   "getting up to speed". Any system which allows system understanding
   to be recorded in an usable way stands to greatly improve the speed
   and cost of maintenance.

So, even if initial coding is not dramatically improved, the ability
to explore the design space intelligently and augment maintenance
capabilities should more than justify an investment in installing and
learning to use such a system. In addition, I suspect that most
developers won't miss having to find misplaced braces!

Thanks for the opportunity to further clarify some of my thinking!

--------------------------- ONElist Sponsor ----------------------------

Valentine's Day Shopping Made Simple.
<a href=" http://clickme.onelist.com/ad/SparksValentine7 ">Click Here</a>


Community email addresses:
  Post message: unrev-II@onelist.com
  Subscribe: unrev-II-subscribe@onelist.com
  Unsubscribe: unrev-II-unsubscribe@onelist.com
  List owner: unrev-II-owner@onelist.com

Shortcut URL to this page:

This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 18:56:44 PDT