• My cousin will be working on "very important joints" during London Olympics http://t.co/LWJgihG7 < congratulations doc 🙂 #
  • Quote of the day: "that jib is luffing" /cc @nmar #
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.

How to track contributions to the community  (etherpad notes)

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).

Communication – IRC, mailing lists, blogs, forums (etherpad notes)

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.

Panel: Expanding the Community

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 used a few slides to introduce the topic Growing the OpenStack International Community:

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.

Then, OpenStack supports Amazon’s API quite well, thank you. Such support is there to help companies move away from Amazon. I’ll have you read Jim Plamondon’s comment about how Amazon should not be allowed to follow Microsoft’s strategy (and Jim knows it very well).

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?

  • Is this he weirdest bumper sticker or what? http://t.co/mPJ2dEge #
  • For pessimists a sunny day in San Francisco in spring is like an episode of Game of Thrones: winter is coming! #
  • Things my cousin says: Soccer warm-up may help teen basketball players http://t.co/EZp0uqsq #
  • I'm getting more and more fascinated by ocean races… one day … http://t.co/sOZPVl18 #
  • Qingye Jiang analized OpenStack OpenNebula and Eucalyptus activity on forums/mailing lists (in Chinese and English) http://t.co/Nf7UVomB #
  • Getting ready for 3 days at Linux Collaboration Summit. See you there, I have OpenStack stickers 😉 #
  • OMG! Animated GIF as bullet point on a presentation! It's 2001 all over again #LCS #
  • Quite an endorsement of OpenStack by IBM Gerrit Huizenga from stage at #lfcollab #
  • Bryce says compatibility is a feature of OpenStack, but not a defining tenant "We're not trying to be an Amazon clone" http://t.co/uQxVmXwB #
  • ALT-TAB in Unity is completely screwed up, incoherent like OS X. I hope they fix it or I'll go back to Windows NT. I swear! Not #
  • I believe Flash uploaders are evil… and on Linux it's badly broken #
  • is there a bookmarklet for bookmarks on identi.ca like the one for freelish.us? #
  • RT @scottsanchez: With the Essex release there is now a "stable branch" and team to backport patches/bug fixes to Diablo… #
  • I feel like I made an important discovery: Kosker salt is not "kosher" but only a marketing term http://t.co/LCVZy1JQ #
  • as usual @rms is right: Facebook is an international parasitism project http://t.co/lh0eZRDy #
  • What a week! ISoTotallyNeedBeer! And sun on my face and wind and splashes of ocean… #
  • Preoccupante: siamo stati invitati a cena domani, Pasqua ebraica, e scopro ora che saremo 13 a tavola… #
Il nuovo pianto greco degli artisti che lamentano perdite inesistenti e accusano i motori di ricerca di rubargli guadagni. Sono i soliti lamenti già sentiti e già ampiamente sbugiardati da molto più esperti di me in materia. Una cosa mi è saltata agli occhi: le rughe dei protagonisti del video.

Enrico Ruggeri 41 anni
Gino Paoli 78 anni
Caterina Caselli 66 anni
Ludovico Einaudi 57 anni
Roberto Vecchioni 68 anni
Franco Battiato 67 anni
Mario Lavezzi 64 anni
Ron 59 anni

Che altro vogliono questi relitti?

A scopo informativo, vale la pena riguardare questo video di Rob Reid a TED su come i conti dei cari vecchietti non tornano.


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?