At 01:04 PM 5/17/2001 +0000, you wrote:

elearning has an article about using BLOGs for KM.

http://www.elearningpost.com/elthemes/blog.asp


Jumping from that article to a talk by John Seely Brown at http://www.creatingthe21stcentury.org/JSB10-Open-source-dev.html, we find the following quote in the context of his study of the Linux project:

"What's interesting to me is now to go back and try to understand the social dynamic of the open source consortium. What you basically had was a small center of people, and a czar. And that czar was going to determine what was going into that operating system and what wasn't. But the code was completely open. Anybody could pick up chunks of it. Anybody could improve it. You could map those improvements, and take them back to the central committee. If this central czar liked it, it would go into the operating system with your name attached to that code.
And what became interesting to some of us studying this thing, first of all, for the first time in my life that computer scientists started to write code that was meant to be read by others. Unless your colleagues could read the code, they couldn't pick it up and learn from it. They couldn't pick it up and modify it. So the open source consortium, although it was never talked about this way, became a massive learning community, in terms of sharing of best practices by being able to make code transparent, readable, experimental and changeable.
So not only was it a learning community, but it was a knowledge creation community. Because basically these kids would pick up this code, modify it, see if it was better, pack it, and ship it back in. And if it made back in, you became a hero. And so it was a very interesting dynamic.
It led to a new way of being which I think is going to become much more dominant as we move into the 21st Century, it's a sense of engagement, not just narrative construction but by what I call bricolage. Bricolage, again moving from worshipping the abstract to working with the concrete. Working with the concrete, in terms of here is a concrete piece of code. For those of us who write systems, code is concrete, not abstract. The algorithm may be abstract but the code is concrete. And you take this chunk here and you start tinkering with it. Bricolage has to do with tinkering. Tinkering with a piece of concrete code, seeing whether you can make it better. Engaging in that bricolage until you have something that you think is better and then ship it back into the debate, and then if it is accepted, you increase the social capital for yourself. So this whole phenomenon is pretty interesting.
I have talked a lot about learning and knowledge captured in a very simple way. That's not the whole story. The really interesting question to me is: if you capture and share incremental knowledge, what's the ability to be able to stimulate radical knowledge, the creation of radical innovation, and so on and so forth. "

It strikes me that the solutions to the complex, urgent problems that Doug Engelbart talks about are most likely to be found in the *radical knowledge* to which Brown refers.

Bricolage strikes me as another term for evolutionary programming.  It is in the spirit of Bricolage that I started the Nexist project at http://nexist.sourceforge.net
In that project, I am tossing out ideas that need to be tested and understood.  In that project, I am encouraging others to fork any part of Nexist and explore some other ideas.  Bricolage, indeed!

Cheers
Jack
Yahoo! Groups Sponsor

www.

[ ... ]