CONTACTS 
0201 - Armstrong Consulting
020101 - Mr. Eric Armstrong

SUBJECTS
Feel Good Management Empowerment Do What We Want Open Source
Difficult KM Hard to Design, Not Understood
Open Source Can Occur After Core Capability Developed
Core Capability KM Not Understood, Eric Armstrong
KM Not Understood Secret of SDS
OHS Delayed Indefinitely by Design Problems
OHS Program Code Architecture Under Production
Delay in OHS Architecture Problems Integrating Features, Eric Armstro
Problem Integrating Features, Eric Armstrong
Linking Versioning Architecutre Snag OHS
KM Architecture Snag Release Code Delayed, Eric Armstrong

1913 -
1913 -    ..
1914 - Summary/Objective
1915 -
191501 - Follow up ref SDS 41 ADK2, ref SDS 40 ADK2.
191502 -
191503 - Received ref DRT 1 0001 from Eric Armstrong advising the OHS design is
191504 - still in flux, so it's going to be a while before it is ready for
191505 - review.
191507 -  ..
191508 - This supplements Eric's letter on 001017 reporting progress in OHS
191509 - design, ref SDS 32 IO6J, the next day on 001018 he reported a snag in
191510 - architecture on linking and versioning. ref SDS 34 M4W7
191511 -
191512 -     [On 001122 Eric disappointed about difficulty creating KM, sent
191513 -     letter suggesting he started with narrow objectives, of simply to
191514 -     link. ref SDS 42 0001
191516 -      ..
191517 -     [On 001130 article reports IBM delays release of Raven which is a
191518 -     KM effort based on Lotus Notes. ref SDS 43 F26K
191520 -      ..
191521 -     [On 010723 Eric Armstrong reports NODAL developed by Lee Iverson
191522 -     at SRI solves problems with simplified design for OHS/DKR using
191523 -     Groves and abstract data modeling. ref SDS 44 3B7L
191525 -  ..
191526 - Eric says the problem lay in a premature evaluation of the position --
191527 - in evaluating it while various threats were still outstanding, before
191528 - it had "quiesced". ref DRT 1 WJ6H
191530 -  ..
191531 - On 001102 Eric wrote a letter saying in part...
191532 -
191533 -      The issue of versions continues to complicate the node hierarchy
191534 -      beyond all reason. If the issues are resolvable, the resulting
191535 -      system will be golden, but...
191536 -
191537 -      Today's thought question is:
191539 -         ..
191540 -        If we want categories, and we want versioning, how do
191541 -        categories interact with versioning?
191543 -       ..
191544 -      For an even more interesting problem, what happens when a
191545 -      category is split in two, so that "ToDo" becomes "Bug:Open" &/or
191546 -      "Feature:Open". How are those changes versioned? (Traction solved
191547 -      this problem. So it is solvable. But how???)
191549 -  ..
191550 - These issues are mostly irrelevant to KM, and to the extent they
191551 - require attention, the first objective is to begin producing some
191552 - knowledge.  The scope of versioning will then become clear from
191553 - experience.
191555 -  ..
191556 - Today, Eric explains that in design work, decisions in one area
191557 - precipate changes in other areas.  When you work on those areas, more
191558 - changes occur. When that is happening, the basic design is still "in
191559 - flux" -- it is a dynamically evolving entity that is not yet stable
191560 - enough or quiet enough for a reasonable evaluation. ref DRT 1 GK6K
191562 -  ..
191563 - Eric thinks major design decisions are complete, but each decision has
191564 - ripples to be traced.  As a result, there is still plenty of room for
191565 - "intersecting ripples" to create a design inconsistency, which would
191566 - precipitate yet another change... (and the wheel goes round and
191567 - round...), ref DRT 1 MM7G
191569 -  ..
191570 - Eric is not trying to solve every problem.  There are major issues yet
191571 - to be decided.  The need is not yet clear, so they are not reflected
191572 - in the current design.  There are also a score of implementation
191573 - "gaps" to be filled. ref DRT 1 NM7M
191575 -  ..
191576 - He advises there is a set of design issues that must be solved in an
191577 - internally consistent manner. The kernel will then be ready for "early
191578 - access" publication. ref DRT 1 4O8H
191579 -
191580 -
191581 -
191582 -
191583 -
191584 -
191585 -
191586 -
1916 -