Differences between revisions 1 and 23 (spanning 22 versions)
Revision 1 as of 2007-04-27 21:57:56
Size: 1028
Editor: RossGardler
Comment: Initial page template nand minimal content
Revision 23 as of 2007-06-18 14:01:13
Size: 4762
Editor: RossGardler
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
||<#00FF00> Like all pages in this wiki you are welcome (and encouraged) to contribute to this page by filling in the many gaps, either by providing links to other resources or by providing discussion content. ||

= Open Source Development =
Line 8: Line 4:
[[TableOfContents([3])]] [[TableOfContents(2)]]
Line 10: Line 6:
== Support == = Support =
Line 12: Line 8:
=== Documentation === == Documentation ==
Line 14: Line 10:
=== Mailing Lists === 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.
Line 16: Line 12:
== Build Automation ==  * 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
Line 18: Line 17:
=== Dependency Management === === External Links ===
Line 20: Line 19:
== Issue/Bug Tracking ==  * [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 22: Line 24:
== Testing == == 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 =

== Dependency Management ==

ApacheIvy

= Issue/Bug/Patch Tracking =

= Testing =

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 ==

[http://tapestryjava.blogspot.com/2007/05/free-and-excellent-code-coverage-for.html EMMA] code coverage plugin for Eclipse

= Release Early, Release Often =

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.

"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:

 * 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.
Line 25: Line 75:

["Release Management"]

[wiki:Self:ReleasingOpenSourceSoftware Releasing Open Source Software]
Line 31: Line 85:

== 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 =

OpenSourceDevelopmentInAction - a few examples of how doing it right saves time and effort later

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.

TableOfContents(2)

Support

Documentation

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.

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

Dependency Management

ApacheIvy

Issue/Bug/Patch Tracking

Testing

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

[http://tapestryjava.blogspot.com/2007/05/free-and-excellent-code-coverage-for.html EMMA] code coverage plugin for Eclipse

Release Early, Release Often

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.

"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:

  • 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.

Release Management

["Release Management"]

[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]

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

OpenSourceDevelopmentInAction - a few examples of how doing it right saves time and effort later

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.