[squeak-dev] mailing list VS semantic desktop
Paul D. Fernhout
pdfernhout at kurtz-fernhout.com
Tue Jan 27 13:47:07 UTC 2009
Igor Stasenko wrote:
>> [..snip..] A Group Is Its Own Worst Enemy
> this statement alone defeats any possible solution for the problem, and
> any attempt to write a social software is doomed from the very start :)
I understand where you are coming from, because the title is distressing to
anyone interested in social collaboration. It certainly challenges.
I felt the same way when I saw it the first time.
The person who wrote that essay, Clay Shirky,
also wrote the book "Here Comes Everybody: The Power of Organizing Without
If you read the Group essay,
he talks about coming up with those principles from looking at the
actual behavior of lots of social software systems and groups,
and also building on a book by W.R. Bion called "Experiences in Groups".
So it's not like he's making stuff up. He's saying what actually happens
and then giving some ideas to make things better.
Even in the recent case of spam to the SqueakDev list, that's
obviously not the biggest issue Squeak has wrestled with as
a community over the past decade or so. He makes three points about
group issues where things can go wrong:
* Status/flirtatious related talk
* The identification and vilification of external enemies.
* Religious veneration of the topic/content discussed.
The first two have not been that big issues here in terms of limiting
Squeak's and the community's potential, but certainly the
third has been. Alan Kay himself has written about that -- people
venerating the past work of him and others like Dan Ingalls,
when he wants to move onto something better that Squeak,
just using Squeak to build the next good thing.
And back when I tried to get people interested in having the Squeak license
issues straightened out many years ago, I got lots of people saying it's not
an issue. Well, it's been a much tougher job to fix many years later.
But it's such a non-issue technically. The license issue is all
about "run-time" group dynamics. It's all fine to say it doesn't
matter technically, or the license was "good enough" and lets move on,
"Alan Kay on the Squeak License"
but when, say, Squeakers aren't getting to present at free and open source
software conferences, it's still a real problem. That's another example
of a group being its own worst enemy, by not having a good enough
constitution for how it operates, and maybe not even realizing that.
Something I wrote on that before:
"I think it is easy for any technologist to underestimate community issues
and then to see a license as a program for individual behavior instead of a
constitution for a community. The GPL works. It has problems, sure, but it
works well enough as a constitution for cooperation. More variants of
licenses mainly just make more problems IMHO."
That's not to argue Squeak should be under the GPL at its constitution.
Squeak is moving to X/MIT and has a foundation with a different type of
formality etc.; that's how the community that emerged overall wanted to be.
This is just to say that whatever license software is under is in a sense a
big part of the constitution of the community that works with it and changes
it. For a long time, and maybe even now still in parts, Squeak had a license
that was isolating for it from the community of free and open source
So, I can both applaud and boo Alan Kay in the same email. :-)
Other examples of individual vs. group dynamics include seeing code as about
mathematics (individual and unambiguous) instead of as about communication
and documentation (group-oriented statements about intent subject to
interpretation and revision). Or seeing OO programming as about objects
(individuals) instead of as about sending messages (meaning emerging out of
the group of objects communicating).
Clearly, Alan Kay has himself written on this last point and how "Object
Oriented" is in a way a misnomer, because most of what goes on of interest
is message passing among groups of objects.
which links to Alan Kay's post here of a decade ago, with him writing:
"Just a gentle reminder that I took some pains at the last OOPSLA to try to
remind everyone that Smalltalk is not only NOT its syntax or the class
library, it is not even about classes. I'm sorry that I long ago coined the
term "objects" for this topic because it gets many people to focus on the
lesser idea. The big idea is "messaging" -- that is what the kernal of
Smalltalk/Squeak is all about (and it's something that was never quite
completed in our Xerox PARC phase). ... If you focus on just messaging --
and realize that a good metasystem can late bind the various 2nd level
architectures used in objects -- then much of the language-, UI-, and OS
based discussions on this thread are really quite moot. This was why I
complained at the last OOPSLA that -- whereas at PARC we changed Smalltalk
constantly, treating it always as a work in progress -- when ST hit the
larger world, it was pretty much taken as "something just to be learned", as
though it were Pascal or Algol. Smalltalk-80 never really was mutated into
the next better versions of OOP. Given the current low state of programming
in general, I think this is a real mistake. ... I think I recall also
pointing out that it is vitally important not just to have a complete
metasystem, but to have fences that help guard the crossing of
metaboundaries. ... I would suggest that more progress could be made if the
smart and talented Squeak list would think more about what the next step in
metaprogramming should be -- how can we get great power, parsimony, AND
security of meaning?"
The whole email he wrote is worth reading again, obviously, though I would
be curious ten years later on how Alan Kay feels now about the meta-level
fences idea as a metaphor. For me, another idea which is related or perhaps
analogous to emphasizing message passing versus objects (and is also
somewhat related to some of the meta-level fences idea Alan Kay mentions
there) is the reification of changes in a triple store of which an object
memory is essentially a cache of the state of some part of the store at some
point in time. I see this reification of a "change" that is referenceable
and discussable as being crucial for flexible social software using a
distributed database. Such a database in the way I see it could be thought
of as like Bazaar, git, GNU arch, Mercurial, Darcs or one of the other
distributed source code control systems; here is a list:
So, I'm interested to see thing like a "change" or a "transaction" as being
eternal and discussable. The image that comes to mind is two programmers at
one machine looking at a version of a method in Envy source control system
to figure out why it was changed. But taking that further, for a social
system, I'd suggest one should be able to reference each part of the history
of the value of any attribute of an object of significant social interest,
so you can then build tools to help groups manage their shared state (or
some shared part of their collective Social Semantic Desktops). But the
"virtual object" itself defined by changes can be seen as being mutable over
time. Lisp and some more modern functional programming systems trying to
move in a new direction often try to see an "object" as immutable and
enforce that in static languages and runtimes (in part for machine cycle
efficiency reasons but also for conceptual reasons), which is a related but
in some ways inversely different perspective (more like a focus on objects
than messages). Obviously, if you model a "change" as an essentially
immutable "object", then the two paradigms can interrelate. There are
probably a lot of ways to do this (and there is a big literature on
distributed systems); I just have my own perspective and implementation
ideas on this.
Anyway, enough on trying to draw parallels between human groups and groups
of virtual Smalltalk objects sending messages which can create eternal
transactions listing immutable changes added to massively-redundant
distributed databases which define virtual Smalltalk objects. :-)
Shirky goes on to write:
"So these are human patterns that have shown up on the Internet, not because
of the software, but because it's being used by humans. Bion has identified
this possibility of groups sandbagging their sophisticated goals with these
basic urges. And what he finally came to, in analyzing this tension, is that
group structure is necessary. Robert's Rules of Order are necessary.
Constitutions are necessary. Norms, rituals, laws, the whole list of ways
that we say, out of the universe of possible behaviors, we're going to draw
a relatively small circle around the acceptable ones. He said the group
structure is necessary to defend the group from itself. Group structure
exists to keep a group on target, on track, on message, on charter,
whatever. To keep a group focused on its own sophisticated goals and to keep
a group from sliding into these basic patterns. Group structure defends the
group from the action of its own members."
Oops, I guess that point on human groups and Robert's Rules of Order etc.
might sound a lot like Alan Kay's suggestion above of fences to guard
metaboundaries in future OO message-passing systems? :-)
A related idea:
"Meshwork, Hierarchy, and Interfaces" by Manuel De Landa
"To make things worse, the solution to this is not simply to begin adding
meshwork components to the mix. Indeed, one must resist the temptation to
make hierarchies into villains and meshworks into heroes, not only because,
as I said, they are constantly turning into one another, but because in real
life we find only mixtures and hybrids, and the properties of these cannot
be established through theory alone but demand concrete experimentation.
Certain standardizations, say, of electric outlet designs or of
data-structures traveling through the Internet, may actually turn out to
promote heterogenization at another level, in terms of the appliances that
may be designed around the standard outlet, or of the services that a common
data-structure may make possible. On the other hand, the mere presence of
increased heterogeneity is no guarantee that a better state for society has
been achieved. After all, the territory occupied by former Yugoslavia is
more heterogeneous now than it was ten years ago, but the lack of uniformity
at one level simply hides an increase of homogeneity at the level of the
warring ethnic communities. But even if we managed to promote not only
heterogeneity, but diversity articulated into a meshwork, that still would
not be a perfect solution. After all, meshworks grow by drift and they may
drift to places where we do not want to go. The goal-directedness of
hierarchies is the kind of property that we may desire to keep at least for
certain institutions. Hence, demonizing centralization and glorifying
decentralization as the solution to all our problems would be wrong. An open
and experimental attitude towards the question of different hybrids and
mixtures is what the complexity of reality itself seems to call for. To
paraphrase Deleuze and Guattari, never believe that a meshwork will suffice
to save us."
So, there is perhaps a convergence or consilience of some ideas here from a
few different levels and authors about a few different topics relating
perhaps to some common design patterns? They would all relate to having a
meshwork of communicating objects as well as sets of rules for parts of the
network being hierarchically organized to varying appropriate degrees. They
would include ideas about ways the system can transcend parts of its current
configuration in an experimental way to new hybrids and mixtures. I
personally have long like the Chaordic ideas which capture some of the
flavor of this, and in a way it is a sort of design pattern.
But implicit in that is the sense in which "a group can be its own worst
enemy", meaning that problems that arise out of internal functioning of a
group can be worse than any external threat. A Smalltalk analogy might be
when you change a Smalltalk image so that opening an error window
unfortunately opens another error window, etc. locking up the system and
which is often just as harmful to your user experience as if the computer
memory got corrupt somehow by another external process writing over it.
Which happens more often these days in developing in Smalltalk?
So anyway, I understand your reaction to title, but I still feel there is
some substance there other than what you might expect. And while I just
cited it as a general reference to writing social software, as I
reflect on it, I can see that those very issues (especially veneration) have
negatively effected Squeak's development in a sense to thwart the very goals
Alan Kay and others had in releasing Squeak as a stepping stone to
> You can't write such software to respond a group needs, because such
> needs are hard to formulate, changing fast
Well, if the platform is dynamic, like Squeak, isn't the point of such a
system (along with an ideal like Extreme Programming) to keep up with that?
> and, as always, any innovations will take much oppression from most
> conservative members. In most cases, the only sensible solution , and
> most easy to follow - is to maintain the status-quo :)
Again, Shirky addresses a lot of that in his essay, like getting beyond
"Religious Veneration" of the topic. So, in that sense, you definitely
are agreeing with part of the essay. :-)
> A large communities behavior can be compared with group of ants who
> dragging their catch to their hill - if you look at particular ant, you
> often can see that he tries to drag in opposite direction. But anyway,
> sooner or later a catch will always get into the nest despite individual
> attempts to drag in wrong direction. :)
On your ant analogy, I agree with you, and a general name for that
sort of thing is Stigmergy:
"Stigmergy is a mechanism of spontaneous, indirect coordination between
agents or actions, where the trace left in the environment by an action
stimulates the performance of a subsequent action, by the same or a
different agent. Stigmergy is a form of self-organization. It produces
complex, apparently intelligent structures, without need for any planning,
control, or even communication between the agents. As such it supports
efficient collaboration between extremely simple agents, who lack any
memory, intelligence or even awareness of each other."
I see the Social Semantic Desktop idea as a way to make it even easier
for people to participate in stigmergic processes for creating digital
artifacts (and someday with 3D printers, physical artifacts).
A key idea for me is a system where standard free and open source licensing
is a default option for all contributions, to avoid the sort of
licensing and relicensing issues that have plaqued some projects
(including Squeak, but also many, many others, usually the ones you
don't hear of because they went wrong as collaborations so early).
More information about the Squeak-dev