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.

Drizzle: Seeking tiny contributions, leading to big things

The Drizzle project regularly gets people asking what they can do to get involved in the project.

One very easy way to brush up on your C++ skills and dip your toe into our open development process is to fix minor warnings.

We are very proud that Drizzle builds with zero warnings for with "gcc -Wall -Wextra".

But we can be even better!  Our JenkinsCI system has a target that is even more picky, and also a target that runs cppcheck.

Go to one of those pages, pick a build log off the build history, find a warning that you think you can fix, and then ask us in the #drizzle channel on Freenode how to send your fix to us.

After you've done that a few times, you'll be ready to fix some low hanging fruit.

We've had people graduate from this process into becoming a Google Summer of Code student, and eventually having a full time paying job hacking on Drizzle and other open source software.

And it all starts with writing a simple warning fix.