(oof, this is too long, sorry folks) On Fri, May 28, 2010 at 11:07 AM, Nathan <[email protected]> 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
