release management

Release Managemente in Free Software ProjectsMaster on Free Software

Juanjo Amor, Gregorio Robles, Jesus M. Gonzalez-Barahona

{jjamor,grex,jgb}@gsyc.escet.urjc.esGSyC/Libresoft

2-3 November 2007

Juanjo Amor, Gregorio Robles, Jesus M. Gonzalez-Barahona Release Managemente in Free Software Projects

(cc) 2007 Juanjo Amor, Gregorio Robles, Jesus M. Gonzalez-Barahona

Some rights reserved. This work licensed under Creative Commons Attribution-ShareAlike License. To view a copy

of full license, see http://creativecommons.org/licenses/by-sa/2.0/ or write to Creative Commons, 559 Nathan

Abbott Way, Stanford, California 94305, USA.


Legal aspects

Usually, we already have a (maybe small) program

Select a license (taking into account the software to bereused), including documentation

Decide who has the copyright (authors, institution, etc.)

Include the license and copyright information in all sourcecode files

Distribute at least a single copy (the process starts)

Follow the license “as if the software does not have copyright”


Good practices when releasing (I)

Put the software in a place where it can be downloaded(including the sources)

Announce the software (Freshmeat and other specific sites)

Simplify the compilation and installation process (maybeincluding packaging)

Documenting the distribution


Good practices when releasing (and II)

Clean the code (including translation into English)

Prepare software so that it can be easily translated into otherlanguages

Open feedback channels (lists, bug reports, comments inphorums)

Build an insfrastructe that makes collaboration not onlypossible, but also easy

Manage contributions, patches, modifications and suggestions


The reference site

What do we want?

Visibility (so that people know that the project exists)

User base (that people use the software)

Occasional collaborators (make help by users possible)

Co-developers (make possible that others get involved)

Promote and support a business model

Depending on our goals, the required infrastructure will be different


Working out a good image

First impression: the web

Second impression: the installation

Third impression: the demos

Only then we will really evaluate the product

It is not a bad idea to have related material: articles, usagevideos, etc.

It is important that all the impressions are good


Work on a day to day basis

If we want to keep on being the “reference site”:

Users have to be motivated to use the resources put for them

Updated information

Information about related tools

Documentation, documentation, documentation

That users may express themselves easily; and that theyreceive convenient feedback


The web site

Presentation of the project

Project download pages (binaries and sources)

Page for news

Documentation (on-line and downloadable)

Usage examples, tricks, etc.

Space for contributions (bug reports, patches, etc.)

Related tools

Support information


Useful tools

Software repository (ftp, http)

CVS / Subversion, CVS-Web, Bonsai: if we want to make thelatest of the latest available

Gnats, BugZilla: report management (bugs, requests, etc.)

Phorum (Postnuke, Drupla): helps creating a community

Developer blogs

Mailman: mailing lists, with the archives (very important)

SourceForge, Savannah, BerliOS: all this together (GForge:free software forge)


The Software

Packaging:

tar.gz

Debian package

RPM package

Sources

Goal: as easy as possible to install


Distributing the binary

License (COPYING)

General Info (README). Very important: cite web site anddocumentation

Installation information (INSTALL)

Documentation (maybe in an extra package)

Binary for a specific platform (in doubt, static)

Packages with their version clearly marked


Marketing

Congresses, etc.

Related web sites (especially news sites)

News groups

Mailing lists

Important: generate news every once, but avoid spamming!Very important: Be ready when the announcements are made


Human resources

In addition to development, we need

Infrastructure management (100 / 20)

Development coordinator, including QA (40-200 / 20)

Attention to the bug tracking system (?? / 10-15)

Maintaining documentation and on-line information (60 / 10)

Public relations (?? / 20)

A project with mean complexity (hours at the beginning / hoursper week)Sources: “Open Source as a Business Strategy”, Brian Behlendorf


Conclusions

It is very important to attract users to our site (“marketingcampaign”)

It is very important to keep the users “with us” (competitiveadvantage)

The main goal is to create a community

We have to make life easy to our users

Very important: automatize everything that can be madeautomatically

Of course, all this depends on the goals...


References

“Open Source as a Bussiness Strategy”, por Brian Behlendorf(en Open Sources, Voices from the Open Source Revolution)http://www.oreilly.com/catalog/opensources

“Whether and How To Publish Software Under an OpenSource License”, por Sebastien Blondeelhttp://publish.idealx.org/


release management

Technology