This post is part of the OpenStack Open Mic series to spotlight the people who have helped make OpenStack successful. Each week in August, a new contributor will step up to the mic and answer five questions about OpenStack, cloud, careers and what they do for fun.
Brad Topol is an IBM Distinguished Engineer in the Software Group Standards Strategy organization. In his current role, Brad leads a development team focused on contributing to and improving OpenStack. In addition to leading a team, Brad has also personally contributed to multiple OpenStack projects including Keystone and DevStack. Prior to his current role, Brad was IBM Distinguished Engineer, SWG Serviceability, with responsibility for driving IBM software group’s cross-product serviceability and electronic fix distribution initiatives. Over the years, Brad has been involved in advanced technology projects in the areas of product serviceability, problem determination, autonomic computing, content transcoding for mobile devices, and Web Services. In 2000, he received an IBM Outstanding Technical Achievement Award for contributions to the IBM WebSphere Transcoding Publisher product. He received a Ph.D. in Computer Science from the Georgia Institute of Technology in 1998. You can follow Brad on Twitter at @bradtopol.
1. What do you do when you’re not obsessing over and working with OpenStack?
When not working on OpenStack, I am typically either working out at the gym, helping kids with homework, or taking the kids to softball practice, baseball practice, soccer practice, and flute lessons.
2. What was your first commit or contribution and why did you make it?
The first commit that I made was to fix a Glance registry documentation paste.ini sample that was missing a configuration section for using an authtoken filter. I made this change because I wanted to fix a simple bug that would enable me to learn the OpenStack process for making contributions via Git and Gerrit.
3. Are there any skills that you think are critical for OpenStack developers in the next 5 years? What specialties will be most useful? Valuable?
A key critical skill for an OpenStack developer is to have an extremely strong understanding of the Python programming language and its advanced features. So many of its advanced features are used throughout the OpenStack projects and I’m sure this will continue as Python evolves. The most important skill for an OpenStack developer, however, is to not get complacent once they become an expert on one portion of OpenStack. For example, someone may become an expert in Nova and then their job becomes easy. They know how to perform quality reviews quickly and can make contributions quickly and can go on cruise control a little. When a developer hits this point I strongly recommend that they force themselves to get out of their comfort zone and spend some time learning a different portion of OpenStack. This will be hard, and they may hate being the rookie “dumb” guy in the new project. Nonetheless, the result of them pushing themselves to learn something new will ensure that they continue to improve their skills, enable them to drive greater innovation, and will accelerate their career growth and development.
4. What is the most important contribution you’ve made that will make OpenStack users happy?
The most important contribution that I have made to OpenStack that will make OpenStack users happy was adding Transport Layer Security (TLS) support to Keystone’s LDAP identity backend. This enabled Keystone to have an optional secure connection when using LDAP or Active Directory as its backend identity store. What was great about this contribution was that I have been on customer calls where the customer explicitly asked if Keystone had TLS support and it was really cool being able to tell them that yes it does and also that I personally implemented it!
5. What do you think are the benefits of the open, community-driven approach to development?
There are so many benefits of the open, community-driven approach to development. First, the diversity of having developers from companies all over the world results in solutions to problems being identified quickly and best of breed continuous integration development practices being utilized. As a result, development in an open, community-driven approach occurs at lightning speed. Furthermore, the peer review process utilized for every code commit results in a very high quality code base. I know many times I would think to myself that my patch was “good enough” but then my peers would review it and convince me it most certainly could be better. This peer pressure motivated me to deliver higher quality code than what I would have normally delivered had I not been subjected to peer review. Another benefit is that when you run into a problem that you can’t resolve on your own you can then go ask the community. Most of the time there will be someone in the community that has already encountered the same problem and you will be able to solve the problem much faster than just working on the issue in a vacuum. A final benefit of the open, community-driven approach to development is that open communities breed strong ecosystems. These strong ecosystems increase the longevity of the community and this improves the confidence the user base has with the the community software.