VM (aka Vicky) spent most of her 20 years in the tech industry leading software development departments and teams, and providing technical management and leadership consulting for small and medium businesses. Now she leverages nearly 30 years of free and open source software experience and a strong business background to advise companies about free/open source, technology, community, business, and the intersections between them.
She is the author of Forge Your Future with Open Source, the first book to detail how to contribute to free and open source software projects. Think of it as the missing manual of open source contributions and community participation. The book is published by The Pragmatic Programmers and is now available at https://fossforge.com.
Vicky is the Vice President of the Open Source Initiative, a moderator and author for opensource.com, an author for Linux Journal, and a frequent and popular speaker at free/open source conferences and events. She's the proud winner of the Perl White Camel Award (2014) and the O’Reilly Open Source Award (2016). She blogs about free/open source, business, and technical management at {anonymous => 'hash'};.
Authored Comments
It's important to remember that the metrics selected will vary by organization. Not every org has the same needs. They must each analyze why they are undertaking a community effort and where/how they wish to have impact. This will inform which metrics will be important for tracking.
Simply tracking any old metric (or, even worse, EVERY old metric) is a management smell. It's evidence that the organization may not have a firm grasp on the reasons for and benefits of a community effort. When you sense this, it's time to regroup and make sure everyone is on the same page.
There are a lot of different types of metrics listed not only by Josh above, but also in a related article of this series: https://opensource.com/business/16/3/resources-measuring-open-source-co…
More resources are available in this Zotero group: https://www.zotero.org/groups/community_value/items
I applaud Atlassian for questioning the status quo and forging ahead to find their own solutions to this problem. I particularly commend them for the openness of the process. We all can learn from each others' mistakes, but only if we're not only bold enough to make them but also (harder) to make them public.
The honest fact is that the 'HR Best Practice' does not apply to most teams in the software industry, yet we keep trying to follow this lead simple because the Practice is labeled Best.
I've blogged about something along these lines (http://anonymoushash.vmbrasseur.com/2012/02/01/staff-quality-deserves-the-same-care-as-software-quality/). The post received no online comments but several offline and all parroting the "but that's not the way it's done" party line.
To that I say: So what? Take the time to challenge the way it's done. If it ends up that "the way it's done" equals "the way it should be" then you've just validated your time and effort. If it doesn't then you know it's time to change course rather than spin your wheels on a process which doesn't work.