This post is part of the OpenStack Open Mic series to spotlight the people who have helped make OpenStack successful. Each week, a new contributor will step up to the mic and answer five questions about OpenStack, cloud, careers and what they do for fun.
Gabriel Hurley is the Technical Lead for the User Experience team at Nebula Inc., PTL for the Horizon project, a member of Keystone core, and a core committer for the Django web framework. He has contributed to all the core OpenStack projects and developed numerous clients for interacting with OpenStack. His background is in web development and interface design, with a focus on Python and JavaScript development. Gabriel was first introduced to OpenStack while working at NASA, where his skills were immediately applicable to the nascent OpenStack dashboard project. Given his strong personal belief in open source this was a natural fit. Within six months he had moved to Nebula and began working full-time on OpenStack helping to build the future of this incredibly important endeavor. You can follow him on Twitter at @gabrielhurley.
1. Are there skills that you think are critical for OpenStack developers in the next 5 years? What specialties will be most useful? Valuable?
There are a few discrete layers of skills, and a few crosscutting talents. There will always be a need for people who understand the most fundamental layers: virtualization (flipping bits), storage systems (storing bits), and networking (moving bits). Those people will ensure that OpenStack gets faster and more resilient. There is also already an unmet need in OpenStack for people who craft great user experiences. In between are the folks who build the glue code and things like APIs that make it all hang together. In a more general way, OpenStack needs a pervasive awareness of a few key areas. Foremost, more people in the community need to have a basic understanding of security. This is the hardest job in Open Source, because as a security person you normally think in terms of attack vectors, audits and reviews. In Open Source a security person needs to spend as much time or more educating other people, because the best security comes from having the people who write the code in the first place be aware of the implications of what they’re writing. The most insidious security holes are buried in otherwise innocuous code, introduced by someone who simply didn’t know any better. Even worse is when a community embraces a practice that actively increases vulnerability (I’m looking at you, Rails…). Secondary to that, OpenStack needs its developers to be more aware of their end users. This shows up most prevalently in the APIs (which are often downright painful), but it also appears in configuration, deployment, and lots of other places. If every developer stopped for 5 minutes and thought about how someone else would use the code they’re writing a few months from now we’d have a much more functional OpenStack. So much of it has been written by people who had their use case in mind. We’re getting better about this as the community grows, but there’s still a lot of room left for more focus on the users.
2. If you could start your career over again, where would you want to begin? Advice for someone just getting started?
Quite honestly, I think my career’s had a fantastic trajectory. I could only wish I’d gotten started sooner. Everything good that’s come to me professionally is because I got involved in Open Source early in my career, I gave it my all, and I learned from fantastic people. Aside from all the magnificent developers in the Python and Django communities, I can’t stress enough how much I learned about leadership in an Open Source community and how crucial that aspect is. OpenStack still has a long ways to go in that regard. But my advice to anyone just getting started is to get involved with Open Source. Why? There’s no barrier to entry; you can do it RIGHT NOW! (I won’t be offended if you stop reading to go start contributing.) You can pick a project you actually use and care about. You will learn from people much smarter than you. You will be exposed to ideas you wouldn’t have ever considered. Still not convinced? How about the fact that Open Source is getting higher profile by the day?Recruiters look at GitHub profiles. Top companies hire talent based on their Open Source contributions alone. It gets your name out there forever and ever in a way that working for a private company almost never will. Need more? How about the fact that the work you do in Open Source immediately benefits people around the world. You’re actively helping people you’ve never met or heard of. I don’t know about you, but all those things make me feel pretty good at the end of the day.
3. What do you think are the benefits of the open, community-driven approach to development?
If you couldn’t already tell, I’ve been involved with Open Source my entire engineering career; I’m a huge advocate for Open Source. Let’s imagine for a moment that one company could somehow amass such a staggering sum of money that they could hire all the talent that contributes to an Open Source project. And then that they devoted the time of all that talent to a single project. You still wouldn’t achieve the outcome of Open Source because you’d be lacking the conflict of different ideas, different goals, and different needs that drives innovation. And that’s with one company bearing all the burden! Let’s look at Open Source in practice in OpenStack: you have a collection of contributors, many working for competing companies. No one individally bears the burden of cost or development time (opportunity cost). Outcomes are improved by the tensions between different groups being forced to arrive at consensus. Features no one else would have thought of are brought forward because someone somewhere wanted to do something a little different. OpenStack works because ultimately it becomes a shared common good. Companies who would gladly obliterate one another are willing to work together because they all recognize that the financial gain isn’t in the platform itself; it’s in what you do with it. We’re all working towards a future where the infrstructure layer is a given. Compute and storage will be ubiquitous, you won’t think about it any more than you think about water coming out of your faucet. Sure, people make money for getting the water to you, but that pales in comparison to the value of agriculture, sanitation, living in previously uninhabitable places… This is the power of a shared interest in a common good, and this is the similar power of Open Source.
4. How do you think the OpenStack community will need to evolve over the next few years in light of the fast growth and maturing user needs?
OpenStack has to learn to function as a concerted whole rather than a collection of autonomous software projects. There is absolutely nothing that would make a bigger difference to users than that. We need consistency and unification in every area: clients, APIs, configuration, deployment, discoverability, federation… the list goes on and on. Up until now OpenStack has been governed by the whims of individual Projects and the frustration experienced by users, deployers, and even developers is obvious. It’s time for OpenStack to develop a stronger sense of cross-project leadership. All the features in the world are nothing if using them is an uphill battle.
5. What other open sources projects do you think work well with OpenStack, and why?
While you can deploy just about any open source application on top of OpenStack, I’m much more excited for the possibilities that projects like Docker (https://github.com/dotcloud/docker) bring to the table. Finding new ways to define and deploy distributed applications is what’s really going to fuel the “Big Data” revolution. OpenStack gives everyone access to the cloud, but once you have a cloud what will you do with it? We need tools that are human-friendly, reusable and remixable; getting your app running should be downright obvious. The secret sauce shouldn’t be in your deployment, it should be in your data and how you make meaning from it. The more we can get to that last step, the more we can change the world. One other open source project that deserves mention is Zipkin (http://twitter.github.io/zipkin/) which was released by Twitter. It’s a distributed tracing engine that allows you to follow one entry point (like an API call) throughout an entire distributed system and to understand exactly what it did at every step of the way. To get to the next level of optimization and unification OpenStack is going to need something like this built in. Trying to understand the complexity of an OpenStack deployment without distributed tracing is an exercise in agony.
