Paul Fernhout
pdfernhout@kurtz-fernhout.com


Date: Thu, 31 Aug 2000 18:34:50 -0400



From:   Paul Fernhout
pdfernhout@kurtz-fernhout.com

Reply-To: unrev-II@egroups.com Organization: Kurtz-Fernhout Software

To:     unrev-ii@egroups.com

Subject:   Termites and open source

This is a URL to think about in the context of an open source effort to build something complex like an Open Hyperdocument System / Dynamic Knowledge Repository:

http://www.imaginiz.com/provocative/organize/termites.html

There are some comments on management at the end of that page. But to motivate you to read, here is an excerpt (written by Gareth Morgan) from how termites build their mounds:

The ground on which they start to build their nest is quite flat. The termites begin their work by moving earth in a random fashion. Gradually, distinct piles of earth begin to emerge. These then become the focus of sustained building activity, resulting in columns located in more or less random positions. These are built to a certain height, then construction stops. When columns emerge that are sufficiently close together, building resumes until they are joined at the top to form a rounded arch. In this way the termite nest evolves as an increasingly complex structure, with the arch as the basic unit. The approach eventually results in a kind of free-form architecture, comprised of interlocking caverns and tunnels that are ventilated, humidity-controlled and beautifully formed. African termite nests may rise twelve feet high and measure a hundred feet across. They can house millions of termites. In terms of scale, they're equivalent to human beings creating a building over a mile high. ....

The "masterpiece" evolves from random, chaotic activities guided by what seems to be an overall sense of purpose and direction, but in an open-ended manner.

One of the things about the unrevii project is that it seems in operation effectively a top-down approach with a pre-architected nest. To attract open source developers, a bottom-up termite-like approach might work better. It is less risky for an open source developer to build their own little pile they like and which makes sense to them and to then offer it under some terms they choose to the rest of the world (which accepts or rejects it as the world sees fit), than to build some custom part they have less interest in as part of a grand design that may or may not ever be complete enough to use.

What we need IMHO is some good "rules" for unrevii so we can be good OHS termites.

Not to harp too much, but for me, I believe the "Permission to Use" rule

http://www.bootstrap.org/dkr/discussion/1087.html

...(specifically the indemnification clause as it relates to software patents) may prevent such self-organizing from happening on this list until that is resolved.

At least it does for me -- Eugene Eric Kim has graciously offered to look into the legal validity of my concerns, even though many including Eugene do not share my concern. I feel "Permission to use" makes it risky for developers to talk about their own related open source efforts on this list, lest that be taken to mean they are contributing their code under "Permission to use" (even though they might be happy to contribute it under an open source license of their choosing which disclaims warranty, liability etc.). Thus, the piles such developers may be building will not find a discussion here -- and thus never be connected with other related piles produced by other list members.

For me, "Permission to use" would be much more effective it if related specifically to the content of the mailing list (or the finished classroom video stream naturally), had a clause promising preserving attribution and keeping content intact, and said nothing about code contributions. Then code contributions could be negotiated and accepted into a "main release" after licensing negotiation with the organizers of any particular larger effort.

I feel creating an unlimited scope agreement is self-defeating as developers just won't contribute (and possibly might not hold up in court anyway as it is overly broad and not signed).

Obviously a list charter and peer pressure would prevent a developer of proprietary software with no open source component from hawking their wares on the list, and one would expect (demand?) that any code posted to the list be put under at least one specific open source license (or made public domain) by the poster at the time of posting in exchange for others reviewing it. So, to an extent "Permission to use" addresses many issues perhaps better handled by a list charter.

As I see it, there are at least four separate activities going on here:

  1. Discussion of world problems (mostly faded)
  2. Discussion of other related development efforts (posting links, etc.)
  3. Discussion of individual's own efforts in the open source software arena
  4. Development of a branded "Open Hyperdocument System" by Bootstrap

Activity D) has moved onto the OHS lists. However, I think A, B, and C still have much validity on the unrevii list. Obviously A is the most problematical past the end of the official colloquium because it is so much more controversial (and thus I am not overly mourning its slowing down for the moment -- though it was fun while it lasted). B is continuing to happen, and for me has been the greatest value of this list. C has mostly happened at the start, and then happens occasionally in the context of D. It doesn't happen for me because of "permission to use". And, as long as it only happens in the context of D (which is a very specific effort), the sort of termite-mound-like self organizing process may not happen -- because fundamentally what self organization may produce may be unlike what has been anticipated, in part since that spec is only talking about the next level of bootstrapping, not necessarily the level beyond that, etc.

We have through termite-like processes already built quite a resource in the unrevii list in the B area of seeing what is currently going on around the globe in the direction Doug and others set off in back in the 60s.

Obviously, I think the OHS Framework document:

http://www.bootstrap.org/alliance-980.htm

...should be early reading for unrevii "termites" to provide "an overall sense of purpose and direction"

One may think money (i.e. grant funding or an investor) will solve this problem because in a sense money provides the money receiver a limited scope of dictatorial powers that lets one attempt top-down implementation rather than bottom-up (thus implementing the spec at the previous link exactly), but even with money I think the bottom-up process has a lot to recommend it. There are a lot of things one could do with money of course (and programmers need to eat, etc.), but money only gets you so far. It has been said that ultimately almost all intellectual labor is volunteer because of the wide range of productivity among individuals and the difficulty of immediately measuring effective results or rewarding them on a timely basis. Money can buy you someone sitting at a desk but it is hard to buy their true engagement with a problem. That engagement happens for other reasons -- the money at best just makes it possible for the person and the reasons to come together. Some more commentary on this topic of money and creativity may be found here:

http://www.gnu.org/philosophy/motivation.html

I think the termite approach to open source development would be more fun, and fun is an important part of a successful effort.

Just some thoughts.

Sincerely,

Kurtz-Fernhout Software


Paul Fernhout

Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com