One of the challenges at large projects like OpenStack is to know people, understand who is doing what, how to reach out to them. There are a lot of different classes of people involved in OpenStack: developers, users, speakers and participants to conferences, voters for OpenStack Foundation’s official governing bodies, maintainers of company’s presence on Marketplace and more. At the moment we’re using different tools to collect this information and carefully provide access to it. Most of the data is in the database behind OpenStack.org website: that’s where users register to respond to User Survey, Foundation Individual Members create their identity to be later verified by Gerrit, company administrators manage the content for Marketplace. Coupled with Launchpad OpenIDs, the .org database contains the vast majority of identities of people involved in OpenStack. Since we’ll soon be able our own OpenID provider, we should start building a directory for all OpenStack People based on the database we have now.
We’re finalizing the design of the new openid provider portal so that it will be the ultimate place to hold the profiles of all people involved in openstack, from users, developers, people editing copy on the marketplace, etc. The basic plan is to merge pages like Foundation’s member profile with the OpenID profile and get ready to add more data to those page, make them more interesting and ‘alive’ adding things like achievements, badges and more.
We have also the chance of reducing the pain that it is now to manage Individual and Corporate CLAs. While the discussion to switch to DCO goes on, I think we should simplify what we have now since it’s very easy to do. Currently new developers need to create an account on openstack.org, go to launchpad.net and create an account there, then go to review.openstack.org and create an account there and click-sign an Individual CLA making sure they use the same email address in gerrit as in openstack.org. Gerrit then queries the .org database and if it finds an email match, gerrit stores the fact ‘user signed the icla’ in its database. It’s not over for developers who work for corporations: those should also have their managers approve/list them in the Corporate CLA (if/when needed) which is a totally different thing, managed ‘manually’ with an echosign form.
We want to change all of this, since we already have most of the UI and infrastructure in place to make things simpler. There is a blueprint filed for this effort and specs, also check the discussion on the infra mailing list to gather feedback and move to implementation.
The OpenStack Foundation has always tried to increase genders diversity in our community: we joined the Outreach Program for Women, established clear policies for our summits and in general we’ve been actively promoting good behavior across the board. A few weeks ago I realized that we were lacking of a decent way to track our progress in gender diversity in the OpenStack developer community and decided to improve the situation.
When Anne asked me for the number of women or non-male developers in OpenStack, I realized that we don’t have that number. When people register to become OpenStack developers they need to become members of OpenStack Foundation and have an account on Launchpad. Neither of them track gender information. The best number I had to offer was the t-shirt kind requested at our Summits. If you don’t measure it you can’t improve it, the saying goes. So we thought we need to offer the option for Foundation’s members to tell us their gender, if they want to. How do we ask for gender without being disrepectful to non-binary genders?
We did some research, discussed them on the bug and adapted the best practices to our case. We wanted to keep the choice short and not to offend anybody by leaving out options. An open entry form leads to hard to use data (people have very creative ways to spell just about anything), using pronouns would have made translations a nightmare. We need a way to restrict options so we can easily count them in the database so the binary options male/female were set first and ‘Prefer not to say’ was soon added as another option, since it’s really not mandatory to disclose that information. For non-binary genders using “Non-binary” sounded too geeky to me; using ‘other’ sounds weird, borderline offensive. We came to a consensus on my suggestion to have an open entry prefixed by “Let me tell you”. I liked this phrase because I feel like “Let me tell you” empowers the member to own their own gender definition. The new form is now live so you can now register or edit your OpenStack Member profile and add your gender (if you want to).
The discussion held a few weeks ago at Community Leadership Summit around how to ‘measure’ open source projects were very interesting. There was even a keynote by David Eaves during OSCON about the topic (well worth 15 minutes of your time, watch it below).
There are many people comparing different open source projects, I keep seeing blog posts trying to extrapolate complex concepts from too simple facts. For example, it’s hard to evaluate if an open source project is growing just by looking at the total number of commits per week: when number of commits slow down it may mean that the codebase has reached maturity, not necessarily it’s a sign of diminishing interest. Other simple facts visible on github like the number of followers, forks or ‘watchers’ may not mean much if the developers of that project don’t use the ‘social’ features offered by github.
To measure the “growth” of a project I usually look at a whole bunch of numbers and trends (more importantly) like the total number of committers over time, total new committers over time and also things that are not code-related traffic on mailing lists/forums, websites, google searches, activity on bug trackers as indicators of growth of a community. The total number of commits is more meaningful when taken as one element of ‘livelihood’ of a project (is it still maintained?) but it needs to be integrated with other elements to avoid making mistakes.
All the people interested in measuring open source communities should join the Metrics Working Group at The Open Source Way and push the conversation forward.
Following the rule “you cannot improve what you cannot measure” I started putting together a system to measure engagement in OpenStack community. There are lots of factors to take into account for engagement of members of a community. With OpenStack I started from code, I will keep adding other sources of data that will help me drive engagement up.
This post is mostly about the progress I made using CVSanaly to dig into OpenStack git repositories, build a database from the git logs and extract useful information from it. CVSanaly is a tool developed under a EU sponsored project (FLOSSmetrics) and currently maintained by a few universities.
For the curious among us, I documented the steps to populate the CVSanaly database with data from OpenStack git repos on a new wiki page. You’ll find there also the implementation details of the reports that answer questions like: Who commited to an OpenStack repo, how many times in the past 30 days? See the demo report built with Pentaho Reporting representing the total number commits per repository in past 30 days (pdf).
The long term vision is to have a self service dashboard where anybody can slice and dice all data about OpenStack community, code, bugs, interaction on mailing list and irc and more. I’m experimenting with Pentaho and Jaspersoft tools, still not sure how to proceed. If you have experience with them let me konw. I’m also hoping that Mozilla releases more details about the implementation of Mozilla Metrics project (still under wraps, after a premature leak a few days ago).
I see a world of games, competitions, fun to be added to online communities using social currency platforms.
Social currency is shared information that encourages further social encounters. It’s not a new concept, but the social web increases its prevalence. In the web-based collaboration software platform called Rypple, a simple act of thanking someone on a team and using a badge as a way to show your gratitude is a form of social currency. A platform called Badgeville promises to add virtual rewards to your digital media property through leaderboards and virtual “badges” that act as reinforcements to reward certain behaviors and encourage others.
via Serious Play: The Business of Social Currency – David Armano – The Conversation – Harvard Business Review.