[squeak-dev] mailing list VS semantic desktop

I think this switch would be a bit too radical when we haven't even
made it to "forums" yet ;)

Mr. Fernhout, your proposal is extremely interesting and I'm looking
at it right now.

I wonder how hard would it be to integrate with the mailing list, to
have a number of monthly, weekly or daily abridges messages explaining
the changes in the semantic desktop (or even in the forums!) with
different levels of detail.

Squeak is difficult to follow like this. I've been in this ML for
years and I barely participate because I'm always afraid I'm going to
repeat a topic or spam people with a largely uninteresting topic. In
other words, I know it's intrusive to get into people's mailboxes
which is why more often than not I just shut up.

Please, let's have some less intrusive system to participate. I always
wanted to discuss traits yes or no, Nile, the future VM, ... and never
did because I know here there are many "giants" that I cannot bother
with my opinion.

Regards.
  Ignacio S.

Ignacio-

Thanks for the reply.

I too don't see this as a switch to happen any time soon. :-)

That's an interesting point you raise about how a community functions and
how someone jumps into it in a constructive way. Wikis are less obtrusive in
a way. In a sense, a Social Semantic Desktop might be conceptually somewhere
between a wiki with lots of pages each with a discussion and a mailing list
with just one stream of discussion (although with topical threads that
usually last at most a few day).

In an SSD (at least how I envison it) you'd essentially be modifying shared
objects which were used by various applications (to put it in OO terms).
(Though I'd personally implement it as triples, because I'm very concerned
about things like the history of the change of a value of an attribute of an
object, so I like the idea of such a change being a reified thing I can
refer to, not an afterthought squirreled away in a log that is only
accessible in arcane ways.)

What the applications were on top of that is a complex question and probably
the subject of much future innovation.

In a way, the deeper issue you raise is how the social dynamics of a group
maps on to the software infrastructure it uses or builds for itself. And as
the group's needs change, the software would need to change to. But, ideally
you want a distributed platform flexible enough to allow for all sorts of
changes.

A related web page on social software design and some excerpts (but the
whole thing is worth reading):
   "A Group Is Its Own Worst Enemy"
   http://www.shirky.com/writings/group_enemy.html
"""
In particular, I want to talk about what I now think is one of the core
challenges for designing large-scale social software. Let me offer a
definition of social software, because it's a term that's still fairly
amorphous. My definition is fairly simple: It's software that supports group
interaction. I also want to emphasize, although that's a fairly simple
definition, how radical that pattern is. The Internet supports lots of
communications patterns, principally point-to-point and two-way, one-to-many
outbound, and many-to-many two-way. ... Nevertheless, I think that
definition is the right one, because it recognizes the fundamentally social
nature of the problem. Groups are a run-time effect. You cannot specify in
advance what the group will do, and so you can't substantiate in software
everything you expect to have happen.
...
People who work on social software are closer in spirit to economists and
political scientists than they are to people making compilers. They both
look like programming, but when you're dealing with groups of people as one
of your run-time phenomena, that is an incredibly different practice. In the
political realm, we would call these kinds of crises a constitutional
crisis. It's what happens when the tension between the individual and the
group, and the rights and responsibilities of individuals and groups, gets
so serious that something has to be done. And the worst crisis is the first
crisis, because it's not just "We need to have some rules." It's also "We
need to have some rules for making some rules." And this is what we see over
and over again in large and long-lived social software systems.
Constitutions are a necessary component of large, long-lived, heterogenous
groups.
"""

That essay also mentions barriers to entry being a *good* thing.

Again from the above link:
"3.) Three, you need barriers to participation. This is one of the things
that killed Usenet. You have to have some cost to either join or
participate, if not at the lowest level, then at higher levels. There needs
to be some kind of segmentation of capabilities. Now, the segmentation can
be total -- you're in or you're out, as with the music group I just listed.
Or it can be partial -- anyone can read Slashdot, anonymous cowards can
post, non-anonymous cowards can post with a higher rating. But to moderate,
you really have to have been around for a while. It has to be hard to do at
least some things on the system for some users, or the core group will not
have the tools that they need to defend themselves. Now, this pulls against
the cardinal virtue of ease of use. But ease of use is wrong. Ease of use is
the wrong way to look at the situation, because you've got the Necker cube
flipped in the wrong direction. The user of social software is the group,
not the individual. I think we've all been to meetings where everyone had a
really good time, we're all talking to one another and telling jokes and
laughing, and it was a great meeting, except we got nothing done. Everyone
was amusing themselves so much that the group's goal was defeated by the
individual interventions. The user of social software is the group, and ease
of use should be for the group. If the ease of use is only calculated from
the user's point of view, it will be difficult to defend the group from the
"group is its own worst enemy" style attacks from within. "

So, that suggests that if to get the most out of the Squeak discussions
required using applications running on Squeak, that might actually be a good
thing.

Anyway, there is more I could say on the pros and cons of using a triple
store for this instead of a real multi-user OO database like Magma, but I'll
won't go into that for now, and I might be wrong. Essentially, though,
beyond the reification issue for changes mentioned above, I think social
software could be more fault-accepting of lost information (if you are
missing something, or something doesn't work right, you could ask someone
for help), and that different emphasis then opens up some possibilities for
simpler approaches that are more flexible and less likely to have bottlenecks.

Already, as I look at how Squeak is currently supported, with lots of
mailing lists and web sites, I can wonder how much better if all that was
integrated in some Squeak applications that somehow collaborated easily
(like integrating Monticello and the SqueakDev mailing list somehow).
I know that may sound silly at first -- Monticello is for package
management, the Squeak list is for discussions, yet obviously, most of what
is being discussed relates to what Monticello is used for in some way, so
one might imagine closer integration somehow. There are a lot of
Squeak-related lists now, and again, maybe those might somehow be more
tightly coupled to content on various wikis (even though you view one with
an email client and the other with a web browser).

Anyway, I guess I am not clear on what I mean, and maybe I'm not sure
completely what I mean, :-) but in general I'm saying one can try to imagine
some sort of community-oriented environment in Squeak that was more
integrated than using web browsers, email clients, IRC, and Monticello etc.
to work together. Frankly, I'm not sure what that would look like, and I
expect both at first and most frequently it would not look a whole lot
different inside of Squeak from using these separate applications. But what
I am hoping for is that using a common backend of a distributed RDF-like
triple store database, that new possibilities would be thought of for
integration. One obvious example is moderation -- one might select "Newbie"
mode and all but the most basic packages and discussions might just be
hidden or grayed out (other than one some moderator deemed appropriate for
beginners). Or when you looked at a note that discussed some package, the
package information might automatically show up in another window with its
revision history. Or when someone discusses a bug report, you could click on
something to get the bug reporting tool, which you might drag a screen shot
image into.

I really don't know what it all would look like; I'm just sensing a
potential there when one thinks of, as Clay Shirky suggests, the user being
the community and not an individual.

But, I know this goes against the grain for some, because back years ago on
the defunct list for the first try at a Squeak Foundation there was some
disagreement about whether Squeak should emphasize being a person computing
platform or a collaborative computing platform. What I'm talking about here,
generalized, would really be about pushing Squeak way more into a
collaborative computing direction (especially for discussing itself).

And certainly Squeak has already gone there several times like with Croquet
or Seaside or Nebraska. But somehow I feel those have lacked the generality
of infrastructure a distributed triple store might provide. I know, people
are probably already saying it should be a distributed object database --
and to some extent one is interchangeable for the other in theory -- it's
more a matter of emphasis. I might well be wrong on this and the Squeak
community might be happier with something that looked more conventionally OO.

Thanks again for your interest, and any more feedback is appreciated.

--Paul Fernhout

muyuubyou wrote:

2009/1/27 Paul D. Fernhout <[hidden email]>:
> Ignacio-
>
> Thanks for the reply.
>
[..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 :)
You can't write such software to respond a group needs, because such
needs are hard to formulate, changing fast  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 :)

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. :)


--
Best regards,
Igor Stasenko AKA sig.

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 :)

Igor-

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,
   http://www.shirky.com/
also wrote the book "Here Comes Everybody: The Power of Organizing Without
Organizations".
   http://www.herecomeseverybody.org/

If you read the Group essay,
   http://www.shirky.com/writings/group_enemy.html
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"
   http://wiki.squeak.org/squeak/3363
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:
   http://linux.slashdot.org/comments.pl?sid=202054&cid=16540850
"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
communities.

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.
   http://en.wikipedia.org/wiki/Message_passing
which links to Alan Kay's post here of a decade ago, with him writing:
http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html
"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:
http://en.wikipedia.org/wiki/List_of_revision_control_software#Distributed_model

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.
   http://en.wikipedia.org/wiki/Chaordic
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
something better.

> 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:
   http://www.google.com/search?q=stigmergy

At Wikipedia:
    http://en.wikipedia.org/wiki/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).

--Paul Fernhout