"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

Sponsorship Checklist

Contents

Related pages



Sponsorship Checklist

There are a number of tasks and roles that need to be addressed in order to ensure a successful open source project. These are described below:

  • Community Support
    A person or team is required to answer user and developer questions, review submitted code from external developers to ensure quality control and ensure that all submissions meet the project requirements in terms of test coverage and documentation. This is one of the most effective investments in a project.
  • General Project Processes
    All projects should invest in tools and processes such as automated build systems, issue trackers, concurrent versioning systems as well as ensuring that releases are performed smoothly and regularly.
  • Documentation
    Good, current design and implementation documentation lowers the learning curve for developers supporting and extending software and greatly increases productivity. Good user documentation engenders confidence in project reviewers which in turn will lead to greater adoption.
  • Marketing
    While Open Source benefits significantly from community generated promotion, it is enhanced by prudent investment in web pages and presentations for targeted conferences.
  • Commercial Support
    One of the main reasons given for avoiding Open Source is not being able to call someone to fix problems. Offering commercial support for a project you use will go far in encouraging adoption by other organizations.
  • Integrate and bundle with related software
    Microsoft Office has been especially successful because it integrates a suite of related products and bundles them all together in one easy install. Open Source products improve their attractiveness in the same way.
  • Open Standards
    Due to the release-early/release-often approach of most open source projects, they are often leveraged to develop, test and extend open standards. This makes open source projects among the earliest adopters of emerging standards, encourages the uptake of open standards and makes the projects attractive to those interested in sharing data between agencies.
  • Project Management
    Just like proprietary software, a sponsor’s software development should be managed using standard software development processes . This includes estimation; planning resources, work activities, schedules, budgets, deliverables; monitoring schedule, quality, risk, issues, contractors, configuration management.
  • Measurement
    Measurement is a key tool used during proprietary Project Management, as good metrics enable good management decisions. Good measures highlight whether specific business goals are being met and enable management to alter their strategy early if issues arise.

Metrics are under-utilized in many open source projects as developers usually drive their own agendas, are self motivated, and spend less time on Project Management. However metrics based decision making can be equally effective for Open Source projects especially for sponsors who will need to answer to commercial milestones and targets.

Standard software development metrics should be complemented by measures to monitor the health of an Open Source community. The Community MapBuilder project tracks many of these metrics and can be viewed at the URL provided below. There are now a number of dedicated tools which automate many of the common software metrics. http://communitymapbuilder.org/display/MAP/Strategic+Direction#StrategicDirection-Metrics. Typical measures are discussed in the following sections.

Project Management Measures

Earned Value Management

Earned Value Management (EVM ) provides an effective way to track progress over time and make adjustments to scope, schedule or resources as required. When employed EVM measures the planned value of the project as estimated in the original schedule, the earned value calculated from the percentage completion of all tasks at a given time, and the actual cost of the project at a given time as derived from time logs.

Milestones

Milestones provide an easy means of determining whether deliverables are on time or not. By decomposing a project into a number of smaller milestones, stakeholders can monitor these deliverables to determine if the schedule is likely to be met and adjust their planning accordingly, before the expected completion of the project.

Software Development (Indicative)

Features Implemented

By using an issue tracking system, such as Trac or JIRA, to record, track and report on the progress of feature and improvements, management is able to determine the progress of the project at a finer resolution than would be provided through milestones alone. This process also assists in the planning and prioritisation of features and encourages a flexible and agile development methodology.

Repository Commits

The frequency of commits to the projects source code repository is a strong indicator of the activity experienced by the community. While a high level of activity could indicate anything from a pending code freeze prior to release, to the discovery of a large and pervasive security vulnerability, it does show that the community is responsive and the project is undergoing active development. Commits to documentation repositories, or changes to the project wiki, provide similar indications of community activity.

Quality Measures

Bug Reports

Contrary to intuition, a large number of bug reports usually indicates a healthy project. It is an indication that the community is actively identifying bugs and endeavouring to fix them. Many issue tracking applications allow the reporting of bugs reported and fixed over time, or relating to specific releases. Many bugs indicates a strong user community that is testing and reporting issues or feature requests to the project.

Test Coverage

Many projects have a minimum requirement for the percentage of source code covered by automated tests that must be met before a new feature may be added to the project. The test coverage of a project or a specific module of the project is a strong indicator of the quality and stability of the source code. Projects with minimum requirements are indicating to the community that code quality and stability are more important that a long list of features that may or may not be stable.

Code Reviews

Code reviews are audits of newly written or modified source code performed by a developer or developers other than those that are responsible for the code. The presence and availability of code reviews is indicative of a commitment of the project community to following good development processes. This is another indicator of the quality of the project.

Community Measures

Communication

The activity of the project email lists, IRC channels, forums and other public means of communication is the best indication of the health of the community. In order to promote the use of the project, this activity should be balanced between discussions on the direction of the project, questions from new users or developers and in particular answers from knowledgeable members of the community.

Downloads

The number of downloads of binary releases, developer kits or source code provides an indication of the size of the user community. A large user community provides a large pool of people that may be interested in sponsoring additional development on the project, thus sharing the costs of the project.

Web Metrics

Indicators such as web page hits and related blog entries provide a means of estimating the interest in the project. While downloads provide a good indicator of the current size of the community, these web metrics are more of an indicator of growing interest and awareness in the project, and provide a means of forecasting medium-term growth in the project.

Number of Sponsors

The number of sponsors is a strong indicator of the size of the sponsored community. While this may sound obvious, open source projects suffer in this regard, since many sponsors will not advertise themselves as such. Instead they simply offer code patches, or hire existing developers within the community without informing the community at large. Unlike proprietary software projects, there is no centralized authority to track the number of licenses or authorised vendors/developers associated with the project, so the advertised number of sponsors will generally be a subset of the actual sponsors.

prev up next

 
Topic revision: r3 - 15 Oct 2010, UnknownUser
 

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).