Thanks for effective work on the license issue, and other matters Paul cites.
Just a comment though.
Licensing is a legal issue. At some point a lawyer will draft a document and
people will be asked to sign it. Typically, we need legal advice on issues of
notice, disclosure, rights and remedies, risks and so on. So far that is
lacking in the record. Second, the project needs funding to proceed
meaningfully. The source of the funds will have a say in the license issue.
A predicate to licensing, is developing something that justifies time and effort
of high priced lawyers and other consultants to invest time. Thanks to your
leadership, the SRI seed team is making good progress, as shown in the record of
the meeting on 000615...
...although it would be easier if the KM conceptual framework was a little
easier to crack.
On 000419 Doug wrote to the seed team and suggested we work on formulating a
definition of knowledge management. I am not sure, but he may have mentioned
this previously, something to do with Bellinger. Joe Williams mentioned later
that Doug brought this up again at a meeting on 000504. When the boss brings up
the same thing over and over again, that sounds important. Yet, we get bogged
down in endless discussions about license, Zope, Soap, Wiki, Squeak, Slop Jock,
and so on, without any effort to explain how they contribute to moving from
information to knowledge management. On 000424 Adam Cheyer wrote to the DKR
team and urged that we "listen" to Doug. He did not explain how such listening
is established. One way might be to do the workup on KM that provides a basis
for a DKR. It is not enough to wave Doug's papers in air, and say, "It's all in
You have a little bit of a start in the glossary. Tie it to Doug's writings,
especially his 1972 paper. Synthesize that material with Bellinger's, your own
work on 000504, Jack's work on 000516, Joe Williams offered good ideas on
This is an ideal research project, and you have plenty of stuff to draw upon
without taking a lot of time. Skipping over this predicate step, will cause
continuing delay and disappointment, as reported by Lee on 000324.
This is not to say, that the team must start out on a grand voyage into the
abyss of creating a technology that is undefined. The email track Eric proposes
will eventually get you there as a subset of his requirements, which are getting
close to the kind of editor needed for KM. My only point is that you have the
information and talent at hand, so go ahead and do the work up on KM that sets
Hope this is not too pushy. You are doing a great job on a job that is bigger
than it seems.
Eugene Eric Kim wrote:
> Several things are clear from Paul's post, first of which is that there
> are several misconceptions that need to be clarified. I'll try to do that
> On Tue, 13 Jun 2000, Paul Fernhout wrote:
> > * Doug is looking for SRI (or a similar group) to do the heavy lifting
> > again. Frankly I believe many of the same forces that killed his work at
> > SRI in the past will in the future prevent SRI from doing the right
> > thing with it -- not "something", but "the right thing". While SRI
> > personnel have done incredible things, SRI is still an entrenched part
> > of the pre-internet economic order. It would be a great coup for Doug to
> > get SRI to implicitly admit their mistake in letting go of Augment by
> > taking it back (like an old lover admitting how wrong they were to push
> > one away). The question is, has SRI really changed since then?
> First, SRI didn't kill the original NLS project; DARPA did by not funding
> the project. Second, Doug isn't looking for SRI to do any "heavy
> lifting"; SRI is currently acting as an umbrella group to provide
> infrastructure, such as the office space we use for our meetings. Third,
> Pat Lincoln and Lee Iverson, two SRI representatives, have been tremendous
> contributors to the group.
> > * Bootstrap is a for-profit company and is having trouble making the
> > transition to open source, and also lacks some credibility because it is
> > for-profit.
> Who here on the list thinks that this project lacks some credibility
> because of its legal status? Legal complications over BI's status is one
> of the reasons Doug sought SRI's help. SRI is a non-profit organization
> -- a point I think people on this list miss. It also has in-house
> counsel, a luxury that BI does not. The reason BI is not currently
> nonprofit is that it lacked the manpower to fill out the proper
> forms. But I don't see how the legal status of BI has affected the
> project in any way thus far.
> > * Many of the participants who could contribute are more busy looking
> > for a way to survive economically (possibly by selling DKR products or
> > services). Those who could contribute a small amount of effort or code
> > gratis are somewhat repulsed by this. (These two tensions can also exist
> > within the same person!) This is one reason the license has not been
> > worked out -- the commercial survival group is still looking to hold on
> > to something for an economic edge. However, there are also several open
> > source possibilities for licensing, so this is a compelx issue.
> Tension between factions is not why the license has not been worked
> out. The license has not been worked out because open source licensing is
> very complex, as you note. However, I feel like we are close to reaching
> consensus on a license. Once the minutes from last week's meeting comes
> out, you'll note that we have chosen a date for committing to a
> license: July 6.
> > * Taking handouts from Sun and Stanford has created implicit bonds
> > (choice of Java, "Permission to use" license) that make various options
> > less attractive or prevents them altogether.
> There haven't been any handouts yet. BI uses some equipment that was
> donated by Sun several years ago. I don't think Stanford has ever donated
> a penny to BI. Is there a specific instance you can see of the group
> being limited by "bonds" to either Sun or Stanford?
> > * The project did not start with "a gift of code", and so has no open
> > source credibility beyond Doug's reputation in saying that is what
> > Bootstrap wants to do. Releasing anything related to Augment under an
> > open source license would increase this credibility.
> Your first point is correct, but I don't see this hurting our
> credibility. It certainly hasn't affected our credibility with the
> various members of the open source community we've been in touch
> with. Once we choose a license, open source credibility issues shouldn't
> be a factor.
> Second, releasing Augment as open source will be a bureaucratic nightmare
> with limited benefits. Lockheed currently owns the right to Augment, and
> negotiating with them would be major pain in the rear. Also, Augment was
> written in a custom language -- L-10 -- and the compilers were written in
> DEC assembler. I'd like to see this available for historical reasons, but
> it won't have any real technical value to us.
> > * The weekly meetings in CA have created an in-group / out-group
> > situation with regards to this list. Those who are physically located in
> > CA become the in-group with privileged interactions (although thankfully
> > summarized on the list), those elsewhere geographically become the
> > out-group. While much progress is undoubtedly made with face to face
> > meetings, the Apache group didn't meet face to face for years. The
> > "in-group" does not seem to have license as a priority, because it seems
> > more composed of people figuring out a business model for funding. I
> > don't fault them for this, but it creates a tension between them and
> > open source advocates on the list who just want to proceed without
> > funding.
> This is a very valid point. As someone who has attended the physical
> meetings and who follows this list, let me try to clear up some
> misconceptions. First, any time anyone has spent trying to figure out
> business models has been his or her own. Second, Doug and Pat Lincoln
> have been doing a lot of behind-the-scenes work trying to get funding for
> the group, but that hasn't been what's slowing us down.
> What's prevented this from taking off at the pace people would like is the
> fact that there is no technical starting point yet. As you pointed out,
> successful open source projects start with code. Apache had the NCSA
> code; Linux has Linus's code; Mozilla had the Netscape code. Before you
> can have code, you need to have design. This is what we've been working
> on. Once we finish a preliminary design, we can build a prototype,
> release the code, and start gearing up the community.
> > I don't quite know how to explain this, but I feel like this group has
> > both too much structure and too little structure.
> I agree. But I'm confident the group is streamlining. It's probably more
> evident in the physical meetings right now, but it will start becoming
> more evident here as well.
> +=== Eugene Eric Kim ===== firstname.lastname@example.org ===== http://www.eekim.com/ ===+
> | "Writer's block is a fancy term made up by whiners so they |
> +===== can have an excuse to drink alcohol." --Steve Martin ===========+
> Community email addresses:
> Post message: unrev-II@onelist.com
> Subscribe: unrev-IIemail@example.com
> Unsubscribe: unrev-IIfirstname.lastname@example.org
> List owner: unrev-IIemail@example.com
> Shortcut URL to this page:
IT Professionals: Match your unique skills with the best IT projects at
Community email addresses:
Post message: unrev-II@onelist.com
List owner: unrev-IIfirstname.lastname@example.org
Shortcut URL to this page:
This archive was generated by hypermail 2b29 : Sat Jun 24 2000 - 05:43:36 PDT