Best practice for "releasing" Open Source Software.

Many projects practice "open source" via the "release the source" technique.  Sometimes, in the process of being underwhelming, what is "released" is a bare tarball that lacks build instructions, and metadata such as change history, internal documentation, and bug and feature commentary.

This is not a "best practice".


A slightly nicer way to do it is to maintain a read-only repository, such as a public SVN or GIT server, and on occasion write out an approved and sanitized version of the software for the great unwashed to pull down.

This looks nicer than just bare tarball drops, but actually isn't any better.


The next step is "public development".  This turns software development into a public performance.  It turns out that the proverb "Sunlight makes the best disinfectant" is true for software quality as well as for politics.  Such projects keep their real operational version control system world readable, and keep their bug tracker and development mailing lists and documentation fully public.  Sites like GitHub and Launchpad make it trivial to do this.

There are some costs a project has to pay to make this work.  They have to make sure that "tip always passes", e.g. that they have a good enough test suite, continuous integration system, and merge processes.  But, consider: any project, open source or closed, that doesn't have these things is unlikely to be generating high quality work at all.


The next step after "public development" is open development.  Such projects accept participation and contribution from "outsiders". When fully expressed, there is no such thing as an "outsider", everyone is a contributor.