Add open and agile development link
Some changes for RT ticket 1621342
|Deletions are marked like this.||Additions are marked like this.|
|Line 67:||Line 67:|
|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.
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.
"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:
- attract interested parties
- show them the project outputs are useful
- 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 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:
MarketingDocumentation consists of materials intended to attract potential users
UserDocumentation consists of materials aimed at guiding users through common tasks.
GovernanceDocumentation contains materials aimed at showing users and developers how to contribute to the project
DeveloperDocumentation consists of materials aimed at helping people improve the software and its documentation
[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]
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
["SVN Commit Messages"] - SVN can send out emails on every commit, great for peer review and keeping up to date
ContributorLicenceAgreements - a contributor licence agreement helps ensure that all contributions to the project can legally be included
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 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.
[http://tapestryjava.blogspot.com/2007/05/free-and-excellent-code-coverage-for.html EMMA] code coverage plugin for Eclipse
[https://hudson.dev.java.net/ 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.
[wiki:ReleasingOpenSourceSoftware Releasing Open Source Software]
[http://en.wikipedia.org/wiki/Release_Management_method Wikipedia on Release Management Method]
[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.tldp.org/HOWTO/Software-Release-Practice-HOWTO/ Software Release Practice HOWTO by Eric Steven Raymond]
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.
IzPack - an installer generator for the Java platform.
OpenAndAgileDevelopment - notes on what an open and agile development process would look like