[squeak-dev] mailing list VS semantic desktop
Paul D. Fernhout
pdfernhout at kurtz-fernhout.com
Tue Jan 27 02:23:44 UTC 2009
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
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"
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
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
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
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.
> 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.
> Ignacio S.
More information about the Squeak-dev