Do you know what people are really doing in your open source project? Having good community data and metrics for your open source project is a great way to understand what works and what needs improvement over time, and metrics can also be a nice way to highlight contributions from key project members. This session will focus on tips and techniques for collecting and analyzing metrics from tools commonly used by open source projects. It’s like people watching, but with data.
The best thing about open source projects is that you have all of your community data in the public at your fingertips. You just need to know how to gather the data about your open source community so that you can hack it all together to get something interesting that you can really use. We’ll start with some general guidance for coming up with a set of metrics that makes sense for your project and talk about the LibreOffice community metrics. The focus of the session will be on tips and techniques for collecting metrics from tools commonly used by open source projects: Bugzilla, MediaWiki, Mailman, IRC and more. It will include both general approaches and technical details about using various data collection tools, like mlstats. The final section of the presentation will talk about techniques for sharing this data with your community and highlighting contributions from key community members. For anyone who loves playing with data as much as I do, metrics can be a fun way to see what your community members are really doing in your open source project.
Every community manager knows that community metrics are important, but how do you come up with a plan and figure out what you want to measure? Most community managers have their own set of hacky scripts for extracting data from various sources after they decide what metrics to track. There is no standardized Community Software Dashboard you can use to generate near-real-time stats on your community growth.
Like most open source projects, we have diverse community infrastructure for MeeGo, including Mailman, Drupal, Mediawiki, IRC, git, OpenSuse Build Service, Transifex and vBulletin. We wanted to unify these sources together, extract meaningful statistics from the data we had available to us, and present it to the user in a way that made it easy to see if the community was developing nicely or not.
Building on the work of Pentaho, Talend, MLStats, gitdm and a host of others, we built a generic and open source community dashboard for the MeeGo project, and integrated it into the website. The project was run in the open at on the MeeGo wiki and all products of the project are available for reuse.
This presentation covered the various metrics we wanted to measure, how we extracted the data from a diverse set of services to do it, and more importantly, how you can do it too.
Do you know what people are really doing in your open source project? The best thing about open source projects is that you have all of your community data in the public at your fingertips. You just need to know how to gather the data about your open source community so that you can hack it all together to get something interesting that you can really use. Having good community data and metrics for your open source project is a great way to understand what works and what needs improvement over time, and metrics can also be a nice way to highlight contributions from key project members. This session will focus on tips and techniques for collecting and analyzing metrics from tools commonly used by open source projects using examples from what I’ve learned doing MeeGo metrics.
A few topics:
General guidance for coming up with a set of metrics that makes sense for your project.
Tips and techniques for collecting metrics from tools commonly used by open source projects: Bugzilla, MediaWiki, Mailman, IRC and more.
General approaches and technical details about using various data collection tools, like mlstats.
Techniques for sharing this data with your community and highlighting contributions from key community members.
For anyone who loves playing with data as much as I do, metrics can be a fun way to see what your community members are really doing in your open source project. It’s like people watching, but with data.
Were you sad and dismayed to hear that OSCON was moving out of Portland? Are you looking for more open source events to attend? Would you like an open source conference organized by the community? Want one more tech event to attend in July? Need an excuse (any excuse) to visit lovely Portland, Oregon in July? Do you like to help organize events for fun in your spare time?
If you answered yes to any of my obnoxious questions above, I have a great solution for you: The Open Source Bridge event.
Open Source Bridge will bring together the diverse tech communities of the greater Portland area and showcase our unique and thriving open source environment.
Open Source Bridge will have curated, discussion-focused conference sessions, mini-conferences for critical topics and will include unconference sessions.
We will show how well Portland does open source and share our best practices for development, community and connectedness with the rest of the world.
Lots of ideas are buzzing around in our heads, and we’d love to talk about them with you! If you’d like to contribute to the effort, stop by the town hall event October 30, 2008 at Cubespace. We’ll have another meeting November 6th, and it will be announced on Calagator.
At the town hall, you’ll have a chance to meet the members of the core organizing committee, and pick up a responsibility or two. We’ll be breaking off into teams for each of the major areas requiring organization, and distributing the work across many people. We will create a mailing list after this first meeting for those who just want to hear about what we’re up to, or participate in some other way.
I encourage you to attend the Town Hall to share your ideas with the team and to talk about how you can get more involved in the event. The key to community driven events is that they require a lot of work from volunteers both during the planning stages and on site during the event! If you want this event to be successful, I encourage you to pitch in to help.
I was just talking to Deb Bryant about the upcoming GOSCON event here in Portland Oct 20th – 23rd, and there are some very exciting things about the event. For anyone unfamiliar with GOSCON, it is focused on providing “forums to explore both the business case and real-world applications for open technology to deliver the next generation of government services”. This is the fourth annual GOSCON event.
I will continue to upload more presentations to my SlideShare account as I deliver them. You can also contact me via email (email@example.com) if you would like to have me deliver a similar presentation or more extensive online community or social media training for your organization.
Here are my notes from the Art of Community lightning talk that I delivered at OSCON yesterday. Some of this advice is geared toward open source and developer communities, but most of it applies to building corporate communities in general. We also used a 3 minute lightning talk format, so the advice below contains only my top few tips that could fit into this fast-paced format.
We’ve all seen times where companies try to sponsor communities. Sometimes they do it successfully, but other times all you can do is watch while the whole thing backfires. Here are a few tips to help companies approach community building in the right way to build successful communities and hopefully avoid the disasters that some companies face.
Tip #1 Think about Ownership:
The company does not “own” the community. The community “owns” the community, and the people participating own their contributions (whether it is ideas, advice, documentation or code).
A company who starts a community:
owns the infrastructure
facilitates the discussions
moderates and keeps people in check
It can be difficult for companies to think of a community in this way. However, if the company doesn’t play nice with the community, the community will take their discussions elsewhere and fork the community and the project.
Tip #2 Keep Sales and Marketing in Check:
This applies to all communities, but is especially true for developer communities.
Developers want detailed information without the fluff. Get rid of the marketing speak and make it easy to find the key pieces of information
Don’t use the community to sell anything. You don’t need to pimp your products and services within the community. If someone is already participating in the community, then chances are they can find out how to get in touch with you if they need something.
Tip #3 Make Someone Responsible for Community Management:
This person can make sure that everything is running smoothly in the community and work to resolve issues before they get out of control.
The community manager isn’t responsible for doing all of the work within the community, but they can pull the right people into discussions and make sure that the right people are participating.
For open source and developer communities, this person should report into the technical side of the company (not marketing)
Companies can have successful communities, but only if they take the time to do the right things and truly participate in the community.
This weekend, we announced a bunch of changes at Jive.
We released Clearspace 2.0, including a renaming of Clearspace X to Clearspace Community. We also upgraded Jivespace to Clearspace Community 2.0 with an update to the look and feel, so I’ve spent a fair amount of time yesterday and today doing lots of testing and some tweaking.
The press has also been writing about the changes (search Google News if you don’t believe me). I won’t go into too much detail here, since the blog posts linked above have a bunch of details, but I am excited about the changes!