Linux Foundation: Panel: Measuring Community Contributions

Luckily I found a power outlet, so here comes more blog fodder!

Panel: Measuring Community Contributions (View Summary)
Joe Brockmeier, Community Manager, OpenSUSE

Panelists:
Jono Bacon, Community Manager, Ubuntu
James Bottomley, Linux SCSI Subsystem Maintainer
Dan Frye, VP, Open Systems Development, IBM
Karsten Wade, Fedora Project, Red Hat

Joe asked each of the panelists to introduce themselves - Karsten as a gardener, Jono a member of a metal band (did I hear that right), Dan Frye - VP of Linux Development at IBM, and James Bottomley - now at Novell and still SCSI subsystem maintainer and Chair of the Linux Foundation's Technical Advisory Board.

James:  Contributions to the upstream kernel is a major source of community contributions.  Karsten points out that users bear the brunt of the poor contributions.  Jono points out that there are key contributions beyond just code.  As an example, ten years ago the documentation project required that you know LaTeX.  Today, contributions such as documentation, translation etc. are valid contributions.  Joe asks what about companies that contribute market or legal review - general agreement that that is a useful contribution.  Dan Frye points out that it was best said by <insert name here> in the Halloween note:  People scratch their own itch.  A real community allows people to contribute as benefits the contributor, as opposed to only contributing from a laundry list of features needed by the recipient.  This is key to the success of a real community.

If your itch involves contributing in the Peer to Patent project, that adds value to you and thus to the community that you are a part of.  James points out that code contributions are critical but so are testing, debugging, bug fixes, etc.  And, the community accepts money (via the Linux Foundation) to support various Linux related activities, such as the Linux Kernel Summit or requested capabilities.

Dan:  I don't see any reason to "grade" people's contributions.  But we do need to remain inclusive allowing people to contribute in ways that helps to scratch their own itch.  There's no need to guilt people into contributing in ways that they don't happen to find worthwhile.  However, it is key to make sure that the community remains open to people so that they can scratch their own itch, to be a part of the community and to grow within the community.

Jono points that we are all still learning about the different ways that people can contribute.  For instance, some people are predisposed towards certain strengths, such as python programmers or documentation writers or graphics artists.  From a distro perspective, the knowledge of how new members could contribute based on their skills is a new and emerging competency.

How much thought goes into a vendor's training and education about how to make community contributions.  Tongue in cheek from Joe:  IBM plans everything, right?  Dan laughs - we try.  IBM does evaluates a new community, understanding what roles we might be able to take on, learned about styles, governance models, and try very hard to learn how to be real and effective members of the community.  James points out that we also learn by mistakes.  Dan points out that there isn't a mistake that IBM hasn't made.

James points out that IBM long ago attempted to make contributions in whole cloth quite unsuccessfully.  IBM then went out to break down the contribution into small components which benefited the community and over time achieved IBM's own ends.  Dan agreed that was a lesson IBM had to learn many times.

Karsten's perspective was that he was impressed with IBM's due diligence.  His feeling is that Red Hat's approach has been more evolutionary in terms of interacting with communities and probably less formalized.  James pointed out that this is a key different between an industrialized approach of "I pay you for X feature" versus the community approach were people get together to share goals and possible solutions and work collaboratively to create a solution.

James points out that the panel has collectively a lot of experience in training an organization to engage with open source and is hoping that this knowledge can be transitioned to new folks and hopefully in part to the Linux Foundation.

Andy Wilson from Intel points out that development seems to be US centric.  Dan points out that IBM has a large number of contributors in India, Brasil, some in China.  Joe asks for clarification - are these people at large in these countries or are they IBM employees?  Dan says these are IBM employees.  Andy agrees that IBM has a supportive corporate culture here, but suggests that the problem is more endemic to the Linux community as a whole.  James points out that IBM's involvement has helped generate a lot more interest in developers in India becoming more interested in Linux.  Dan also agreed that we are (as a community) short on contributors from eastern Europe and other countries as well as a number of other major developing countries - not just Asia.

James points out that there is also an infrastructure problem in these countries which has to be addressed as one of the key inhibitors to the growth of Linux developers in those countries.

A member of the audience asked what objective measures are actually being used - based on the title of this panel.  Karsten points out there there are some objective measure such as mailing list traffic and analyzes the source of key contributors (similar to Greg KH's analysis of kernel contributors).  The goal is to be able to help track the health of any community.  Another measure might be IRC traffic on a project channel.  James points out the work of the Greg KH and Jonathan on the git logs of the kernel to permanently track all contributions.  Karten points out that community is primarily based on communication.  There are some collaboration techniques such as bug work flow that provide indicators of community contribution or community vitality. 

A woman from Google asked if there was a measure of success of mentoring and how mentoring improved or led to the viability of a community.  James pointed out that they do some of this for the Linux kernel via the Linux kernel summit.  Dan pointed out that companies don't measure code contributions as much sa effectiveness.  In IBM's view, if participation in a community led to other people contributing code to address IBM's customer needs.  That, in fact, was more important than measure patches which may have no bearing on value.  James pointed out that no real kernel maintainer appears to have a manager which measures based on that level of effectiveness.  Jono points out that measuring for the point of measuring is of course pointless.  James pointed out that many people are motivated simply to get a patch into the kernel.

And with that, the time expired.  Jim Zemlin wrapped up the session by pointing out that the Linux community is an excellent example of the success of a development community.  And, introduced Al Gillen from IDC who will provide some measures of the success of Linux in the market place.