Differences between revisions 22 and 30 (spanning 8 versions)
Revision 22 as of 2007-06-18 14:00:34
Size: 4755
Editor: RossGardler
Comment: Add a link to UsingSVN page
Revision 30 as of 2013-04-15 13:56:17
Size: 6184
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
[[TableOfContents(2)]] <<TableOfContents(2)>>
Line 6: Line 6:
= Support = = Project Creation =

''"By giving off this aura of preparedness, the project sends out a message: "Your time will not be wasted if you get involved," which is exactly what people need to hear."'' (Producing Open Source. Chapter 2)

Open source is often sustained by sharing the costs of development across a number of collaborating partners. As a project gets larger it is often desirable to attract new partners. There are usually three important steps in attracting a new partner:

 1. attract interested parties
 1. show them the project outputs are useful
 1. encourage active participation

All three of there steps are carried out wing online resources. The following sections describe the key tools at your disposal.
Line 10: Line 20:
Documentation is key to the success of your project. If your users can't use the software then they will simply leave. If your potential developers do not know how to contribute they simply won't bother. Documentation is key to the success of your project. If people cant understand what your project aims to achieve they will take no interest. If potential users can't get to grip with the software then they will simply leave. If your potential developers do not know how to contribute they won't bother.

In the online world documentation is delivered through your website. We recommend that you use a website management look that allows you to repackage your documentation in multiple ways. For example, you will need an online version, a printed version and a version to bundle with your releases.

You will need four main sections within your documentation:
Line 19: Line 33:
 * [http://www.symphonious.net/2007/02/06/creating-great-documentation/ Creating great documentation]
 * [http://norman.walsh.name/2007/02/05/painting Topic oriented authoring]
 * [http://www.wikipatterns.com/display/wikipatterns/Wikipatterns Wiki patterns]
 * [http://www.onlamp.com/pub/a/onlamp/2007/06/14/why-do-people-write-free-documentation-results-of-a-survey.html Why Do People Write Free Documentation? Results of a Survey]
 * [[http://www.symphonious.net/2007/02/06/creating-great-documentation/|Creating great documentation]]
 * [[http://norman.walsh.name/2007/02/05/painting|Topic oriented authoring]]
 * [[http://www.wikipatterns.com/display/wikipatterns/Wikipatterns|Wiki patterns]]
 * [[http://www.onlamp.com/pub/a/onlamp/2007/06/14/why-do-people-write-free-documentation-results-of-a-survey.html|Why Do People Write Free Documentation? Results of a Survey]]
Line 30: Line 44:
UsingSVN - Subversion is a very common version control system that allows multiple people to work simultaneously on the same documents and code. UsingSubversion - Subversion is a very common version control system that allows multiple people to work simultaneously on the same documents and code.
Line 36: Line 50:
["SVN Commit Messages"] - SVN can send out emails on every commit, great for peer review and keeping up to date [[SVN_Commit_Messages]] - SVN can send out emails on every commit, great for peer review and keeping up to date
Line 44: Line 58:
[[http://ant.apache.org|Apache Ant]]
[[http://maven.apache.org|Apaceh Maven]]
Line 50: Line 67:
= Testing = Using an issue tracker is essential for a project to keep track of any feature requests and bugs that have been found. It does not only record these issues and help you tracing what happens with them, but it can also assist in planning releases and deciding which features and/or fixes will be in which release. Most major hosting websites offer an issue tracker, such as [[http://www.googlecode.com|Google Code]] or [[http://www.sf.net|SourceForge]], which offers the open source bug tracking system Trac.

= Quality Control =
Line 58: Line 77:
[http://tapestryjava.blogspot.com/2007/05/free-and-excellent-code-coverage-for.html EMMA] code coverage plugin for Eclipse [[http://tapestryjava.blogspot.com/2007/05/free-and-excellent-code-coverage-for.html|EMMA]] code coverage plugin for Eclipse

== Coninuous Integration ==

[[https://hudson.dev.java.net/|Hudson]] an extensible continuous integration engine
Line 62: Line 85:
An important part of open source development is the creation of a release for users of the software. Whilst the source code is freely available and usually developed in an open manner, potential developers and users will usually want to be able to evaluate the code quickly and easily. Therefore, projects should frequently release their software in a form that is easily accessible. Open source development is all about attracting users and developers. It is therefore important to release the software early, and as frequently as possible. Many people have difficulty with this concept, asking questions like "won't users be put off by the bugs?" Well, no, that is the point of open source, we are honest about our bugs and, if it really bothers you, you can fix it yourself (or pay someone to fix it).
Line 64: Line 87:
"Release early, release often" is a well known mantra of open source development. There are many reasons why it is important to release early and release often. Some of the more important ones are: Bugs exist in all software, not just open source. As long as you don't claim the software is more complete than it really is users will be happy to work around its limitations, safe in the knowledge that it is temporary.
Line 66: Line 89:
 * Early and frequent feedback from users
 * easy access to the latest and greatest features
 * Builds developer confidence
 * Shows genuine project activity
 * Manageable upgrade path for users

Release Early, Release Often is part of building a sustainable open source project, releases produce users, users sometimes become contributors, contributors make the project stronger. The downside of releasing early and often is that you need to manage your user expectations. Be clear about the true status of your release and make any known bugs clear in your documentation.
More on ReleaseEarlyReleaseOften.
Line 76: Line 93:
["Release Management"] [[Release_Management]]
Line 78: Line 95:
[wiki:Self:ReleasingOpenSourceSoftware Releasing Open Source Software] [[ReleasingOpenSourceSoftware|Releasing Open Source Software]]
Line 80: Line 97:
[http://en.wikipedia.org/wiki/Release_Management_method Wikipedia on Release Management Method] [[http://en.wikipedia.org/wiki/Release_Management_method|Wikipedia on Release Management Method]]
Line 82: Line 99:
[http://www.ics.uci.edu/~wscacchi/Papers/Open-Source-Research/OSSE3-Erenkrantz.pdf Release Management Within Open Source Projects by Justin R. Erenkrantz] [[http://www.ics.uci.edu/~wscacchi/Papers/Open-Source-Research/OSSE3-Erenkrantz.pdf|Release Management Within Open Source Projects by Justin R. Erenkrantz]]
Line 84: Line 101:
[http://www.tldp.org/HOWTO/Software-Release-Practice-HOWTO/ Software Release Practice HOWTO by Eric Steven Raymond] [[http://www.tldp.org/HOWTO/Software-Release-Practice-HOWTO/|Software Release Practice HOWTO by Eric Steven Raymond]]
Line 96: Line 113:
OpenSourceDevelopmentInAction - a few examples of how doing it right saves time and effort later OpenAndAgileDevelopment - notes on what an open and agile development process would look like

There is more to open source than a licence. It is also a development methodology. This page links to various resources about different aspects of open source development.

Project Creation

"By giving off this aura of preparedness, the project sends out a message: "Your time will not be wasted if you get involved," which is exactly what people need to hear." (Producing Open Source. Chapter 2)

Open source is often sustained by sharing the costs of development across a number of collaborating partners. As a project gets larger it is often desirable to attract new partners. There are usually three important steps in attracting a new partner:

  1. attract interested parties
  2. show them the project outputs are useful
  3. encourage active participation

All three of there steps are carried out wing online resources. The following sections describe the key tools at your disposal.

Documentation

Documentation is key to the success of your project. If people cant understand what your project aims to achieve they will take no interest. If potential users can't get to grip with the software then they will simply leave. If your potential developers do not know how to contribute they won't bother.

In the online world documentation is delivered through your website. We recommend that you use a website management look that allows you to repackage your documentation in multiple ways. For example, you will need an online version, a printed version and a version to bundle with your releases.

You will need four main sections within your documentation:

Mailing Lists

Code Development

Version Control

UsingSubversion - Subversion is a very common version control system that allows multiple people to work simultaneously on the same documents and code.

SoftwarePatch - Working with patches

Team Communications

SVN_Commit_Messages - SVN can send out emails on every commit, great for peer review and keeping up to date

IPR Management

ContributorLicenceAgreements - a contributor licence agreement helps ensure that all contributions to the project can legally be included

Build Automation

Apache Ant Apaceh Maven

Dependency Management

ApacheIvy

Issue/Bug/Patch Tracking

Using an issue tracker is essential for a project to keep track of any feature requests and bugs that have been found. It does not only record these issues and help you tracing what happens with them, but it can also assist in planning releases and deciding which features and/or fixes will be in which release. Most major hosting websites offer an issue tracker, such as Google Code or SourceForge, which offers the open source bug tracking system Trac.

Quality Control

Quality is key. This does not mean shipping without bugs, that is close to impossible, what it does mean is shipping with no known bugs (actually shipping early releases with known. but manageable bugs can be ok too). Testing is the way to ensure you are shipping (near) bug free code. Testing falls into two camps, user testing and automated testing. Both have their strengths and weaknesses.

User Testing

Automated Testing

EMMA code coverage plugin for Eclipse

Coninuous Integration

Hudson an extensible continuous integration engine

Release Early, Release Often

Open source development is all about attracting users and developers. It is therefore important to release the software early, and as frequently as possible. Many people have difficulty with this concept, asking questions like "won't users be put off by the bugs?" Well, no, that is the point of open source, we are honest about our bugs and, if it really bothers you, you can fix it yourself (or pay someone to fix it).

Bugs exist in all software, not just open source. As long as you don't claim the software is more complete than it really is users will be happy to work around its limitations, safe in the knowledge that it is temporary.

More on ReleaseEarlyReleaseOften.

Release Management

Release_Management

Releasing Open Source Software

Wikipedia on Release Management Method

Release Management Within Open Source Projects by Justin R. Erenkrantz

Software Release Practice HOWTO by Eric Steven Raymond

Release Packaging

You should make the installation of your software as easy as possible, ideally users should be able to download and install from a binary, whilst developers should have a clear document describing how to configure their environment.

Installers

IzPack - an installer generator for the Java platform.

Related Documents

OpenAndAgileDevelopment - notes on what an open and agile development process would look like

OSSWatchWiki: OpenSourceDevelopment (last edited 2013-04-15 13:56:17 by localhost)

Creative Commons License
The content of this wiki is licensed under the Creative Commons Attribution-ShareAlike 2.0 England & Wales Licence.

OSS Watch is funded by the Joint Information Systems Committee (JISC) and is situated within the Research Technologies Service (RTS) of the University of Oxford.