In days like this I feel very lucky to be a member of the OpenStack community. The thread that started today demonstrates the great culture of collaboration among the people that make OpenStack.

Following up on the discussion held at the Design Summit, Thierry suggested to split the Mailing-list in order to improve the communication among developers and users. The proposal requires a significant change in the current workflow for developers and adds a new burden on the infrastructure team. A reason to be proud of this community is that the infrastructure team didn’t say ‘no’ like many IT shops would. They highlighted what they needed in order to do a good job satisfying the request. A volunteer jumped up to help (thank you Duncan) and off we go to do something without wasting time debating. This community is effective and gets things done.

What a week! We had over 1,000 participants from 26 countries (Japan and UK follow USA for total number of participants with Australia, Canada and South Korea in the next cluster), 159 sessions during the summit and 56 during the conference, over 40 hours of intense discussions, decisions and night time fun a total with 8 parties. No wonder some (me first) had to take a break to recover from it 🙂

I led two sessions about community and participated in another few. All have actionable items. Below are the notes I took. In the next weeks I’d like to gather comments and proceed with implementation.

I showed the results of the work I’ve been doing with the metrics about OpenStack development. The plan is to build a datawarehouse that hosts data from git and the bug tracker, plus data from forums, mailing lists, IRC and gerrit. Currently the datawarehouse hosts data extracted from git. A couple of days before the summit the developers of bicho released the extension to gather data from Launchpad bug tracker (the job was sponsored by Rackspace). Mark McLoughlin used git-dm to gather data from OpenStack git repository, creating a good master data record for the association developer-company.

Many people liked the analysis done after the Essex release, while the weekly reports are less interesting. The other important comment is that we should all be careful with which numbers we decide to track as these can lead to “games” to trick the system.

I gathered that it would be more interesting to have monthly reports and more comprehensive coverage of what is going on with the project. Thankfully, Jake Dahn is working on a self service portal as a frontend to the datawarehouse (his work is on github).

General agreement is that the developers mailing list on Launchpad has too much traffic (see the chart http://openstack.markmail.org/). The plan is to keep the Launchpad list for general discussions and move developers to a new set of lists, managed by a powerful list manager that allows automatic tagging of messages, per project. Ideally, a developer would send a message about Quantum to something like openstack-dev-quantum@listmanager with subject “foo bar”. The message would have its subject changed to “[Quantum] foo bar” and it would be delivered to openstack-dev@listmanager. Even if mailman and other list managers have this feature, implementing and running a large email server like this would require resources. The openstack-infra team would help manage the machines but the actual email server administration should be done by somebody else. We need volunteers.

The IRC channels seem to be suffering: #openstack and #openstack-dev are not helping create a sense of cohesion among developers and users. The suggestion is to keep #openstack and split #openstack-dev into smaller channels for each project. The idea is that users and developers will all hang around #openstack, finding questions to answers while the smaller project-dedicated channels will help create bonds among developers.

How to help users get answers to their questions is the main issue we discussed in the section. Currently questions come in from messages to the mailing lists operators and developers, on forums, IRC channel, Linkedin group, Disqus on docs.openstack.org and more. The general feeling is that Launchpad Answers product is not adequate for the task, mainly because it’s hard to measure anything on it and since there are now six projects where you can ask question, and sometimes the answer is related to two projects not just one. The OpenStack forums seem to be gaining traction and should be advertised more prominently from openstack.org domain. We should investigate the possibility to use something similar to StackOverflow.

The OpenStack Planet suffers for having little visibility but, like the forums, it has lots of good content. Also, lots of content that could be in the planet, stays out because to add a blog you need to be a developer (to add your blog to the planet you need to use git and gerrit). There was consensus on adding a plugin to the OpenStack blog to manage syndication of content directly from openstack.org/blog and get rid of planet.

I moderated the panel with Boris Renski, Masanori Itoh, Joseph B George, Tristan Goode, Yoyo Chiang and important contribution from Heng Chui and Sammy Luo from China. There will soon be a video online but the gist of the session is that we need to add more content in local languages to openstack.org, and we need to publish and keep updating the document OpenStack User Group HOWTO. Other comments were that starting a new user group is easy, doesn’t need bureaucracy and it can help companies build a local reputation as OpenStack experts.

I keep reading very strange things about OpenStack and its support for Amazon APIs. I believe it was generally acknowledged that APIs designed by one company were bad and that open API is really what you wanted. Today in Citrix kicks down door, breaks up OpenStack cloud party Matt Asay first quotes a superficial comment from Sam Johnston comparing OpenStack soon-to-be-obsoleted OpenStack governance model to Eclipse Foudation (suggestion: compare the draft documents for the OpenStack Foundation to Eclipse Foundation governance model).

Then Matt jumps on the favorite topics of the cloud pundits: API! It seems that Matt is cheering for one API, Amazon’s, like the history of Microsoft in the 90s didn’t teach us anything:

One aspect of [Rackspace’s] agenda is a shift away from full API compatibility with Amazon’s API, which is one of CloudStack’s major selling points, and one of the big reasons it is striking off on its own. Rackspace could easily have followed this furrow, first plowed by Eucalyptus and VMops/Cloud.com/Citrix, but doing so would effectively cede the API battle to its bitter enemy, Amazon.

The first assumption is just wrong: Rackspace’s strategy is not the same thing as OpenStack’s strategy. Besides, Rackspace has two lines of business on OpenStack and those may not be 100% aligned.

OpenStack and the Free Software/Open Sourcei movement is in the rare position to be able to shape the future of computing, with an API that is designed by a very large set of companies, with lots of money too. This is not a small set of hackers trying to change the world: it’s BIG. OpenStack has the chance to set a real open standard for cloud computing while still allowing a compatibility layer as a migration path for all developers that are currently stuck on the proprietary API designed by Amazon behind closed doors. Companies like HP, Dell, Rackspace, Canonical and so many others are setting together a standard API, a truly open standard that I expect can also be easily ratified by a standards body, if/when needed.

I wonder why people claiming to be open source supporters cheer for the (quasi)monopolist and try to shut down at each occasion the effort of such large community to provide the world an open alternative. What am I missing?

I read lots of comments regarding the agreement between Eucalyptus and Amazon, all focusing on how that affects OpenStack. Some of the comments are plain wrong: let me remind that OpenStack has support for Amazon EC2 and S3 APIs, Canonical leader made it quite clear that he wants to have AWS compatibility in OpenStack and other companies chimed in to maintain that compatibility layer.

I find it more interesting to think about what this agreement means for VMware. My impression is that for new deployments of private clouds the obvious excluded will be VMware: why would you want to use a proprietary set of API incompatible with anything else else out there? Given the option, why should a CIO chose to setup a private cloud that supports a standard that is also available on a public cloud?

Suddenly, I feel that VMWare has become legacy, maybe still a profitable one but one that has more chances to die sooner than Oracle’s legacy database business. What do you think?