John Dickinson is Director of Technology at SwiftStack and Program Team Lead (PTL) of the OpenStack Swift project. Last year, he gave us an update on Swift's progress with Storage policies: Coming to an OpenStack Swift cluster near you for Opensource.com. In this follow up interview, John offers tips for improving community collaboration on open source projects, and gives us a preview of his upcoming OpenStack Summit talk.
You've shared with us about storage policies before, but why are these important, and why was this such a big undertaking?
Definitely refer back to that article for why storage policies are such a big deal. In summary, storage policies is the basis for a huge amount of flexibility in how people deploy Swift. It allows for deployers to match their needs exactly to their infrastructure and offload the hard problems of storage to Swift so that devs can focus on making great apps.
Also, storage policies are the basis of newer features like Erasure Codes, which were recently released. The lessons we learned working together in the community on the Storage Policy feature directly applied to how we worked together on Erasure Codes, and as a result our community is better.
How many people helped develop storage policies, and what were their roles?
The entire community was involved with both Storage Policies and Erasure Codes. A lot of the day-to-day effort in creating those features is done by the developers, of which there were probably about a half a dozen. But the "Swift community" is larger than that. It also includes a lot of the non-developers working at various companies. It takes devs, sales, marketing, and product people to take this open source thing and turn it in to something that's useful and used by people. All of these people are crucial to the success of Swift, no matter where they are.
Specifically, the contributions from SwiftStack, HP, Intel, and Red Hat have been invaluable in completing both storage policies and Erasure Codes.
Without giving your whole talk away, what were a couple of things you did right, and a couple things that went wrong when trying to coordinate the different contributors and managing the project?
The "good" that we did is focus on communication. We tied the developer work into the specific goals that various companies have. Tying the story together into a cohesive vision and sharing that clearly with everyone is vital for getting people in an open source project to cooperate on the same thing.
We didn't do everything right, though. One thing we struggled with is bringing people into the development work late in the process. For example, at the very end when we were merging the completed Storage Policy feature into master, we put documentation right up front as the first thing for people to review. Unfortunately, this encouraged people to find small documentation nits before looking at the actual code, and fixing those slowed down the overall process. We learned from this and did a much better job of keeping everyone informed and removing those "bike-shedding" reviews when we worked on the Erasure Codes feature.
Which open source tools were most useful to help organize the project? What was missing that you needed?
The key is communication, not the particular tools. During the development process we used wikis, IRC, Trello, and gerrit for collaboration. We also had a few in-person meetings. That high-bandwidth communication was crucial to delivering these features.
The lesson here is to not get hung up on the particular tools. The best tools are the ones that integrate into the existing developer workflow. Tools that require yet another login are hard to adopt. What I would love to see, and haven't found yet, is a tool that unifies idea discussion, code review, and issue tracking into one place.
What tips would you give project managers or open source project leaders before they kick off a project that requires community collaboration?
Communication is key. You can't hide what's going on in an open source project, so exploit that and make sure everyone—from devs to downstream sales—knows what's going on. Also, in an open source community, you can set target dates, but you can't actually guarantee them. So don't. Be honest about what's going on, and make sure everyone keeps the overall vision in front of them.
Speaker Interview
This article is part of the Speaker Interview Series for OpenStack Summit Vancouver, a five-day conference for developers, users, and administrators of OpenStack Cloud Software.
Comments are closed.