Community Engine NG - espians

Community Engine NG

From espians

Jump to: navigation, search

Contents

Introduction

Over the last few years, there has been a lot of excitement over so-called "Social Software", such as blogs, wikis and most notorious of late social networking websites such as the apparently unstoppable Facebook. These "social media" have been successful at bringing people together and enabling them to communicate.

Often what happens is that established or new groups converge on these sites. These groups may operate primarily in a real world context or alternatively primarily in an online context. Such groups will use the sites to communicate and organize to some degree. Very often the groups will come up with projects that they wish to pursue as a collective and try to make use of the features provided by the sites to enable this in conjunction with tools such as email, IM, phone and often Skype. The features provided by the sites is necessary but not sufficient to enable effective long term collaboration on meaningful projects, especially those with a real world impact.

This document proposes to outline a collaboration tool that takes the best of what is currently availabe in Social Software and adds key collaboration-enabling features into an integrated platform.

Overview

Available social software platforms like CollectiveX and Drupal which bills itself as "community plumbing" commonly have support for such features as forums for discussions, blogs for journals, wikis for documentation, storage for sharing uploaded files, personal profiles, private messsaging, webmail, calendar for event and schedule management. These are features that provide a lot of utility to the groups that make good use of them.

Imagine a group is like a living thing. One biological definition of a living thing is "Something that makes autonomous decisions". Do groups need to make autonomous decisions? They most certainly do. A group forms because of the members have something in common. Perhaps they live in the same locality, have a shared interest, or a shared practice or some combination of those. A group frequently needs to make decisions on what activities they will do together, on how to make best use of the resources they share, on how to pursue their common goals.

So groups need to make decisions, what else do they need to do? They need to take action on their decisions, they need to take in information and resources from the outside environment, they need to manage existing information and resources, they need to send out information and resources. This suggests a set of features that aren't commonly available in existing Social Software and never in the same platform. Features such as voting for decision-making that is more sophisticated than the common polling seen in many applications; project and task management to handle the taking of actions in a transparent and accountable manner; managing existing and incoming information with the ability to tag, rate/rank, comment on and/or annotate articles, bookmarks and rss feed items; transparent management of finances, physical assets and other resources; community currencies to incentivise the successful completion of tasks and encourage efficient use of shared resources.

It should be noted that once the above capabilities are in place, they can be mixed and matched in interesting ways such as combining voting, accounting and possibly community currencies to enable demand-based referenda.

If the proposed features are combined with the already available Social Software features, the result will transcend the existing "social media" and become what I call a CommunityEngine where the resulting impact on collaboration will be greater than the sum of its parts.

Decision-Making

Community Currencies

Project/Task Management

Accessibility for the Disconnected and/or Iliterate

For the illiterate, there are a number of possiblities. A voice interface would be one option, another would be a buddy system where they are paired up with a trusted literate person who can interact with espra on their behalf.

For the disconnected, you can fallback on things such as SMS and MMS. For those who don't even have any sort of access to a mobile phone, the fallback is essentially database publishing. Printing out a personalized newspaper based on their profile taken from espra. There are confidentiality issues that will have to be thought through in that context but there are a number of ways of tackling that. It's a question of determining the most robust and secure method that makes sense in the context.

Different Types of Community with Different Needs

Almost all of the above is predicated on the various types of communities having common needs. The fundamental differences between the types of communities means they do have disparate needs in some aspects. For example, communities based on locality would find a local map useful with information on things such as local crime, property values, local facilities and businesses, etc.

Conclusion