Powered by Elgg

George Roberts :: Blog :: Attending to the needs of the Emerge project

July 01, 2007

A note of discussions with Joe Rosa, Emerge Technical Lead.

This note is principally derived from a meeting held at Oxford Brookes University on 27 June 2007, but draws on previous calls and conversations and a subsequent discussion on 30 June 2007.

Since starting as technical lead for the Emerge project (25 May 2007), as well as working to keep systems running, Joe has been gathering requirements through:

  • discussion with the Emerge Team and members of the community;
  • probing the applications and hosting environments;
  • setting up an Elgg mirror server;
  • participating in a number of wider community events.

Joe has:

  • Supported Online Activity Days by providing a Moodle VLE (http://vle.jiscemerge.org.uk/) and technical support to users of the Elluminate platform and engaged as participant-observer member of the community;
  • Attended OSS Watch seminar on 20 June 2006, on the role of community in software development and the relevance of community to JISC development projects;
  • Attended meeting on 21 June 2006 with Bill Olivier, JISC Development Director for Systems and Technology, George Roberts and the Imperial College Internet Centre team; the aim of the meeting was to review the Imperial Mash-up Toolkit, but the discussion ranged widely across JISC developments and the support of development communities;
  • Attended a “Barn Raising” session in Leicester on 26 June 2007, which Josie Fraser, Lead Community Architect, organised to consider the development needs of the Elgg platform;
  • Attended meeting with Tony Linde, Ross Gardler (new Head of OSS Watch, ) and Anjana Batterjee (aporia) on 28 June 2006 to understand the role of OSS Watch in respect of the Emerge community presence project;
  • Participated in Emerge core team phone conferences and face to face meetings;
  • Met regularly with the Project Director

At our discussion I was mindful of the Appreciative-inquiry (Ai) approach taken by the Principal Investigator, Rhona Sharpe.

Joe has been peripherally involved with the Apache Foundation and the Open Source Portfolio (OSP) project. While not following the structure of these probes, this discussion is based on the Apache Foundation’s approach to open-source software development communities: communities of purpose.

Vision

We avoided discussion of the wider definitions of community. We are explicitly concerned with the scope of the community envisaged by the JISC Users and Innovation (U&I) Programme, and even more explicitly and narrowly with the community forming around the Emerge Project. If we were to follow Scott Wilson’s typology as set out in a presentation to ALT and SURF in 2006, “Social Software”, we are concerned with communities of purpose or action. Although the Users and Innovation Programme community is not a software development community, it has many features in common and many members are, or have been, part of software development communities. Emerge is explicitly a community development community, or maybe better put, an educational development community of software and educational developers. A community of this sort has: roles and tools .

Roles

There are three broad roles within communities of purpose:

  • users
  • contributors
  • managers.

The user is the evangelist for the project, the bug finder and the requirements generator. The contributor is the supporter of the user, and the management is the support for the contributors. We avoid the term “leader” because leadership can have many dimensions and a community may have several leaders.

Users

Without users, development activity is “pure research”: navel gazing. JISC does not fund pure research. JISC’s role is to fund the development of solutions to real challenges facing education and particularly Higher Education. JISC is funded by a topslice of the moneys allocated by HEFCE to universities. As such, JISC is answerable to universities and must show value to them.

The pupose of the community in this model is solely to support the users. Without users there is no community and without community there is no hope of sustaining the software. The Apache Foundation takes a strict view on incubation. A developer might apply to the Foundation to become a project within the Foundation. But, that project will stay in incubation and will not be released unless it can be demonstrated that there is a community of users supporting the development, and that the development responds to the needs of the community.

This is the basis of the Users and Innovation Development Model (UIDM).

Contributors

If there are users, there are needs. If there are needs, there are contributions. Contributions may be in the form of requests for features or repairs. Contributions may be in the form of bug-tracking, FAQ writing, or documentation. In practice only a relatively small number of people contribute code.

Management

If there are needs they need to be managed or chaos ensues. There can be many styles of management and management is different from leadership. In this model, there are three functions of management. These three functions are not clearly demarcated, but support one another:

  • Marketing is concerned with establishing priority of needs.
  • Governance is concerned with order, control and resourcing; ultimately direction will be set and compliance assured by management.
  • Documentation has three categories:
    • strategy, including mission, aims, policies, promotions
    • guidance for users, including how-tos and user guides; and for developers, including technical documentation, etc
    • legal and corporate records for audit and control, including compliance, financial records, IPR, licensing, insurances, etc

Tools

A software development community needs five basic tools:

  • website for providing co-ordination, linking, overview “map” of the territory
  • mailing list and related communication and discussion tools for the community such as blogs and forums
  • issue tracker
  • document management
  • version control for releases.

Arguably a community development community does not require version control for software releases.


Overview for Keywords: appreciative inquiry, community, platform, Web 2.0

Posted by George Roberts


Comments

  1. George - I am not so sure I understand all of this post.

    You say

    "If there are needs they need to be managed or chaos ensues. There can be many styles of management and management is different from leadership. In this model, there are three functions of management. These three functions are not clearly demarcated, but support one another:

    • Marketing is concerned with establishing priority of needs.
    • Governance is concerned with order, control and resourcing; ultimately direction will be set and compliance assured by management.
    • Documentation has three categories:
      • strategy, including mission, aims, policies, promotions
      • guidance for users, including how-tos and user guides; and for developers, including technical documentation, etc
      • legal and corporate records for audit and control, including compliance, financial records, IPR, licensing, insurances, etc"

    This sounds a rather top down approach. Earlier you talked about communities of practice or  community development community. I would prefer to view rules etc. in an activity context - with rules emerging fromt the community and the context of the activity rather than being "set and compliance assured by management".

    Equally I am not sure the notion of a software development community transfers so unproblematically to a community development community. 

    Or am I misunderstanding you?

     

    Graham AttwellGraham Attwell on Monday, 02 July 2007, 13:29 BST # |

  2. "Although CurveRider declined explicitly at the outset to be a "member"
    of the core project team and were clear that they wanted to be suppliers
    to the project rather than participants, the implications of this did
    not become evident for a couple of months."

    Firstly, we were never going to be or were invited to be an active
    member of this project – we were asked to provide Elgg Spaces type
    hosting for one installation of Elgg and to skin the site, which we have
    done. There was no real budget for development and you already had your
    social software experts onboard so I am not sure what you wanted us to do?

    "Elgg is not universally "loved""

    If one is trying to foster a sense of community, this type of phrase
    doesn't really help as is not possible to improve a platform with this
    level of analysis? We are very much interested in hearing Elgg
    criticism, as it helps us improve our software and hopefully make it
    more useful - but we need more than this!

    "Unfortunately, the Elgg developers do not appear to be going in a
    direction that can support our community."

    Again, it would be great to have this explained further. We have been
    working on social software and its potential impact on the educational
    landscape for 4 years now - well before it became a bandwagon - in a
    completely transparent and open fashion. During this time we have
    worked, and continue to work, closely with most of the large Elgg
    communities; so I am not sure what you are getting at here?

    I am wondering if perhaps some of the problems with this project have
    arisen from a lack of clear directives which focus on tangible outcomes.
    Hence the need to use every piece of software available: the answers are
    not going to come from all the 'tools' but rather what you want to
    achieve. Only then should you select tools to best meet those needs.
     
    Dave Tosh. 

    sitedevelopmentDave Tosh on Monday, 02 July 2007, 13:55 BST # |

  3. First, let me make it clear that I am new to the Emerge community and anything I say in this comment is not intended to be a comment on current or past practices here in Emerge, I am not familiar with them in any intimate way.

    Secondly, a little background about myself may help put my comments into context. In recent lives (I have had many) I have been a researcher within Universities, an independant contractor within private industry and now I  am the Service Manager for OSS Watch. Throughout all of these activities I have contributed to and worked with a great many communities, some developing software (I'm a Member of the Apache Software Foundation), some creating an understanding of a problem space (user requirements if you like) and some creating blue sky solutions to a percieved problem (peer reviewed research).

    Graham observes that community should be defined from the bottom up. That is, the members of the community should define the "rules and regulations" of that community. This is trye, however, it should be recognised that when a community is first formed it is, almost always small. There is not concept in the early stages of community of top or bottom, and so there is no top-down, or bottom-up approach to any of this.

    [NOTE: there are exceptions in which the initial community is seeded by large injections of capital, such as The Eclipse Foundation or the Sakai Foundation, but in order to reach sustainability they invariably strip the top down control and struggle to implement a bottom up mechanism]

    In a healthy community everyone feels they have a place and their voice will be heard. Terms like "governance" and "leadership" do imply that there is a "top", but this need not be the case. A governance model simply describes how decisions are made within the community. It does not necessarily impart any "power" to the individuals at the "top" of the community, in fact it is often the exact opposite, ensuring "power" does not congregate in the hands of a few, that is it keeps the power as "low down" the "structure" as possible.

    Graham says "I would prefer to view rules etc. in an activity context - with rules emerging fromt the community and the context of the activity rather than being 'set and compliance assured by management'". I completely agree with this observation, a community should be self defining and self governing. Nevertheless, it is not realistic to expect every community member to take an active role in every role within that community. Most users, for example, only care about consuming the outputs of a community - very few contribute to those outputs. Do you really want to have them dictate where the resources of those who contribute are focussed? Sure, we want users to have influence, but we do not want them to have control, that should be for those expending resources in the support of the whole community.

    Graham also wonders whether "the notion of a software development community transfers so unproblematically to a community development community." Some succesful software development communities are more concerned with community than on software code. The Apache Software Foundation, for example, maintains that if we look after the community, the code will look after itself.

    Notice, the emphasis is on community rather than software. The first stage in software development is identifying a need, a need that is defined by a user. Therefore, a software development community starts off with users, not with software developers - they come later and will always be outnumbered by the users (at least in a viable community that is the case).

    The Apache Incubator will not allow projects to graduate to being a full blown Apache Software Foundation project unless a number of criteria have been met. None of these criteria include working software, but many of them identify the need for a working community.

    Whilst many software development models are not good models for Emerge, some do have plenty to offer. Learning what can be transferred is very important.

    Ross GardlerRoss Gardler on Monday, 02 July 2007, 15:41 BST # |

  4. My last comment was getting too long, so on to my second point in a second comment...

    Dave Tosh says "the answers are not going to come from all the 'tools' but rather what you want to achieve. Only then should you select tools to best meet those needs."

    I totally agree with  Dave here. When I build a community in the real world, I do it be talking and sharing resources. That is it, nothing more nothing less. The tools needed for community development are as listed in the original post (although I've trimmed it even further):

     

    • website - for dissemination
    • mailing list - for communication (although you mayprefer a forum)
    • issue tracker - for task management
    • version control - for resource management and collaborative development

    I've stripped blogs, they may be how you provide info under your website, but they are not a communication/discusion tool as asserted in the original post (this is a blog and this is certainly not a discussion, it is a series of statments)

    I've also rolled thedocument management and version control into one. Version control is what is important, it allows multiple people to work on a document in a way that is convenient to them and it allows tracking of who did what for IPR management reasone. Document managment is nothing more than a process, often constrained by software tools, but a process nevertheless. 

    Select the minimum number of tools, create a working and welcoming environment and then, if necessary, i.e. if your community demands it and can justify those demands, add another layer on top.  

     

     

    Ross GardlerRoss Gardler on Monday, 02 July 2007, 15:58 BST # |

  5. Wow

    I want to reply to issues raised by Dave and Graham and Ross. How? 3 new blogs? 3 comments to this one? One long comment?

    Going to think over my dinner.

    Thanks for the stimulating thoughts

    George 

    George RobertsGeorge Roberts on Monday, 02 July 2007, 20:17 BST # |

You must be logged in to post a comment.