Recently, Citrix announced that it will donate CloudStack to the Apache Software Foundation (ASF).  This is a very exciting moment in the history of the CloudStack project.  The ASF is the premier open source foundation in the world and it has a track record of successful, completely open projects.  The CloudStack project has been increasingly open during its life.  But, “increasingly open” isn’t good enough.  We have to be 100% open in our technical discussions to run the project in the meritocratic fashion that successful Apache projects use.  In this blog post I’ll do a brief review of CloudStack openness and list out the changes we’ll be making over the next few months to transform CloudStack from a largely single-entity development effort to a collaborative, community project.

CloudStack 1.0 was proprietary software.  Closed specs, closed discussion, closed bug database, closed source.  The CloudStack 2.0 release in May, 2010 transitioned CloudStack to an open-core model.  About 95% of the source was available under GPLv3 and the bug database was open, but the technical discussions were closed and few technical documents were publicly available.  In August, 2011 Citrix published 100% of the CloudStack source code.  We started publishing some technical specs, but the discussions were still closed.

In late 2011, in conjunction with the Acton release, we started doing a better job publishing technical specs.   Not perfect – we weren’t iterating the designs in the open – but good progress.  We also (finally) came up with a process for accepting contributions.  In 2012 we’ve created a publicly available project dashboard , started publishing meeting minutes, and getting a larger number of non-Citrix contributions.

That’s good stuff, but there are some fundamental changes needed to make it more open.  Instead of publishing designs and discussion results after the fact, we have to publish the earliest version and then iterate in the open.  We also have to have the technical discussions on the cloudstack-dev mailing list (see below for the new one), and not on our internal engineering list.  This will take policing -- and I’m part of the problem here -- but through force of will a few folks can make a big difference here.

We also need to ask more of the community.  Our bug database is open, but, there’s no place to go with an “ask-list”.  Nowhere can you easily see important features with no owner, nor can you easily search to find the bugs with the most votes.  We need to pick a few features with a variety of technical needs and ask the community to help out.  That part is easy, BTW.  CloudStack has so many potential integrations in the datacenter that just listing those would give years of work to interested parties!

The above is good process in any open project.  For an ASF project, we’ll also have to operate as a meritocracy that makes decisions on code changes in an unanimous fashion.  We’ll have to distinguish between PMC members, committers, and those just starting with CloudStack development.  We’ll have to adopt guidelines for when a committer should be considered for the PMC.

Last week CloudStack was voted into the Apache Incubator.  Now we’ve got a project page and new mailing lists set up (see the project page for the lists, and please subscribe!).  We also have a fledgling Podling PMC to manage the project.  We’ll be migrating our bug database into the Apache Jira instance, and of course moving the source code over as well.