Shared Intro: After the summit (#afterstack), a few of us compared notes and found a common theme in an underserved but critical part of the OpenStack community. Sean Roberts, Allison Randal, and Rob Hirschfeld committed to expand our discussion to the broader community. Instead of sharing a single post, we wanted to bring our individual perspectives to you and start a dialog. See Rob’s post and Sean’s post.
Historically, open source projects have focused on developers as individuals, applying a kind of social filter to their corporate affiliations. And historically, this was the right approach to take. Those of us who have been around a while have collected far too many old stories of companies that tried to control open source projects rather than beneficially participating. Downplaying the companies behind the developers was an effective way to channel their contributions through a sanity filter.
But, there’s another dimension that few open source projects acknowledge, which Rob Hirschfeld has aptly dubbed “hidden influencers”. I encountered it at Canonical, and now at HP: developers don’t operate in a vacuum, and their success or failure at contributing to open source projects depends heavily on the support (or lack of support) they receive from the management context they operate in. This is true for independent developers — whatever day job they have to pay the bills may not understand why they spend their nights and weekends on volunteer development. (Many of my employers have understood, and I have always felt lucky that they do.)
Support from management has an even greater impact on developers who work on open source as their primary job.
Some people might see that as a bad thing, but I don’t. I can tell you from experience at Canonical and HP that a manager or executive who understands open source (possibly even has experience doing open source development) is a powerful force for good in an open source project. Unlocking the power of those hidden influencers is a unique opportunity, and very few open source projects are effectively taking advantage of it.
As I’ve talked with managers at HP and other companies around OpenStack, it impresses me that the vast majority who have OpenStack core reviewers or PTLs on their team are actively enthusiastic about their developers’ work and success within the project. I saw a number of these managers at the Summit in Atlanta. But you probably didn’t see them or talk to them.
Are these managers hiding? Not exactly. They are all over:
- Design Summit: Those sessions are geared toward developers.
- General session: Those sessions are geared toward users and operators.
- Developer’s lounge
- Hallways: This informal “track” is the main place where you’ll see managers interacting.
But there really isn’t any forum for managers to interact around the kinds of topics that fill their daily task lists. So what would have been valuable in cross-company management communication?
- Allocating developers’ time to deliver the features discussed.
- Sharing workloads across developers in multiple companies, and avoiding duplicated efforts.
- Balancing internal delivery commitments with external delivery commitments.
- Growing new contributors, from existing employees and new hires.
I not talking about release management here, OpenStack has a highly effective release management program already in operation. What I’m mostly talking about is people management, though there’s also an element of business strategy around OpenStack.
I’d like to see OpenStack as a project more actively engaging with managers as participants, acknowledging their contributions and building collaboration structures for them. Done right, this could set a strong positive example for future open source projects, blaze a new path for guiding beneficial corporate contribution, above and beyond trying to ignore them. Let’s start by simply talking with managers of OpenStack contributors at a variety of companies, finding out where their pain points are and what kind of collaboration would be most beneficial to them.