I asked a question during Matt Aslett's excellent presentation on Monday at the Microsft/SD Forum OSBC Zero Day event: Does your community manager report to engineering or marketing? Matt gently stepped out of the way, but there is exactly one right answer: Engineering.
Here's why:
This doesn't mean that the community isn't an enormous source of word-of-mouth evangelism for the company, the project brand, and self-qualified leads over time. But the community doesn't want messages and they don't want to be qualified or converted. The community is already setting their own expectations around the project instead of buying the product. Neither does this mean that marketing is out of the loop at developing inbound requirements from customers for the engineering team as they develop the software that feeds into the product.
While marketing traditionally managed the "developer network" in closed source companies, that's because the software wasn't a community engagement mechanism for users that weren't customers. Growing the developer community around your platform was a marketing function based on the business strategy of growing market share and providing complement value with lots of "knowledgeable developers" for customers. The software part of the solution wasn't a source of customer contribution, innovation, and testing resource. Your community equated to your customers.
There are companies that historically have strong product management departments that are often staffed by engineers that have crossed the floor to marketing. There's still a problem here with the community manager reporting to marketing, because the marketing department is traditionally measured on marketing functions. They will behave against how they're measured.
So community development and management is an engineering function.
I thought you asked if the community manager should report to "engineering or business". I 100% agree it should not be marketing. But if a company only truly enjoys the benefits of open source when it takes a business-led approach to community engagement (rather than a project-by-project engineering-led approach) then my gut reaction is that the community manager should report to a business leader - but only when a company has reached this level of engagement. I'll explain more in a post when I get 30 minutes or so.
Posted by: Matt Aslett | 24 March 2009 at 18:01
Hi Stephen,
Interesting question. Here's another: As an open source company, why do you have a community manager?
In my experience, the community manager position gets created when a company realises that a group of people want to engage with them, and they don't know how to do it. So they hire someone to do it for them. In some sense, hiring a community manager is an admission of failure as a project.
Some community managers have the job title, but their job is more community enabling and general busybody, removing roadblocks and clarifying and condensing ideas which already exist in the community. I would argue that these people are both valuable and poorly titled. The other kind of community manager, the guy you hire to be the company's "guy in the community", his job is nigh on impossible.
Cheers,
Dave.
Posted by: Dave Neary | 25 March 2009 at 09:18
Great post!
Interestingly, nearly *all* OSS licenses are distribution licenses...Distribution is, of course, one of Marketing 101's 4 P's (Product, Price, Promotion and Place - aka Distribution).
Perhaps Marketing (in the lens of software development) needs to evolve to accommodate another [new] business model, or maybe it spills even further: "Community" seems to be traversing traditional departmental boundaries; one slice might see it as "Customer Base" (such as Marketing) another might look at it as "Developers" (such as R&D) and yet another might look at it as "Quality Control" (such as Release Engineering).
Netting it out, "Command and Control" management is dead. Long live Open Source [meritocracy's surrogate]. Damn, this stuff is exciting!
Posted by: Mark Withington | 25 March 2009 at 17:16