[Date Prev] [Date Next] [Thread Prev] [Thread Next] Indexes: Main | Date | Thread | Author

[ba-ohs-talk] Collaboration Improvemenet Ideas



Recent comments on license issues demonstrated brilliant talent by
many contributors.      (01)

Eric's letter today (shown below) referencing his excellent Treelight
web site focuses on adding value to knowledge work, and seems to
propose a technology project to improve collaboration.  I believe this
is an error.  The first order of business should be intelligence based
on an architecture of human thought.      (02)

Earlier Paul worried that the license issue has prevented code from
being contributed for the OHS/DKR.  While I have admired Paul's
analysis on many issues, this particular point is not clear in the
record.      (03)

A simple test is work product.      (04)

Whether someone submits code or not is irrelevant if there is no work
product that demonstrates added value to existing capabilities.  An
example is Doug's purple numbers system demonstrated in a letter on
001025 that showed added value, so people might ask to have that code,
and at that point licensing becomes an important concern.  Similarly,
Eric, Paul, Jack, Lee, Eugene and others have made helpful
contributions, and so licensing is critical, based on a demonstration
of added value, as Doug did on 001025.  For example, Eugene made
improvements in purple numbers and Jack planned to produce an engine
to organize the record.  Eric planned to create something on version
control and categories.  Show work product that shows added value to
generate demand for the code; then address licensing.     (05)

This still leaves open the question of whether meaningful progress has
occurred on producing an OHS/DKR, or is deterred pending resolution of
license matters?    (06)

OHS/DKR capability is so valuable, as explained in Eric's letter on
000120 citing Doug's vision presented in the Colloquium at Stanford,
and on Eric's web site, per his letter below, for solving world
problems, that it seems implausible for people to hold back creating
useful code simply because of worry about licensing.  In other words
the needs Eric related on 000120 and later on 011003 are so huge and
painfully frustrating that no one would stand by and endure suffering 
if they knew how to fix the problem. In that case, work product would 
demonstrate added value.  Since there is no work product, this
indicates that people don't know what to do.    (07)

Eric's letter on 000503 made this very point.  Earlier on 000405 Paul
said close to the same thing.  Nothing in the record shows that lack
of understanding the design of KM has been repaired.    (08)

Consideration might therefore be given to reviewing Eric's letter on
000423 talking about augmenting intelligence, because experience
indicates intelligence helps collaboration.  This requires re-thinking
the meaning of "knowledge" based on Eric's letter on 000212 by
applying the rigor invested the past week or so re-thinking license
ideas. There is plenty of brain power in the group, but it needs to
focus on things that make progress, rather than whatever pops into the
mind at the moment, as Grant noted on 001012.  In this respect I
differ slightly with Paul on the Termite production method used at
Microsoft, Boeing and with the OHS/DKR effort the past few years.  A
million bright stars light up the heavens but do not produce enough
energy to light a fire; while a simple magnifying glass focuses light
in sufficient measure for ignition.      (09)

The missing ingredients then are focus of management and focus of
design on cognitive science, noted by Drucker in his article published
in October of 1999. Recall that Mary Keeler discussed this somewhat in
remarks at SRI on 000518 citing work by Peirce on semiotics.    (010)

Once you establish an architecture of human thought that can be
addressed with computer programming skills, you can build a technology
that enables a dynamic knowledge repository to solve world problems. 
When people are able to work "intelligently," then there is
opportunity to improve collaboration, as called out in Eric's web
site.  So long as knowledge and intelligence are ignored, people will
remain in the dark using information technology which means continued
dominance by Microsoft that has been a sore point in the group.  The
only way to transcend Microsoft is to leave them the monopoly for IT
that is document centric, and move the market to KM by advancing
alphabet technology beyond the model of documents in the same way that
automobiles outflanked covered wagons.  It is an old story that may
not be played out in our lifetimes, but at least we have the
opportunity to witness the  majesty of a powerful new wave forming on
the horizon, if only we would lift our eyes to see, and then perhaps
nudge things along as best we can.    (011)

Once a better foundation for knowledge work is in place by
strengthening alphabet technology, then folks are positioned to
accomplish Doug's goals for improving improvement using open source
modalities.  First, however, we need a better way to leverage
intelligence, as explained in NWO....    (012)

http://www.welchco.com/03/00050/01/09/03/02/03/0309.HTM#42HC     (013)

This requires focusing brilliant talent for analysis, demonstrated on
the license issue, on "knowledge," which is painful in the beginning
as Eric noted on 000503, but very soon rewarding, satisfying and fun
to work intelligently.  It only takes a little focus.    (014)

Rod    (015)

****************    (016)

Eric Armstrong wrote:
> 
> That is one great document. It doesn't cover issues of
> version control and a couple of other things, but it is one
> heck of a great start.
> 
> My own take on the requirements are captured here:
> http://www.treelight.com/software/collaboration/index.html
> 
> I'd start with the Requirements for Collaborative Design/Discussion
> System (Winter-Spring 2000).
> 
> I believe Eugene worked up a later summary that took some
> of its better features and combined with a lot of the material
> that came up in our email discussions. Lee and Henry may
> have put something together, as well. (Unfortunately, I am
> horrible at keeping track of other people's documents.)
> 
> Paul Fernhout wrote:
> 
> > James Michael DuPont wrote:
> > >
> > > Paul,
> > > please let me ask this to all of you.
> > > If the OHS will not be able to at first contribute
> > > code.
> > > You and Eric both have a profound command of the
> > > english language.
> > >
> > > My command is of C/C++/SQL and Perl.
> > >
> > > Would you provide instead of software, as a group
> > > a SPECIFICATION that can be implemented as a GPLed
> > > program by someone like me? A modular design that
> > > allows for a core of GPLed code that protects the
> > > investment, and is easily modified.
> >
> > Here is a starting point:
> >   http://www.bootstrap.org/augment/ALLIANCE/980.html
> >
> > Various discussions here have taken some of the ideas in it further, but
> > that document is probably a good place to start.
> >
> > -Paul Fernhout
> > Kurtz-Fernhout Software
> > =========================================================
> > Developers of custom software and educational simulations
> > Creators of the Garden with Insight(TM) garden simulator
> > http://www.kurtz-fernhout.com    (017)