PEER Sustainability

Nicole Harris

 

 

Abstract:

 

Table of Contents

 

1. Background ...............................................................................................................

2. Use of software .......................................................................................................

3. PEER as a Service ...................................................................................................

4. Sustainability .........................................................................................................

6. Annex 1 – Meeting PEER Requirements .....................................................................

7. Annex 2 – REFEDS Hosting ........................................................................................

1. Background

 

The PEER project was funded as a REFEDS work-item in 2011, primarily through funds donated by ISOC.   The first phase of the project has created a working beta( http://beta.terena-peer.yaco.es/ ) and implementation documentation ( http://packages.python.org/peer/ ) against the scope design for the project ( https://spaces.internet2.edu/display/PEER/ ) .  The second phase (2011/12) will address additional requirements and fixes identified during phase one, as identified in the project software backlog ( https://spaces.internet2.edu/display/PEER/PEER+Software+Backlog ). 

 

Beyond these initial development phases, there are on-going sustainability and development costs identified for PEER:

 

  • Metadata validator and publication from R&E PEER instance;
  • Hosting costs for R&E PEER instance;
  • Ongoing software maintenance and development. 

2. Use of software

 

It is expected that there will be several instances of PEER in operation serving different communities.  As a generic metadata registry, individual federations that do not currently have an effective automated tool for registering entities could use the PEER software.  Different federation spaces – such as health or government – may wish to focus on PEER service for their environments. 

 

The PEER software will be made available as an Open Source release under a BSD license.  The software currently resides on github ( https://github.com/Yaco-Sistemas/peer/ ), a social coding site.  Hosting of the software here is free as long as it is made available under an open source license.   IPR in the software resides with TERENA on behalf of REFEDS. 

REQUIREMENT: PROMOTE PEER SOFTWARE TO R&E FEDERATIONS AS AN INTERNAL TOOL AND TO FEDERATIONS WORKING OUTSIDE THE R&E SPACE.

3. PEER as a Service

 

It is expected that research and education federations will want to trust a single instance of PEER where possible in order to effectively integrate its feeds in to their metadata.  Whilst multiple uses of the software is a desired outcome, it will be more effective from a management point of view for R&E federations to have a core trusted PEER instance, and interact with other instances only when required. 

REQUIREMENT: CREATE AND MAINTAIN A PEER SERVICE INSTANCE FOR RESEARCH & EDUCATION FEDERATIONS

4. Sustainability

 

  • Service sustainability.

 

Whilst PEER as a service is not designed to require significant central administration, there will be costs associated with maintaining the service such as server and hosting costs, helpdesk queries and support queries.  REFEDS itself its an obvious host for the service, but this raises interesting questions about the remit of REFEDS - does REFEDS intend to become a permanent host of resources or services, or does it aspire to be a catalyst for development, which is then hosted elsewhere?  The REFEDS Steering Committee should discuss these requirements and the long-term impact hosting requirements may have on the REFEDS budget.

 

As the host for REFEDS, TERENA will need to be both willing and able to provide the support for sustainability that is emerging from REFEDS projects.  REFEDS should present a clear business case to TERENA for the effort involved.  Annex 2 tries to capture the range of hosting and sustainability requirements that are emerging. 

 

Another model to consider would be to ask participant organisations to donate hosted space as part of their contribution to REFEDS – NorduNET may be a good candidate for such an arrangement.

REQUIREMENT: DEFINE REFEDS POSITION ON LONG-TERM SUPPORT FOR REFEDS PROJECT

  • Software sustainability. 

 

As demonstrated by phase1, PEER is likely to be an evolving product with new functionally identified as the software is used in service environments.  More intense use will also inevitably lead to bug fix requirements as well as new function requirements.

Funding has been agreed to support PEER for an additional phase of work within 2011.  REFEDS will need to agree a forward-looking plan for how both maintenance and new features will be handled from 2012 onwards. 

 

REFEDS may wish to consider a lightweight agreement with Yaco Sistemas to cover bug fixes once a stable version of PEER is released.  A position on the open source nature of the software and management should also be considered – will REFEDS seek maintenance from the community and who will manage updates and releases for future versions of the software?

REQUIREMENT: DEFINE A MAINTENANCE AND RELEASE PLAN FOR PEER SOFTWARE

6. Annex 1 – Meeting PEER Requirements

 

 

REQUIREMENT

PROPOSED ACTIONS

1

Promote PEER software to R&E federations as an internal tool and to federations working outside the R&E space.

  • Create a PEER website at peer.refeds.org.
  • Ask REFEDS participants for interest in PEER software and service.
  • Promote at international conferences such as I2, Kantara events and APAN.

2

Create and maintain a PEER service instance for R&E federations

  • Discuss hosting arrangements with NorduNET, TERENA, others?
  • Define potential hosting costs.
  • Agree contact point (contact@refeds.org)??

3

Define REFEDS position on long-term sustainability of REFEDS projects

  • Paper for steering committee based on Annex 2?

4

Define a maintenance and release plan for PEER software

  • Agree github as a home or seek alternative home?
  • Discuss on-going maintenance contract requirements.
  • Agree software management approach.

 


7. Annex 2 – REFEDS Hosting

 

As an organisation, REFEDS is at a point where it should consider a strategy for sustaining the outputs of its projects.  The following list describes most of the scenario that need to be supported. 

 

  1. Website ( www.refeds.org ) .  The website is currently hosted by TERENA, but is currently complex to update by more than a couple of people close to the development of the site.  REFEDS also wishes to create a blog, which would be difficult within the current site format.  It has been suggested that moving the site to a Wordpress installation may resolve these issues, but the TERENA technical staff would need to be consulted closely on this. 

 

  1. Wiki (refeds.terena.org) .  The wiki is typically used to support the REFEDS working group and has been developed to a good level of production.  The wiki is currently hosted by TERENA and provides federated access.  It is clear that the federation data held on the wiki needs updating / maintenance; this is being considered by the proposed Metadata Explorer Tool.

 

  1. Mailing lists .  TERENA currently hosts list for REFEDS, but in 2 different formats: refeds@terena.org , attribute-release@refeds.org .  The PEER mailing list is hosted elsewhere and should be moved to TERENA hosting.  

 

  1. General white papers and releases . These can typically be managed as part of the website with little additional requirement.

 

  1. Subdomains for projects. This may include papers / html but also hosted services.

 

  1. Service instances . At the moment PEER and the proposed Metadata Explorer Tool will need a long-term home.  REFEDS has also been considered as a long-term home for eduGain.

 

  1. Software hosting . As well as support for service instances, REFEDS should have a clear policy on where open-source software produced under its umbrella should be hosted and maintained (github, in-house, other?).

 

  1. Standards hosting .  REFEDS has been asked to become the home for the saml2intprofile.