open source marketer and community manager

Month: June 2014

When OpenStack launched, it made four clear promises to its community: Open Source, Open Design, Open Development and Open Community. Open Source for OpenStack founders has been clearly explained:

We are committed to creating truly open source software that is usable and scalable. Truly open source software is not feature or performance limited and is not crippled. There will be no “Enterprise Edition”.

I find it worth restating that promise because I believe the four ‘Open’ promises that largely contributed in boosting OpenStack growth. There is a conversation about what is Cinder itself and what’s the role of its drivers. It’s a highly technical debate and a very important one, where I think this promise needs to be reminded: There will be no “Enterprise Edition”.

I won’t enter into technical details because it’s not my role. John Griffith and Ken Hui have a lot of interesting things to say about this and I suggest you to read their posts. My personal opinion based on what I heard in Atlanta and read afterwards is that one approach puts Cinder in danger of becoming only useful if you pay a license to someone offering “value added” (better, freedom removed) pieces of hardware and software. That would be very shortsighted and that’s not what OpenStack is. I think any leader of OpenStack has to be very careful when implementing changes that may put OpenStack’s promises in danger. The promises we made as a community are the first things to keep in mind during any conversation, technical ones included.

One of the challenges at large projects like OpenStack is to know people, understand who is doing what, how to reach out to them. There are a lot of different classes of people involved in OpenStack: developers, users, speakers and participants to conferences, voters for OpenStack Foundation’s official governing bodies, maintainers of company’s presence on Marketplace and more. At the moment we’re using different tools to collect this information and carefully provide access to it. Most of the data is in the database behind OpenStack.org website: that’s where users register to respond to User Survey, Foundation Individual Members create their identity to be later verified by Gerrit, company administrators manage the content for Marketplace. Coupled with Launchpad OpenIDs, the .org database contains the vast majority of identities of people involved in OpenStack. Since we’ll soon be able our own OpenID provider, we should start building a directory for all OpenStack People based on the database we have now.

We’re finalizing the design of the new openid provider portal so that it will be the ultimate place to hold the profiles of all people involved in openstack, from users, developers, people editing copy on the marketplace, etc. The basic plan is to merge pages like Foundation’s member profile with the OpenID profile and get ready to add more data to those page, make them more interesting and ‘alive’ adding things like achievements, badges and more.

We have also the chance of reducing the pain that it is now to manage Individual and Corporate CLAs. While the discussion to switch to DCO goes on, I think we should simplify what we have now since it’s very easy to do. Currently new developers need to create an account on openstack.org, go to launchpad.net and create an account there, then go to review.openstack.org and create an account there and click-sign an Individual CLA making sure they use the same email address in gerrit as in openstack.org. Gerrit then queries the .org database and if it finds an email match, gerrit stores the fact ‘user signed the icla’ in its database. It’s not over for developers who work for corporations: those should also have their managers approve/list them in the Corporate CLA (if/when needed) which is a totally different thing, managed ‘manually’ with an echosign form.

We want to change all of this, since we already have most of the UI and infrastructure in place to make things simpler. There is a blueprint filed for this effort and specs, also check the discussion on the infra mailing list to gather feedback and move to implementation.