Stories and software have been the two defining aspects of Brian Proffitt‘s varied and fascinating career.
From local newspaper journalist to community analyst at Red Hat, the ability to communicate effectively to different audiences has been central to his work.
And the relationship between communication and community is a theme he will explore in his upcoming talk at DevXCon.
“There’s so many different ways that storytelling becomes useful, especially around open source,” he says.
“From a purely pragmatic marketing level, I can tell a story about a use case that’s like storytelling 101 – hey these guys use this project to do this really cool thing and we’re going to share it with you and maybe it’ll resonate.
“So that’s bare bones base level storytelling, but then we need to look at how do we take the creativity, the passion for your product and make that interesting to everybody else?”
The ability to promote a personal passion in the wider world isn’t one that comes naturally to everyone, as Brian acknowledges.
He accepts it can be hard for open source communities to see that just because they find their latest project, it doesn’t mean everyone else will – and that’s if they even know about it in the first place.
“I have literally worked for projects where they have said verbatim, ‘We don’t need to put any effort into publicity or marketing or advocacy, because our software stands on its own,’ he says.
“And I wanted to cry when I heard that and it’s not really for my job security as much as just, ‘No, you’ve got it wrong because if no one knows about your software they’re not just gonna magically show up, you know.’
“That is why I feel that it is important that we focus on storytelling more because however you want to tell the story, it’s got to be expressed in a way that more people can understand it.”
Brian honed his communication skills at the start of his career, working as a local newspaper journalist.
Among the hard news stories – the crime or the official community decisions – came the human interest pieces; features about people making cat statues from butter (as a small town newspaper reporter, he says, this is only a slight exaggeration) or cautionary tales of finding giant mushrooms in the woods.
“In open source, I think you can make an argument that says, okay, this is a story that is talking about the software. This is what it can do and this is how it does it and this is why it’s important,” he explains.
“But then you get a story that’s completely separated from the human interest side and I don’t believe it should be separated. I think that in a community it’s more interesting to talk about why you got to this point and how you got to this point and share that.
“And this,” he admits, “drives people crazy. It’s important to share about how you screwed up – but a lot of people are not willing to talk about that.”
But it’s that openness about mistakes, believes Brian, that is the key to developing the story and opening up the two-way communication between developers and users – even if that means users telling you what you did wrong.
“That kind of information people would kill for,” he adds, “and you’re being honest about it and by publishing it you’re saying you know it’s a problem, you’re going to fix it and instead of a story that’s one-sided, you have interaction and I think that’s an important part of these stories as well.”
Asking the difficult questions has been part of Brian’s role since those early reporting days.
He went from news journalism to technology publishing at Sam’s Publishing. There he saw the passion and intensity people were putting into OSS before making the leap to becoming the first community manager at The Linux Foundation.
Subsequent community roles at SUSE and now at Red Hat have drawn on Brian’s background, with his publishing knowledge enabling him to focus on improving and organising the process around documentation.
At Red Hat, the story is currently around communities and finding the most appropriate metrics to measure the health of those they support either directly or indirectly.
As part of this drive to find the right metrics, Red Hat has been working with Spanish company Bitergia to create dashboards of data. But, Brian says, they realised they were a step ahead of themselves.
“We quickly realised we hadn’t done the first step of stepping back and asking what does that mean, what am I looking for? We did this uh-oh moment right about the time the Linux Foundation started working with a group of academics who were building something called Project CHAOSS.
“It’s a project housed in the Linux Foundation that is working on establishing core values around community health. We’re working with them and figuring out what are the actionable metrics on those core values.
“So now we feel fairly comfortable in saying we’ve got something we’re sure about and we’re actually auditing all of our existing upstream projects to see where the gaps are and to see if there are some areas where we could be healthier.”
For Brian, taking this step back when it comes to metrics, can also be applied to delivering clear communication – especially when it comes to developer audiences.
“It’s kind of a cliché,” he admits, “but I’m a big believer in know your audience. You have to know who you’re writing for, who you’re podcasting to or who you’re giving a presentation to.
“You need to know your audience so you can communicate with them effectively. When developers write documentation, they always seems to feel like they’re writing documentation for other developers – but users care about use cases not what’s in every dialogue box or menu in your software.
“So know your audience. How I tell a story, how I talk to you, depends a lot on what we’re talking about. You’ve got to know your audience and know where you’re talking, besides knowing what you’re talking about.”
Be part of Brian’s audience for his talk Media 101 for Communities at DevXCon San Francisco from 4-5 June.
Indeed has seen a huge uptick in Hacktoberfest participation from their engineering team. Hear how they did it.
People were organising communities long before developer relations. So what can we learn from those that went before?