Re: [Social-discuss] Interoperability?

[Dan Brickley]

(oof, this is too long, sorry folks)

On Fri, May 28, 2010 at 11:07 AM, Nathan <address@hidden> wrote:
>
> I'll second both Mischa and Dan's comments,
>
> We already have more than enough protocols to do everything we need; caveat 
> some of them may need used together in some tasty ways, but the whole world 
> and their dog is working on that right now.
>
> So far the highest value I've seen come out of this particular group are the 
> ideas and use-cases - this work is valuable to all (and places social-discuss 
> at the center of what's going on).

Don't forget code! The folk on the gnu-social list are just the tip of
the GNU-loving iceberg. There are hundreds of thousands or perhaps
millions of developers around the planet who could respond positively
to a well crafted call-to-action.
Maybe this comparison will come back to bite me, but if you look at
the UI improvements happening on the free/open desktops, eg.
Canonical's efforts around Ubuntu integration / polish,
http://arstechnica.com/open-source/news/2009/06/canonical-to-boost-ubuntu-usability-by-tackling-papercuts.ars
 ... perhaps some similar push is needed for integration of 'social'
functionality across a variety of online services.
Have you logged into Mailman recently to administer a mailing list?
It's fiendishly geeky, resolutely of the '90s in terms of UI, yet also
incredibly powerful and something that underpins countless online
communities. We should be asking ourselves why progress on usability
and integration of these tools is taking so long. For any particular
software package - and sorry to pick on the wonderful mailman effort -
there might be a local explanation. But I think we have a regular,
recurring pattern here. The *default*, when we consider social
functionality (groups, permissions, information flow, admin panels,
permissions, chat, comment filtering and approval, etc etc.) is
towards clunkyness and confusingness. Not only do all these sites and
tools look different, they work very differently, and once you've got
your head around a particular site or tool, you don't have a
transferable skill. If I learn to administer mailing lists on eg.
Google Groups, then I'm given a list on -say- yahoo groups to run,
I'll have to re-learn a pile of similar-but-different settings. This
is true across commercial sites and across free / opensource tooling.
Making a protocol to "fix all that stuff" is terrifyingly underscoped.
But I suspect we all feel the shape of the problem. This is why a
single good-enough-for-everyone site like Facebook is so ... magnetic,
even when that centralisation brings a pile of well known problems.
How could we chop this up into work items that could be shared by a
global community of *thousands* of hackers? How can we go beyond the
hardcore of code-writers to engage the skills and enthusiasm of
interaction designers, usability experts, and other people who don't
consider the user-facing bits of the codebase something that can be
"slapped on afterwards"?
GNU has a really strong connection to the kind of people who write
compilers in their sleep, people who can make complex configuration
files sing, dance and pass turing tests; people who can understand and
remember how to use PGP, and for whom flexibility and configurability
are an essential freedom. They've written mountains of fantastic code
which -taken together- underpin as much online social malarky as any
of the monolithic megasites. But those mountains of fantastic code all
have different human interfaces, and often very little by way of the
machine interfaces that would allow others to do UI-level integration.
What I'm thinking for a work-plan is to take the best of open source
and open standards, and chose some initial projects which are
explicitly about establishing a new "division of labour" on the social
Web. This would have an initial research aspect, some surveying of
what's out there. How many mailman-powered discussion lists are there?
How many in public view? do we think the software is generally kept up
to date, so that innovations would be disseminated? How do normal
users deal with some common tasks (create a group and establish
participation and visibility rules, for eg.).

>
> thus (imho):
> 1 - support & make sure the many protocols that are out there work
> 2 - focus on use cases & requirements + being a central 'log' of all the 
> efforts that are going on.

... yes, quite. So sticking with the mailman example, and going from
bottom up (ie. existing deployed software), we might look at what it
is for, what user tasks it supports, which bits work well, which are
known to be problematic in its current form, and also -critically- try
to find developers and others who know the software and are willing to
help try to move things along in a more integration-minded direction.
And of course to humbly enquire what their existing plans are, rather
than to rush in as would-be saviours.
After that (and we'd do this for IRC / realtime chat / XMPP, for
bulletin board software like http://en.wikipedia.org/wiki/PhpBB for
Drupal, Wordpress, MediaWiki, etc etc. ... we would have a catalogue
or map of the 'raw materials'; codebases, project collaborators, use
cases, different tasks and collaboration styles that each supports.
I'd hope some of this could be done in parallel.
And then once we have this map, we can look for ways of removing
needless fragmentation, and make some sample implementations. Perhaps
for example, we could make a prototype in which the major settings of
a MailMan installation can be configured via (eg) OAuth-mediated APIs,
so that *completely new* admin interfaces could be created by
designers without needing to get their heads around the detailed
internals of the codebase. Or through which the group settings of a
MediaWiki could be similarly administered via external codebase. I
made some experiments in that direction here btw:
http://danbri.org/words/2009/10/25/504
There are a lot of packages out there, a lot of standards and would-be
standards out there. I suspect the most important code to be written
here (and a *lot* of code needs to be written) will be pretty ugly,
cludgy, boring code. Not the kind that people will be initially
excited to write. It'll be bodging APIs on to systems that don't have
APIs, digging into 10+ year old code written by someone else and
trying to figure out how to encapsulate it, so that someone else you
don't know, somewhere else in the world, can have a go at wiring on a
fresh new user interface to it. For this to get people enthused I
think we'll need a couple of short term 'wins', where we work through
what this kind of makeover could mean for a much loved but clunky free
software classic. I keep coming back to Mailman as an example but
there are many, and I guess I've been unclear whether it is the entire
package that deserves a new UI or just the admin screens. Probably
both. But if we start with what's out there already, and by learning
how real users of those real tools are experiencing them, then we can
be confident that we'll find lots of useful jobs to do. Starting with
a blank slate and wide eyes, by contrast, leaves us with a million
options and no obvious mechanism for planning.
So --  1. map what's out there, tools/software, people, what the
software does and what it could do better 2. Look for commonalities
across these, where similar tasks are handled differently 3. Apply
pragmatic mix of hacking and open standards to create machine
interfaces that allow UI to be improved / added / replaced without
deep knowledge of specific codebases 4. Pick some basic
socially-oriented tasks, and push through to a v1 'makeover' for some
selected software projects, showcasing possibilities for a single
(improved and improving) user interface to be attached to different
codebases.
Back to my mention of Canonical/Ubuntu ... here's the Mailman page on
the Launchpad directory,
https://launchpad.net/mailman
Here is the blurb,
"The GNU Mailing List Manager, which manages email discussion lists
much like Majordomo and Smartmail. Unlike most similar products,
Mailman gives each mailing list a web page, and allows users to
subscribe, unsubscribe, etc. over the web. Even the list manager can
administer his or her list entirely from the web.

Mailman also integrates most things people want to do with mailing
lists, including archiving, mail <-> news gateways, and so on. It has
all of the features you expect from such a product, plus integrated
support for the web (including web based archiving), automated bounce
handling and integrated spam prevention."

... all kinds of status info up there, including eg

"42 active branches owned by 23 people and 5 teams, 19 commits by 3
people in the last month"

Bugs: https://bugs.launchpad.net/mailman

>From a quick look there, I see a bug re openid support,
https://bugs.launchpad.net/mailman/+bug/266836 and one around Atom/RSS
https://bugs.launchpad.net/mailman/+bug/317453 ... also some issues
around NNTP interfacing/bridging, plus integration of Spamassassin.

I suggest we could do much worse than sit down and read through the
bug lists for a lot of this kind of software. Spam / trust issues,
login and group management and open protocol implementation are all
there in the first page of bugs for mailman.

Here's phpbb, https://launchpad.net/phpbb ... with their issue tracker
over on sourceforge:
http://sourceforge.net/tracker/?atid=975058&group_id=7885&func=browse
... (OpenID jumps off the page there btw) and over here
http://blog.phpbb.com/2010/04/02/introducing-jira-%E2%80%93-the-new-bug-tracker/
... apparently there's some use of JIRA for issue tracking. ->
http://tracker.phpbb.com/secure/Dashboard.jspa

I won't dig out the urls for wordpress, mediawiki, drupal and their
countless extensions. There's clearly a lot to look at. While we
shoudn't get lost in the detail, the prize here is planet-wide
integration of dozens (well, hundreds, thousands...) of packages which
together provide millions of users a rich, varied and evolving set of
options for online community. The Launchpad.net site tracks 18,640
projects. These don't fall cleanly into "social" and "non-social";
even solitary use tools like laptop media players have huge potential
for integrating with other sites, and the more standards support we
have, the greater the chances of enriching the majority of these
tools. Thousands of projects, thousands of developers, millions of
users, millions of bugs... where to begin...? :)

cheers,

Dan