Thoughts on OpenStack

Since I joined Rackspace a little over a month ago, I’ve gotten involved with OpenStack, learning the APIs, getting involved in discussions, and contributing code. I wanted to write a bit about what some of my experiences have been, particularly with respect to the code and contribution process.


Were I to have started to design a system similar to OpenStack, and particularly components like Swift (Object store), the first thing I would have done would be build a (or select an existing) general purpose distributed database. The OpenStack developers did not go in this direction, instead they built tools specific to each of their needs. It’s not yet clear to me whether this is a better or worse direction, but it was one of the most striking things to me.


Open Stack’s contribution process is fantastic. Most open source projects have a group of individuals who are committers (often called “core developers” or similar) and the rest of the community contributes by sending patches, which these committers merge. Eventually members of the community become committers; this model is seen in projects like Django or CPython.

OpenStack flips this on its head. In OpenStack there are no committers. The only thing that commits is a Jenkins instance. Instead, they have “core reviewers”. Essentially, to contribute to OpenStack, whether you’re a long standing member or brand new, you upload your patch with a git-review script to their Gerrit instance. People who follow that project in Gerrit are notified, and Jenkins CI jobs are kicked off. People will review your patch, and once it has both passing tests and the necessary number of “+1” reviews from core reviewers, your patch is automatically merged.

This process of having no committers, only core reviewers, normalizes the contribution process. Uploading a patch is the same experience for me, a relative new comer, as it is for someone who’s been working on the project from the beginning. We just have slightly different review experiences. It also puts an emphasis on code review, which I think is fantastic.


OpenStack comprises a large amount of Python code, and I’m a very opinionated Python developer. For the most part the OpenStack code is of good quality, however there are a few issues I’ve run across:

Infrastructure vs. Application Services

A lot of OpenStack’s code is around what I like to think of as “infrastructure”. Things like spinning up VMs, storing disk images, taking snapshots, and handling authentication for all of this. When OpenStack started there was one application service, Swift, which does massively scalable object (“blob”) storage. One of the most exciting developments in OpenStack, in my opinion, is the growth to include more application services, things that directly provide utilities to your application. These include:

It’s worth noting that many of these are still “StackForge” projects, which means it’s not guarnteed that they’ll become a part of OpenStack, nevertheless I think these are exciting developments.

Of particular value is that, because they’re (of course) open source, you’re spared some of the lock-in concerns that come from many “as a service” offerings.

Future involvement

Looking towards the future, I’m hoping to be involved with OpenStack primarily in three ways: