Earlier this year, I had the privilege of giving two talks at the CloudStack Collaboration Conference in Denver, Colorado.  Neither talk was specifically about OpenStack; the first was on navigating the differences between legacy and cloud native applications while the second was on getting involved with and growing out technical communities.  While the response within both the CloudStack and OpenStack communities were overwhelmingly positive, I did receive questions from some who wondered what an OpenStack Evangelist from Rackspace was doing speaking at a CloudStack conference and potentially helping to build up a rival community?

One of the reasons has to do with my belief that cloud adoption is at an early enough stage that user education is critical regardless of the cloud platform in question.  But another reason has to do with my commitment to open source technologies and to open source communities.  Those commitments do not preclude the idea of vigorous competition between members from different or even the same communities; however, it does include a willingness to work together in common cause for the sake of promoting the principles and benefits of open source, even if there are no clear benefits for you or your company.  My belief is that by elevating the entire open source community, ultimately  many if not all in the community benefits.

In my role as a Technology Evangelist, I am responsible for helping to drive Rackspace though leadership within the OpenStack community.  Along with that, I am tasked with doing all I can to make sure Rackspace is a good citizen in this community.  Beyond code contribution, it means sharing the lessons we have learned as operators of the world’s largest OpenStack-powered public cloud and the vendor with the most OpenStack-powered private cloud deployments.  Obviously, this doesn’t mean Rackspace is a perfect citizen in the community and we will clearly make mistakes along the way; but we never want to stop trying to elevate the entire OpenStack community.  In the same manner, I expect to make mistakes as I learn my way around this community but personally vow to do the best I can to be a strong contributing member.

As someone who spent much of my career working for vendors who did not contribute to open source technologies prior to joining Rackspace, there are some lessons I’ve learned which may be helpful to those who are new to open source and particularly for vendors who are looking to join the OpenStack community.

• It’s not just about quantity, but also about quality – There are vendors who spend their PR budgets telling the world that they are among the top contributors to the OpenStack project.  While this can be a significant indicator of strong community involvement and leadership, there are also well-known techniques that developers can use to inflate those numbers.  Ultimately, what makes for great software is not number of lines of code, but the quality of that code.  So don’t spend time finding ways to inflate your code contribution numbers, focus on writing elegant code.
• Contribute to OpenStack core, not just your product’s integration – Personally, the way I measure a vendor’s commitment to the community is by how much effort they take to improve the core of OpenStack.  There are plenty of vendors who write drivers and plugins to integrate their products into OpenStack, but how are they making OpenStack a better platform?  If you are a hypervisor vendor who’ve integrated your product into Nova, what else have you done to improve Nova’s ability to scale?  If you are a storage vendor that has written code to plug in your storage array, have you also written code to add new functionality to Cinder?  What we need are more vendors who are willing to make the whole of OpenStack better and not just to make their product a better OpenStack plugin.
• There are no Lone Rangers in Open Source – The best open source technology is created when users and vendors are willing to work together without assuming that everyone is out for themselves.  This means being willing to accept ideas that are not your own and recognizing that someone who is a direct competitor may actually have a better idea than you about the direction of a project.  Are you willing to contribute ideas and code to a project and allow a competitor in the community to take them in a different direction that may be better for the health of the overall project?
• Community contributions dont’ just include sharing code but sharing knowledge – When it comes to operating a cloud, there is much more to it than merely deploying software.  It includes operational knowledge that is often learned through years of experience managing a cloud environment.  It also includes knowledge gained from managing the various OpenStack projects in production.  We need vendors who are willing to have their OpenStack experts share with users and other vendors what they know and what they have learned.  Do your people have permission to speak at OpenStack meetups and conferences or to write documentation and books in order to share valuable knowledge and not just to market your product’s OpenStack capabilities?

As we approach the next OpenStack Summit in Atlanta, I look forward to seeing the community grow stronger and more members contributing in truly significant ways.  Only as the community grows in this area, will OpenStack become the dominant cloud platform of the future.