1. Your love of OpenStack is not enough.

You've had your "Aha moment." You get the OpenStack value proposition. You've listened to other customers talk about their success with it. You can see the problems it's going to solve for your organization. You are all in.

But it's not enough. Just know that. Even if you're the decider-in-chief, and you can make the call to start an OpenStack initiative at your company tomorrow, you've got another, bigger job on your hands, and that's changing your company culture.

So say the panelists that were speaking at a Cisco-sponsored session yesterday about their experiences with OpenStack. They agreed unanimously that the technology isnotthe challenge when deploying an OpenStack-based private cloud. It's changing the company culture. Giving developers more freedom and trusting them to do great things (which a proper cloud will in fact enable them to do), vs. controlling them tightly in a traditional IT environment. It's embracing the "Fail fast, fail small, fail often," model that allows for quick learning and innovation.

One panelist said, "The technology is there. It works. It's easy to use. But changing how people use it is the hard part." Another pointed out that it's even harder if you're in an established (non-startup) company with yearly CapEx cycles and capacity planning. "It's difficult to get groups to buy in on an OpEx model and move away from their established processes," he said, with a look that suggested he's been down that road. A third mentioned "dragging them kicking and screaming" as part of his strategy to get his company there.

All agreed that moving to the cloud is the right thing to do. Just that the big surprise was that the technology was the least of the challenges when doing it.

1. Herding cats is absolutely do-able. Just remember that they're not your cats.

Some of them are HP's cats. Some are Intel's. And still others belong to Swiftstack or Red Hat. The point is that they all have homes. They are not strays with nothing else to do. They have obligations to those that feed them. So if you're going to borrow those cats for the OpenStack project you're leading, you need to respect that. It will make for happier, more loyal, more productive cats.

Other tips that John Dickinson passed on in his talk about how to get things done as an OpenStack PTL:

• Tie your new idea to whatever else is already going on: The people in the community are all working on their own things and want to make things better, but they have limited time. If you want them on board for your project, find a way to make it relevant.
• Build motivation: Want your contributor to have enough time to work on your project? Help make it clear how this new feature will benefit his/her employer. Maybe it's cost savings. Maybe it's a revenue opportunity. Make the value prop clear so the employer gives your contributor the latitude to get the job done.
• Sell the story: You have to sell the dev community on your idea as well. Tell people who the potential end customers are. Tell them exactly what they're going to get out of it. And then start talking about it...publicly. Blog about it. It keeps you accountable, builds interest, and gets the feedback loop started.
• Communicate while doing the dev work: Early and often. The more you communicate about exactly how far it's come along, the less often you'll have to have awkward conversations about why you haven't done anything at all (which happens when you do the hard backend design parts first and no one can see evidence of your efforts), or why you haven't finished after so much fast early progress (which happens when you do the easier, user-visible stuff first).
• Manage it with whatever tools work for you: Maybe it's a cool custom Gerrit dashboard that helps people know what to work on. Maybe it's an outside tool like a Trello project page. If it's going to make priorities clear and help people get things done, use it. But definitely use something (John has some excellent examples if you need them). Also, make liberal use of in-person meetings where possible, and provide regular status updates to keep everyone engaged.
• Release when it's ready: Not on some arbitrary date. You can't control what everyone is working on, so don't try to promise you'll be done when you really don't know.
• Sell the story again: Tell people about your new feature a month before the hoped-for release, and keep talking after it's actually out. Make it all about the use cases. Explain how it works, what it will do for end users, and why you did it in the first place.

1. Python may remain the favored child, but it's not going to be the only child much longer.

The community is opening up to the idea of using other programming languages. I heard it more than once-on panels-from people whose opinions matter. The only questions seem to be how and where to get started, and how to mitigate some of the complications that will result from this shift.