At OpenStack Summit in Barcelona, Emily Hugenbruch, John Arwe, and Ji Chen will give a talk called How to lose clients and alienate coworkers: Lessons learned on an OpenStack enterprise journey. In a recent email interview, Emily, an Advisory Software Engineer and z/VM OpenStack Community Liaison at IBM, discusses the transition developers from proprietary backgrounds must make when they move onto open source projects, and she explains the big ROI on sending developers to conferences.
Your upcoming OpenStack Summit talk will cover how not to introduce OpenStack to your existing customers. What are a few mistakes people make? What should they do instead?
Well, you'll hear more specific examples in our talk, but generally we find that there's so much excitement around OpenStack that we forget that:
- it's not the answer to every computing issue, and
- it's still very much a growing and evolving solution.
That kind of blind enthusiasm can sometimes mean people dive into a project without evaluating it. The community is doing a great job with, for example, working groups to incorporate more feedback from the users and the enterprise community, but there are still some gaps and you have to be mindful of that when you're implementing a customer solution.
What do developers who come from proprietary system backgrounds often find frustrating when developing in the open? What differences do you think they'll come to embrace once they get adjust to the change?
The most obvious frustration is learning new tooling, but that is usually a temporary frustration, since open source tooling usually improves faster than proprietary.
Most proprietary developers are very well versed in navigating their own organizational structures. They know how to get things done within—and sometimes in spite of—their companies' rules. So open source brings a whole new set of rules to learn, and a new organization to navigate. It's really like joining a new company, while still staying at your old job, too. That can be tough to learn and it can make budgeting your time very difficult.
But learning new skills is never wasted; learning better time management is never wasted. I think that developers who switch from proprietary to open source find themselves growing a lot and enjoying that.
What role does attending conference play in open source development?
Imagine working for a company but never meeting another employee face to face, or never having a phone call with your team members. While a lot of interaction takes place over email or IRC—or even in patch comments—nothing replaces getting to meet people face to face, hearing their voices. It builds a sense of community that's difficult—if not impossible—to cultivate just via written words.
In terms of ROI, why should managers prioritize having a healthy conference travel budget for developers?
When someone goes to an OpenStack Summit for the first time, it's amazing how much knowledge they come back with. The hallway conversations, chance meetings, overheard design discussions—they all give you an immersive learning experience that is just second to none. So managers should realize that this is an incredibly cheap way to get a week's worth of education. Plus, like I mentioned above, it's just very hard for people to feel that they're a real part of the community without the face to face interaction, so I don't think developers will be as productive without coming to summits. Contrary to the stereotype, coding is a social activity—you need connections within the group to get things done.
Even for proprietary developers, this is important. There's nothing like being face to face with a user who's frustrated with your code to make you realize how much your job matters—it's even better when they're delighted with your code.
You point out that the community doesn't seem to appreciate hearing about how a platform brings in millions of dollars in revenue and has decades of history. What kinds of shared experiences should organizations focus on instead?
Both the community and companies want their users to be successful. And both want to do it in an efficient way that also doesn't burn out their developers. So if you start with the focus on users and keep the examples specific, it's a lot more meaningful than starting with history. If you think about coming into the community as an interview, what's more impressive: the job seeker who tells you about all their awards and accolades, or the one who tells you about the way they solved problems in their previous jobs?
Any additional thoughts you'd like to add?
Lots of room at our session (5:05-5:45 PM Wednesday, October 26). We promise it's not just another boring session with slides full of text.
Comments are closed.