EditAttachPrintable
r3 - 08 Feb 2005 - 08:48:03 - TonyLindeYou are here: TWiki >  Main Web  >  TonyLinde > TonySupportProposal
This is a proposal for how it might be possible to organise ongoing support for the AstroGrid software without the overhead and inevitable inertia of a permanent organisation. When complete it will be submitted to AGLI for consideration.

AstroGrid Software Foundation (AGSF)

Draft Only

Contents:

Introduction

AstroGrid (AG) is a project whose prime goal is to develop and deploy software which will deliver a working Virtual Observatory (VObs) to UK astronomers. For an introduction to the VObs vision and the AstroGrid project, see:

The AstroGrid project was initiated in September 2001 with PPARC e-Science grants and was due to complete in December 2004; it has since been extended another three years to December 2007. Regardless of this extension and any others that might eventuate, the project will finish and the people employed on it move to other jobs. What then will happen to the software? This paper proposes an approach to continuing the support and development of the AstroGrid software.

Executive Summary

Preliminary Argument

What are the usual solutions to providing ongoing support and maintenance of software developed under academic grants? It seems to me there are three common solutions:
  1. forget it
    • the software authors move on to completely different things;
    • the tools are placed on a server somewhere and persist until the server is retired
    • no changes are ever made to the tools and so soon are out of date and unused
  2. author maintained
    • the author(s) are keen to keep the tools in use so make them available
    • minor updates are made by the authors in their own time
    • major updates are only done if the author is employed on a project which wants that update
  3. organisation maintained
    • the software is put under the control of (or may have been developed by) a software department like StarLink? (5)
    • the department determines the need for updates (usually based on some feedback from the user community) and undertakes them
    • the department makes the tools available on its web sites

The problems with the first two are obvious: the software does not get maintained or not on a regular basis: AstroGrid software is too large and complex to be maintained on such an ad hoc basis anyway. The problems with the third and the reasons I would not like to see AstroGrid software follow this approach are discussed below.

Organisational problems

The problem with the organisation maintained solution are less obvious but more damaging to the cause of academic software.

The first is to do with any IT support department (and I've worked in and managed a good many). Any such department will have as its prime stated goal the support and maintenance of software. But the real goal is to get bigger. Departments are managed by people and people measure their status by how many staff they have and how big their budget is: whatever the organisational goals may state and whatever metrics are imposed on them.

The second is the problem of ownership. Such a department will not willingly retire one of its own products if a better one is produced by another group. They will, instead, come up with justifications for why their product must be maintained and why more money is needed to make it better than the other group's product.

A third is that the department is simply the wrong group to determine its own priorities. And whatever surveys it undertakes to determine user priorities, it will always interpret those priorities as requiring more staff and a higher budget.

End result

I could probably cite more problems but the end result is always a moribund and bloated organisation whose priorities are not those of the community it serves and a suite of software products that are feature-rich but usefulness-poor which the community feels obliged to use because so much of its money is spent on them.

This is a harsh judgment and is not meant to single out Starlink but is common to any IT department that has existed for some time and is in any way 'protected' from the normal market forces (ie, in commerce, is not a profit centre and in academia, does not compete in the project-based grant process).

Proposed solution for AstroGrid

My proposed solution for the support and maintenance of AstroGrid software is to create an open sourced based support mechanism which has no fixed institutional component, no permanent members and no directly funded staff. So how can this work? Before setting out this approach, let me first outline two of the models on which it is based.

Models

This idea is based on a couple of tried, tested and trusted models:
  • the Apache Software Foundation (3), and
  • the Eclipse Foundation (4).

Apache Software Foundation

from the site:
The Apache Software Foundation exists to provide organizational, legal, and financial support for the Apache open-source software projects. Formerly known as the Apache Group, the Foundation has been incorporated as a membership-based, not-for-profit corporation in order to ensure that the Apache projects continue to exist beyond the participation of individual volunteers, to enable contributions of intellectual property and funds on a sound basis, and to provide a vehicle for limiting legal exposure while participating in open-source software projects.

The Apache Software Foundation is a membership-based, non-profit corporation. Individuals who have demonstrated a commitment to collaborative open-source software development, through sustained participation and contributions within the Foundation's projects, are eligible for membership in the ASF. An individual is awarded membership after nomination and approval by a majority of the existing ASF members. Thus, the ASF is governed by the community it most directly serves -- the people collaborating within its projects.

The ASF members periodically elect a Board of Directors to manage the organizational affairs of the Foundation, as accorded by the ASF Bylaws. The Board, in turn, appoints a number of officers to oversee the day-to-day operations of the Foundation. A number of public records of our operation are made available to the community.

...

The Foundation is a collaborative project of the ASF. Our goal is to build and sustain the literal foundation upon which our open-source software projects are based. Like the other projects, we will need help to achieve this goal, and several groups have already contributed their time and effort to good effect. However, it is often difficult to find volunteers to perform the essential grunge work behind the scenes. We are in the process of putting together a support organization, using funds contributed by the Apache community, that will provide the administrative assistance needed to keep the projects moving at full steam.

The ASF is organised into projects:

HTTP Server Commonly known as Apache httpd
Ant Java-based build tool
APR The Apache Portable Runtime
Avalon Framework and components for Java applications
Cocoon XML publishing framework
Commons Reusable libraries and components
DB Database access
Incubator Shepherd for new projects
Jakarta Server-side Java
James Java Apache Mail Enterprise Server
Maven Java Project Management and Comprehension Tools
Perl Dynamic websites using Perl
PHP Server-side, HTML embedded scripting language
TCL Dynamic websites using TCL
Web Services Web Services
XML XML solutions focused on the web
Conferences Meetings of developers and users
Foundation Administration and infrastructure management

Eclipse Foundation

from the site:
Eclipse is an open platform for tool integration built by an open community of tool providers. Operating under a open source paradigm, with a common public license that provides royalty free source code and world wide redistribution rights, the eclipse platform provides tool developers with ultimate flexibility and control over their software technology.

Eclipse has formed an independent open eco-system around royalty-free technology and a universal platform for tools integration. Eclipse based tools give developers freedom of choice in a multi-language, multi-platform, multi-vendor environment. Eclipse provides a plug-in based framework that makes it easier to create, integrate and utilize software tools, saving time and money. By collaborating and exploiting core integration technology, tool producers can leverage platform reuse and concentrate on core competencies to create new development technology. The Eclipse Platform is written in the Java language and comes with extensive plug-in construction toolkits and examples. It has already been deployed on a range of development workstations including Linux, QNX, OSx and Windows based systems. A full description of the Eclipse community and white papers documenting the design and use of the Eclipse Platform are available at http://www.eclipse.org.

The Eclipse Foundation is a non-profit corporation formed to advance the creation, evolution, promotion, and support of the Eclipse Platform and to cultivate both an open source community and an ecosystem of complementary products, capabilities, and services.

You can learn more about the structure and mission of the Eclipse Foundation by reading the formal documents that establish how the foundation operates, and by reading the press release announcing the creation of the independent organization.

from the press release:

The Eclipse Board of Stewards today announced Eclipse’s reorganization into a not-for-profit corporation. Originally a consortium that formed when IBM released the Eclipse Platform into Open Source, Eclipse is now an independent body that will drive the platform’s evolution to benefit the providers of software development offerings and end-users. All technology and source code provided to this fast-growing ecosystem will remain openly available and royalty-free.

With this change, a full-time Eclipse management organization is being established to engage with commercial developers and consumers, academic and research institutions, standards bodies, tool interoperability groups and individual developers, plus coordinate Open Source projects. To maintain a reliable and accessible development roadmap, a set of councils–Requirements, Architecture and Planning–will guide the development done by Eclipse Open Source projects. With the support of over 50 member companies, Eclipse already hosts 4 major Open Source projects that include 19 subprojects.

To oversee and staff this new management organization, Eclipse has established a Board of Directors drawn from four classes of membership: Strategic Developers, Strategic Consumers, Add-in Providers and Open Source project leaders. Strategic

Developers and Strategic Consumers hold seats on this Board, as do representatives elected by Add-in Providers and Open Source project leaders. Strategic Developers, Strategic Consumers and Add-in Providers contribute annual dues. The founding Strategic Developers and Strategic Consumers are Ericsson, HP, IBM, Intel, MontaVista Software, QNX, SAP and Serena Software.

And the projects (which encompass 19 subprojects):

The Eclipse Project - The Eclipse Project is an open source software development project dedicated to providing a robust, full-featured, commercial-quality, industry platform for the development of highly integrated tools. The mission of the Eclipse Project is to adapt and evolve the eclipse technology to meet the needs of the eclipse tool building community and its users, so that the vision of eclipse as an industry platform is realized.

The Eclipse Tools Project - The project provides a focal point for diverse tool builders to ensure the creation of best of breed tools for the Eclipse Platform. The mission of Eclipse Tools Project is to foster the creation of a wide variety of tools for the Eclipse Platform. The Tools project provides single point of coordination for open source tool developers in order to minimize overlap and duplication, ensure maximum sharing and creation of common components, and promote seamless interoperability between diverse types of tools. The Eclipse Tools Project will use its experience in developing tools for eclipse as a source of technical input and feedback for the Eclipse Project.

The Eclipse Technology Project - The mission of the Eclipse Technology Project is to provide new channels for open source developers, researchers, academics and educators to participate in the on-going evolution of Eclipse. It is organized as three related project streams, namely Research, Incubators and Education. Research projects explore research issues in Eclipse-relevant domains such as programming languages, tools, and development environments. Incubators are small, informally structured projects which add new capabilities to the Eclipse software base. Education projects focus on the development of educational materials, teaching aids and courseware.

AstroGrid Software Foundation

Counter Arguments

Conclusion

References

(1) AstroGrid Vision: http://wiki.astrogrid.org/bin/view/Agdoc/ArchVision

(2) AstroGrid Overview: http://wiki.astrogrid.org/bin/view/Agdoc/ArchOverview

(3) The main Apache site is at http://www.apache.org and details of the Apache Software Foundation at http://www.apache.org/foundation/

(4) The main Eclipse site is at http://www.eclipse.org and details of the Eclipse Foundation at http://www.eclipse.org/org/index.html

(5) Starlink home page is at http://www.starlink.rl.ac.uk/

()

()

()

()

()

()

()

()

()

()

()

()

()

()

()

()

()

()

()

()

()

()

()

-- TonyLinde - 09 Mar 2004

Edit | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r3 < r2 < r1 | More topic actions
 
AstroGrid Service Click here for the
AstroGrid Service Web		 This is the AstroGrid
Development Wiki
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback