Tag Archives: community management

My Mozilla Summit 2010 Talk: Making the Army of Awesome more Awesome

2 Replies

This summer I had the enormous pleasure and privilege of both being at the Mozilla Summit and of being selected to give a lightening talk.

Embedded below is the talk – it’s five minutes so won’t take long to watch and is a short and updated version of my community management presentation. There are tons of people to thank for this talk, Diederik Van Liere, David Ascher and Mike Beltzner come to mind immediately, but there are many others as well. It also builds off a number of posts, including some old gems like this one and this one.

I’ve embedded a YouTube video of it, and the slide deck is a little further down.

Making the Army of Awesome more Awesome (Mozilla Summit ignite)

View more webinars by David Eaves.

Some thoughts on improving Bugzilla

60 Replies

One of the keys to making an open source project work is getting feedback from users and developers about problems (bugs) in the code or system. Mozilla (the organization behind Firefox and Thunderbird) uses Bugzilla, but organizations have developed a variety of systems for dealing with this issue. For example, many cities use 311. I’m going to talk about Bugzilla and Mozilla in this case, but I think the lessons can be applied more broadly for some of my policy geek friends.

So first, some first principles. Why does getting the system right matter? A few reasons come to mind:

  1. Engagement: For many people Bugzilla is their first contact with “the community.” We should want users to have a good experience so they feel some affinity towards us and we should want developers to have a great experience so that they want to deepen their level of participation and engagement.
  2. Efficiency: If you have the wrong or incomplete information it is hard (or impossible) to solve a problem, wasting the precious time of volunteer contributors.

I also concede that these two objectives may not always be congruent. Indeed, at times there may be trade offs between them… but I think there is a lot that can be done to improve both.

I’ve probably got more ideas than can fit (or should fit) into one post so I’m going to unload a few. I’ve got more that relate to the negotiation and empathetic approaches I talked about at the Mozilla Summit.

One additional thought. Please feel free to dump all over these. Some changes many not be as simple as I’ve assumed. Others may break or contravene important features I’m not aware of. Happy to engage people on these, please do not see them as an end point, but rather a beginning. My main goal with this first batch of suggestions was to find things that felt easier to do and so could be implemented quickly if there was interest and would help reduce transactions costs right away.

1. Simplifying Menus

First. I thought there were some simple changes that could render the interface cleaner and friendlier. It’s pretty text heavy – which is great for advanced users, but less inviting for newer users. More importantly however, we could streamline things to make it easier for people to onboard.

Take for example, the landing page of Bugzilla. It is unclear to me why “Open a new Account” should be on this page. Advanced users will know they want to file a bug, novices (who may be on the wrong site and who should be looking for support) might believe they have to open and account to get support. So why not eliminate the option altogether. You are going to get it anyways if you click on “File a bug.”

Bugzilla-landing-page

Current

Bugzilla-landing-page-v2

Proposed

In addition, I got rid of the bottom menu bar (which I don’t think is necessary on this screenƒclu given all the features were along the top as well). I also ditched the Release Notes and User Guide for Bugzilla as I had doubts about whether users were, at this point and on this screen, looking for those things)

2. Gather more information about our users (and, while I’m at it, some more simplifying)

Once you choose to file a bug you get prompted to either log in or create an account. At this point, if you want to create an account. I thought this page was hard to read with the text spanning the whole width, plus, there is some good info we could gather about users at this point (the point it feels they are mostly likely going to add to their profile).

Current

Bugzilla-registration-v2

Proposed

Couple things a like about this proposed screen.

One, if you are a lost user just looking for support we likely snag you before you fill out a bugzilla account. My feeling is the bugzilla is a scary place that most users shouldn’t end up in… we need to give people lots of opportunities to opt for support before diving in, in case that is what they really need.

Second, in this proposed version we tell people to read the bugzilla guidelines and suggest using an alternate email before they punch their email into the email field box.

In addition, we ask the user for their real name now (as opposed to relying on them to fill it out later). This nudge feels important as the more people with real names on the site, the more I think people will develop relationships with one another. Finally we ask people if English is their second language and if this is their first open source project.

Finally, with the extra data fields we can help flag users as ESL or new and thus in need of more care, patience and help as they on-ramp (see screen shots below). We could even modify the Bugzilla guidelines to inform people to provide newbies and ESL’s with appropriate respect and support.

Bugzilla-Raw1

Current

Bugzilla-New

Proposed

Proposed

I imagine that your “newbie” status would disappear either when you want (some sort of preference in your profile) or after you’ve engaged in a certain amount of activity.

3. Make life easier for users and the triage guys

Here is an idea I had talking with some of the triage guys at the Mozilla Summit.

Let’s suppose that someone submits a bug that isn’t really a bug but a support issue. I’m informed that this happens with a high degree of frequency. Would it be nice if, with a click of a mouse, the triage guys could move that bug out of Bugzilla and into a separate database (ideally this would be straight into SUMO, but I respect that this might not be easy – so just moving it to a separate database and de-cluttering bugzilla would be a great first start – the SUMO guys could then create a way to import it). My sense is that this simply requires creating a new resolution field – I’ve opted to call it “Support” but am happy to name it something else.

Current

Status-v2

Proposed

This feels like a simple fix and it would quickly move a lot of bugs that are cluttering up bugzilla… out. This is important as searches for bugs often return many results that are support oriented, making it harder to find the bugs you are actually searching for. Better still, it would get them somewhere where they could more likely help users (who are probably waiting for us to respond).

Of course, presently bugzilla will auto generate an email that looks like the first one and this isn’t going to help. So what if we did something else?

unresolved

Current

SUMO-transfer-v2

Proposed

Here is the auto-generated email I think we should be sending users whos bugs get sent to SUMO. I’ve proposed a few things.

First, if these are users who’ve submitted inappropriate bugs and who really need support, giving them a bugzilla email isn’t going to help them, they aren’t even going to know how to read it.

Second, there is an opportunity to explain to them where they should go for help – I haven’t done that explicitly enough in this email – but you get the idea

Third, when the bug gets moved to SUMO it might be possible to do a simple key word analysis of the bug and, from that, determine what are the most likely support articles they are looking for. Why don’t we send them the top 3 or 5 as hyperlinks in the email?

Fourth, if this really is a bug from a more sophisticated user, we give them a hyperlink back to bugzilla so they can make a note or comment.

What I like about this is it is customized engagement at a low cost. More importantly, it helps unclutter things while also making us more responsive and creating a better experience for users.

4. Make Bugzilla Celebrate, enhance our brand and build community

Okay, so here’s the thing that really bugs me about bugzilla. If we want to be onramping people and building community, shouldn’t we celebrate people’s successes? At the moment this is the email you get from Bugzilla when a bug you’ve submitted gets patched:

BORING! Here, at the moment of maximum joy, especially for casual or new bugzilla participants we do nothing to engage or celebrate.

This, is what I think the auto-generated bugzilla email should look like.

Congrats-v2

Yes, I agree that hard core community members probably won’t care about these types of bugs, but for more casual participants this is an opportunity to explain how open source and mozilla works (the graphic) as well as a chance to educate them. I’ve even been more explicit about this by offering links to a) explain the open web, b) learn about mozilla and open source; and c) donate to the foundation (given this is a moment of pride for many non-developer end users)

Again, I’m not overly attached to this design per se, it would just be nice to have something fun, celebratory and mozillaesque.

Okay, it is super late and I’m on an early flight tomorrow. Would love feedback on all or any of this for those who’ve made it this far. I’ll be sharing more thoughts, especially on empathetic nudges and community management in bugzilla ASAP.

Awesome Interactions: More on my Mozilla Summit 2010 Ignite Talk

3 Replies

Last week I had the distinct pleasure of being at the Mozilla Summit.

This is a gathering of about 650ish people from innumerable countries around the world to talk about Mozilla, the future of the open web, the various Mozilla products (such as Firefox and Thunderbird). As Mozilla is a distributed community of thousands of people from around the world and the summit only takes place every two years, it as one participant memorably put it, “an opportunity to engage in two years of pent up water cooler talk.”

As a follow up for the summit I’ve two things I wanted to share.

First, for those who enjoyed my Ignite talk on community management entitled Making the Army of Awesome More Awesome I’ve uploaded my slides to slideshare. (Not the most flattering picture of me giving the talk, but the only one I could find on flickr…)

I’m hoping, once the summit organizers have taken a much deserved break, to get video and audio of the presentation and I’ll create slidecast and post it to this blog.

Also, if you found the talk engaging, there is a longer version of that talk where I dive a little deeper into some of the theory I mention at the end. It is a talk David Humphrey kindly asked me to give back at FSOSS a few yeas ago called Community Management: Open Source’s Core Competency.

Second, both in my talk and during the incredible time I had speaking with a number of people in the Mozilla community I brainstormed a ton of ideas. I’m committed to documenting those and sharing them. Here’s a list of some of them, in the coming week I hope to blog on each, and ideally all of these.

1. Improve the link between Bugzilla and SUMO

2. Auto-generate help topics in the Help pull down menu

3. Ask people when they download Firefox or Thunderbird if they’ll volunteer to do bug confirmation

4. Add “Newbie” to new Bugzilla registers

5. Add “ESL” (English as a second language) to Bugzilla accounts that request it

6. Rethinking data.mozilla.org and fostering a research community

7. Segment Bugzilla submitters into groups that might be engaged differently

8. Reboot Diederik Van Liere’s jet pack add-on that predicts bug patch success

8b. Add on a crowdsourcing app to call out negative language or behaviour

9. Retool questions asked in Bugzilla to “nudge” users to better responses

10. Develop an inquire, paraphrase, acknowledge and advocate crowdsourcing identfier jet pack add on for bugzilla

11. plus more, but lets start with these…

Mozilla and leadership: Rethinking the CEO

7 Replies

Last week John Lily – CEO of Mozilla – announced he will be stepping down to take a job at Greylock, a venture capital firm. I’ve only met John twice, and both times he was generous with both his time and willingness to engage some of my thoughts and (many) questions. I know he is a huge asset to Mozilla and has done a great deal to help mature the organization.

With the Mozilla now planning a CEO succession it seems like an opportune time to raise an idea that first came to me a few months ago: Should Mozilla rename the role of CEO?

Why change the title? My interest is that the title communicate the message of Mozilla mission and its method. CEO’s are usually (although, admittedly not exclusively) associated with traditional companies, and to a lesser degree, hierarchical decision making structures. Indeed, if asked what words I were to associate with the CEO I think “authority,” “command” and “hierarchy” would be among the top to jump into my mind.

Mozilla has never been, and I hope never will be, a traditional software company. It is not profit driven but mission driven – its goal is to keep the web open in part by providing a competitive, open standards compliant web-browser. More importantly, the Mozilla models depends not on a large staff to succeed, but on a community of volunteers whose donations of time and code are coordinated by a (relatively) small staff.

So what do I think the core values the titles of Mozilla’s leadership needs to communicate? I think authority and command are definitely part of the mix. Ultimately the senior leadership of Mozilla needs to make difficult strategic and management choices, just like a CEO. But one of the things that I think makes the role so difficult (and different) is that it requires other key attributes as well, including “engagement,” “fun,” and “community.” Let’s face it, if your capacity to create software depends on a volunteer community, that community had better be fun, engaging and with – ideally – low transaction costs.

None of this, I think, is new. Mitchell Baker, Mozilla’s chairman and Lily’s predecessor, retains the title she popularly used while in her previous job: Chief Lizard Wrangler (also the name of her blog). That title says it all: Fun, community-oriented, hints at decision-making that is consultative, but still a dose of authority…

So, can we find a new title that reflects these values? I know at Mozilla solutions are prized above observations but I’ll confess I’m a little short on suggestion (I actually love Chief Lizard Wrangler and wonder if that should not be the title). Community Director (as opposed to Executive Director) has come to mind. I’m ultimately not attached to a given solution, I just believe it is important that the title be consistent with the spirit and values of the Mozilla project. I know that the leadership and staff have a lot of its plate and that this is not the most critical issue, but I wanted to put the thought out there nonetheless as symbols such as these matter, I believe especially in mission driven organizations.

Connectedness, Volleyball and Online Communities

4 Replies

I’m currently knee deep into Connected: The Surprising Power of Our Social Networks and How They Shape Our Lives by Christakis & Fowler and am thoroughly enjoying it.

One fascinating phenomenon the book explores is how emotions can spread from person to person. In other words, when you are happy you increase the odds your friends will be happy and, interestingly, that your friends’ friends will be happy. Indeed Christakis & Fowler’s research suggests that emotional states are, to a limited degree, contagious.

All this reminded me of playing competitive volleyball. I’ve always felt volleyball is one of the most psychologically difficult games to play. I’ve regularly seen fantastic teams collapse in front of vastly inferior opponents. I used to believe that the unique structure of volleyball accounted for this. The challenge is that the game pauses at the end of every point, allowing players to reflect on what happened and, more importantly, assign blame (which can often be allocated to a single individual on the team). This makes it easy for teams to start blaming a player, over-think a point, or get frustrated with one another.

As a result, even prior to reading Connected, I knew team cohesion was essential in volleyball (and, admittedly, any sport) . This is often why, between points, you’ll see volleyball teams come together and high-five or shake hands even if they lost the point. If emotions and confidence are contagious, I can now see why it is a team starts to lose a little confidence and consequently then plays a little worse causing them to lose still more confidence and then, suddenly they are in a negative rut and can’t escape.(Indeed, this peer reviewed paper showed that tactile touch among NBA players was a predictor of individual and team success)

Of course, I’ve also long believed the same is true of online (and, in particular, open source) communities. That poisonous and difficult people don’t just negatively impact the people they are in direct contact with, but also a broader group of people in the community. Moreover, because communication often takes place in comment threads the negative impact of poisonous people could potentially linger, dragging down the attitude and confidence of everyone else in the community. I’ve often thought that the consequence of negative behaviours in the online communities has been underestimated – Christakis and Fowler’s research suggests there are some more concrete ways to measure this negative impact, and to track it. Negative behaviour fosters (and possibly even attracts) still more negative behaviour, creating a downward loop and likely causing positive or constructive people to opt out, or even never join the community in the first place.

In the end, finding ways to identify, track and mitigating negative behaviour early on – before it becomes contagious – is probably highly important. This is just an issue of having people be positive, it is about creating a productive and effective space, be it in pursuit of an open source software product, or a vibrant and interesting discussion at the end of an online newspaper article.

Open Source Strategy: OpenMRS case study

4 Replies

Last week I had the pleasure of being invited to Indianapolis to give a talk at the Regenstrief Institute – an informatics and healthcare research organization – which also happens to host the founders of OpenMRS.

For those not familiar with OpenMRS (which I assume to be most of you) it is open-source, enterprise electronic medical record system platform specifically designed to respond to those actively building and managing health systems in the developing world. It’s a project I’m endlessly excited about not only because of its potential to improve healthcare in developing and emerging markets, but also because of its longer-term potential to serve as a disruptive innovator in developed markets.

Having spent a few days at Regenstrief hanging out with the OpenMRS team, here are some take aways I have regarding where they are, and where – in my mind – they should consider heading and what are some of the key places they could focus on to get there.

Current State: Exiting Stealth Mode

Paul Biondich and Andrew Arenson point me to this article about Community Source vs. Open Source which has an interesting piece on open source projects that operate in “Stealth Mode”

It is possible to find models similar to community source within the open source environment. For example, some projects opt to launch in a so called ‘stealth mode’, that is, they operate as a truly open source development from inception, but restrict marketing information about the project during the early stages. This has the effect of permitting access to anyone who cares enough to discover the project, whilst at the same time allowing the initiating members to maintain a focus on early strategic objectives, rather than community development.

OpenMRS has grown in leaps and bounds and – I would argue – has managed to stay in stealth mode (even with the help of their friends at Google summer of code). But for OpenMRS to succeed it must exit stealth mode (a transition that has already been steadily gathering steam). By being more public it can attract more resources, access a broader development community and role out more implementations for patients around the world. But to succeed I suspect that a few things need to be in place.

Core Opportunities/Challenges:

1. Develop OpenMRS as a platform to push people towards cooperating (as opposed requiring collaboration) whenever possible.

One of the smartest things Firefox did was create add-ons. The innovation of add-ons accomplished two benefits. First, it allowed those working on the trunk of the Firefox code to continue to do their work without being distracted by as many feature requests from developers who had an idea they wanted to try out. Second, it increased the number of people who could take interest in Firefox, since now you could code up your own add-on cooperatively but independently, of the rest of the project.

With OpenMRS my sense is that then entire UI is a platform that others should be able to develop or build add-on’s for. Indeed, the longer term business model that makes significant sense to me is to treat OpenMRS like WordPress or Drupal. The underlying code is managed by a core open source community but installation, customization, skinning, widgets, etc… is done by a mix of actors from amateurs, to independent hackers and freelancers to larger design/dev organizations. The local business opportunities to support OpenMRS and, in short, create an IT industry in the developing world, are enormous.

2. Structural Change(s)

One consequence of treating OpenMRS as a platform is that the project needs to be very clear about what is “core” versus what is platform. My sense is that members of the Mozilla team does not spend a lot of time hacking on add-ons (unless they have proven so instrumental they are brought into the trunk). Looking at WordPress the standard install theme is about as basic as one could expect. It would seem no one at WordPress is wasting cycles developing nice themes to roll out with the software. There is a separate (thriving) community that can do that.

As a result, my sense is that OpenMRS should ensure that its front-end developers slowly begin to operate as a separate entity. One reason for this is that if they are too close to the trunk developers they may inadvertently prevent prevent the emergence of a community that would specialize in the installing and customizing of OpenMRS. More importantly, those working on the platform and those working on the trunk may have different interests, and so allowing that tension to emerge and learning how to manage it in the open will be healthy for the long term viability of the project as more and more people do front end work and share their concerns with trunk developers.

3. Stay Flexible by Engaging in Community Management/Engagement

One of the challenges that quickly emerges when one turns a software product into an innovation platform is that the interests of those working on the product and those developing on the platform can quickly divide. One often here’s rumblings from the Drupal community about how drupal core developers often appear more interested in writing interesting/beautiful code than in making Drupal easier to use for businesses (core vs. platform!). Likewise, Firefox and Thunderbird also hear similar rumblings from add-on developers who worry about how new platforms (jetpack) might make old platforms (add-ons) obsolete. In a sense, people who build on platforms are inherently conservative. Change, even (or sometimes especially!) change that lowers barriers to entry means more work for them. They have to ensure that whatever they’ve built on top of the platform doesn’t break when the platform changes. Conversely trunk developers can become enamored with change for change’s sake – including features that offer marginal benefits but that disrupt huge ecosystems.

In my mind, managing these types of tension is essential for an open source project – particularly one involving medical records. Trunk developers will need to have A-level facilitation and engagement skills, capable of listening to platform developers and others, not be reactive or defensive, understand interests and work hard to mediate disputes – even disputes they are involved in. These inter-personal skills will be the grease that ensure the OpenMRS machine can keep innovating while understanding and serving the developer community that is building on top of it. The OpenMRS leadership will also have to take a strong lead in this area – setting expectations around how, and how quickly OpenMRS will evolve so that the developer ecosystem can plan accordingly. Clear expectations will do wonders for reducing tensions between disparate stakeholders.

4) Set the Culture in Place now

Given that OpenMRS is still emerging from Stealth mode, now is the time to imprint the culture with the DNA it will need to survive the coming growth. A clear social contract for participation, a code of community conduct and clearer mission statement that can be referenced during decisions will all be essential. I’m of course also interested in the tools we can role out that will help manage the community. Porting over to Trac the next generation of Diederik’s bug-fix predicter, along with his flame monitor, are ways to give community the influence to have a check on poor behaviour and nudge people towards making better choices in resolving disputes.

5) Create and Share Data to Foster Markets

Finally, I think there is enormous opportunity for a IT industry – primarily located in the developing world – to emerge and support OpenMRS. My sense is that OpenMRS should do everything it can to encourage and foster such an industry.

Some ideas for doing this have been inspired by my work around open data. I think it is critical that OpenMRS start asking implementations to ping them once complete – and again whenever an upgrade is complete. This type of market data – anatomized – could help the demonstrate demand for services that already exists, as well as its rate of growth. Developers in underserved counties might realize there are market niches to be filled. In addition, I suspect that all of the OpenMRS implementations that have been completed that we don’t know about represent a huge wealth of information. These are people who managed to install OpenMRS with no support and possibly – on the cheap. Understanding how they did and who was involved could yield important best practices as well as introduce us to prospective community members with a “can do” spirit and serious skills. I won’t dive into too much detail here, but needless to say, I think anonymized but aggregated data provided for free by OpenMRS could spur further innovation and market growth.

Postscript

I’m sure there is lots to debate in the above text – I may have made some faulty assumptions along the way – so this should not be read as final or authoritative, mostly a contribution to what is an ongoing discussion at OpenMRS. Mostly I’m excited about where things are and where they are going, and the tremendous potential of OpenMRS.

Making Open Source Communities (and Open Cities) More Efficient

15 Replies

My friend Diederik and I are starting to work more closely with some open source projects about how to help “open” communities (be they software projects or cities) become more efficient.

One of the claims of open source is that many eyes make all bugs shallow. However, this claim is only relevant if there is a mechanism for registering and tackling the bugs. If a thousand people point out a problem, one may find that one is overwhelmed with problems – some of which may be critical, some of which are duplicates and some of which are not problems at all, but mistakes, misunderstandings or feature requests. Indeed, in recent conversations with open source community leaders, one of the biggest challenges and time sinks in a project is sorting through bugs and identifying those that are both legitimate and “new.” Cities, particularly those with 311 systems that act similar to “bug tracking” software in open source projects, have a similar challenge. They essentially have to ensure that each new complaint is both legitimate, and geuninely “new” (and not a duplicate complaint – eg. are there 2 potholes at Broadway and 8th vs. two people have called in to complain about the same pothole).

The other month Diederik published the graph below that used bug submission data for Mozilla Firefox tracked in Bugzilla to demonstrate how, over time, bug submitters on average do become more efficient (blue line). However, what is interesting is that despite the improved average quality the variability in the efficacy of individual bug submitters remained high (red line). The graph makes it appear as though the variability increases as submitters become more experienced but this is not the case, towards the left there were simply many more bug submitters and they averaged each other out creating the illusion of less variability. As you move to the right the number of bug submitters with these levels of experience are quite few, sometimes only 1-2 per data point, so the variability simply becomes more apparent.

Consequently, the group encircled by purple oval are very experienced and yet continue to submit bugs the community ultimately chooses to either ignore or deems not worth fixing. Sorting through, testing and evaluating these bugs suck up precious time and resource.

We are presently looking at more data to assess if we can come up with a profile for what makes for a bug submitter who falls into this group (as opposed to be “average” or exceedingly effective). If one could screen for such bug submitters, then a community might be able to better educate them and/or provide more effective tools and thus improve their performance. In more radical cases – if the net cost of their participation was too great – one could even screen them out of the bug submission process. If one could improve the performance of this purple oval group by even 25% there would be a significant improvement in the average (blue line). We are looking forward to talk and share more about this in the near future.

As a secondary point, I feel it is important to note that we are still in the early days of open source development model. My sense is there are still improvements – largely through more effective community management – that can yield dramatic (as opposed to incremental) boosts in productivity for open source projects. This separates them again from proprietary models which – as far as I can tell – can at the moment at best hope for incremental improvements in productivity. Thus, for those evaluating the costs of open versus closed processes, it might be worth considering the fact that the two approaches may be (and, in my estimation, are) evolving at very different rates.

(If someone from a city government is reading this and you have data regarding 311 reports – we would be interested in analyzing your data to see if similar results bear out – plus it may enable us to help you manage you call volume more effectively.)

SXSWi Panel: Fostering Collaborative Open Source Communities

Yesterday I saw this academic journal article and was reminded about how an individuals behaviour can negatively impact and groups productivity. In his article “Overlooked but not untouched: How incivility reduces onlookers’ performance on routine and creative tasks.” in the Organizational Behavior and Human Decision Processes (109: 29-44) Amir Erez describes how even just witnessing rudeness resulted in diminished creativity, increased one’s own negative behaviour, damaged productivity and short term memory.

This is a perfect example of why I believe we need open source communities to foster collaborative cultures that nudge people to engage in positive and constructive ways.

In pursuit of talking about this more, I’ve put together a presentation proposal for SXSWi in which I’d like to build on my FSOSS presentation (which has logged over 15000 views since going up on SlideShare.net two years ago) on how the skills and tools from the field of negotiation and collaboration can help improve community management and productivity in open source communities. If this sounds at all interesting to you, I’m hoping that you’ll consider going to the SXSWi Panel Picker website and voting for this panel.

Since FSOSS 2008 I’ve done more research and work in the area and so have more examples to share out of the open source space. In addition, I’ve been working with Diederik Van Liere at the University of Toronto’s business school trying to get data around how behaviour impacts a open source community’s effectiveness.

Title:

Fostering Collaborative Open Source Communities

Description:

Community management is a core competency of open source. So what skills, tools and culture can facilitate and enable collaboration? Drawing from negotiation theory David shares what open source project participants can do to foster sustainable and effective collaborative communities where conflict is productive and not soul-sucking or time consuming.

Questions Answered:

  1. What skills does an open source project leader need
  2. How to a minimize destructive conversations?
  3. How can I encourage participation in my open source project?
  4. How do enable members of my open source community to work together better?
  5. What is negotiation theory?
  6. Someone is being a troll in my discussion group. What do I do?
  7. How can I attract more users to my open source project?
  8. How can I make my open project contributors more effective?
  9. I don’t like arguing with people, what should I do?
  10. I think I may be abrasive, what should do?

Category:

Community / Online Community, Open Source, Self-Help /Self-Improvement, User Experience

Remixing Angie Byron to create the next Million Mozillians

27 Replies

As I’ve noted in some previous posts, Angie Byron gave a presentation on getting more women in open source. My feeling is that the systems, culture and tools we put in place to attract more women into open source are the same systems we need to attract lots of new people into open source. Something that would benefit individual open source projects and the open source community in general.

One of the key things Angie talks about is that we often have a specific view of who can participate in open source – something she identifies as a sweet spot of skills and passion:

I suspect that, at the moment, this is broadly true. As a model however, it has limited scale. Not everyone can “do” everything about the problems they care about in an open source project. Worse still, since Open Source participants (rightly) care more about action than talk, those who are interested but insufficiently equipped often get marginalized. This means either a) potential supporters are turned off or away or b) these people become raging uglies who post unhelpful rants and talk about open source projects being “unsupportive” or “unresponsive.” The former is a loss to the projects, the second is a drain.

As I think about Canada25 and some of the work I’ve done helping open source projects manage their community, it isn’t so much that we want to find and more effectively tap into that sweet spot, it’s that we should be trying to figure out how to manage the open source process so we don’t have to exclusively rely on those in the sweet spot.

That begins with having a better model of what current contributors look like. To that end I’ve remixed Angie’s slide and tried to make it more to what I think “scale” would look like.

Women in Open Source remixed slide 4The fact is, there are A LOT more people who see of problem/bug/missing feature in open source than those who want to see it fixed or can do something about it. Indeed, for those of us who care about Mozilla, if we want to find the next Million Mozillians, this red group is a good (but not the only) place to start.

The real question is, can we break down problems so rather than relying on (a relatively few) key people we can rely on a process instead? This is, in theory, what tools like Bugzilla are supposed to help us do and what, I suspect, many OS projects spend a lot of time thinking about.

Women in Open Source remixed Slide 5

It would be interesting to try to map all the tools that allow us to move ideas and issues from “that’s dumb” to “I want to see it fixed” to “I can do something about it.” How are the people in each phase connected, how can they exchange information and how can they influence one another. More importantly, can we find ways to break the problem down to at least cooperate and possibly even collaborate on these issues.

But the larger issue – and this is where I think it matters to finding the next Million Mozillians, is how do we migrate people up the food chain. How do we shift people from “That’s Dumb” to saying “I want to see it fixed” and from “I want to see it fixed” to “I can do something about it!” This is where I think effective community management has the most to offer – developing a tools, a culture and environment that are encouraging, supportive and still effective and efficient.

Women in Open Source remixed Slide 6

Part of this has to do with finding it easier to accommodate people into a broader set of roles. As Angie Byron (and others) point out, participation isn’t just about coding: It’s about donations, advocacy, documentation, marketing, user support, testing, translations, graphic design, event coordination, bug reports and feature requests, issue queue “farming”, usability, project management, and (among other things) coding. But it is also about nurturing those who have the skills but may sit on the periphery or outside the sweet spot altogether – getting them comfortable with the project, the community and the processes. Often open source projects have a rough and tumble approach to newbies, I’m not sure that this is the best path to growth.

If a given open source community (and I’d argue the open source community writ large) wants to grow, fighting over coders in the sweet spot will be one approach, but its sustainability (and growth) may be more limited. However, figuring out how to task up the other activities so your coders can focus more and more narrowly on just coding may be another, and ultimately more effective route to success. As Angie points out, creating more effective tools is one part of getting there – but it is only one part. Figuring out the culture and soft skills that will get you there is the other.

Women in Open Source and Florida's Bohemian Index

Just a quick somewhat brief follow up to yesterday’s post on women in open source.

I got lots of great feedback and comments for which I’m grateful and wanted to say one or two things.

First, I recognize the title to the post, particularly the “Canary in a Coal Mine” was far from perfect. The exclusion of women from Open Source is not – as some might read the title – an existential threat to open source. OS communities will not collapse or fail if more women are not included (the broader IT industry seems to continue, for better for worse despite a poor male to female ratio). The point is that growth will, however, be limited. Moreover the success of OS communities  – defined in terms of an active and engaged community, one whose members treat each other well and where differences and disagreements are resolved respectfully and effectively – might also be limited.

Actually I’d go further – Richard Florida found a positive correlation between gay household and regional (especially tech) economic development among cities. This quote is from one of his academic papers on the subject:

Florida and Gates (2001) found a positive association between concentrations of gay households and regional development. This tolerance or open culture premium acts on the demand side by reducing barriers to entry for human capital; increasing the efficiencies of human capital externalities and knowledge spillovers; promoting self-expression and new idea generation; and facilitating entrepreneurial mobilization of resources, thus acting on regional income and real estate prices.

The same hypothesis could could hold true for open source communities with regard to women.  Gay men in America and women in tech are both (sadly still) marginalized groups. As such, women are the canary in the coal mine in that the more women you find in an open source community – the more likely that community is tolerant and open to new ideas and self-expression.  In short, the number of women participants is probably a pretty one good metric of the community’s health.

Second, I think the stats around the post are quite interesting. So far:

Page hits: 600+

Feedburner “reach:” 2379

Tweets: 7 from women, 1 from an aggregator

Comments: 10 comments from 7 people (not including mine). All from women

2 emails: both from men

In short, no men participated publicly the the post. My inclination is not to believe that men in open source don’t see this as an issue (I’m sure some don’t, but I know many do), but I do suspect that many don’t feel like it is safe to talk about. That’s a problem in of itself. (Alternatively, and I accept this as a very real possibility, but my blog may not be popular enough to gain attention – or that people haven’t had a ton of time to respond).

As the author it is important to me that nothing in yesterday’s post lead open source participants to believe (or feel accused of) deliberately excluding women. However, I know that reading it, that accusation can feel like it is (implicitly) there anyway. A key to success in communicating around difficult subjects is to separate impact from intent. Open source communities, and the men who participate within them may not be trying to exclude women or other groups (intent). But that doesn’t mean women aren’t being or shouldn’t feel, excluded (impact). The key is for a community to acknowledge and accept that it can be having an impact without that intent – and the solution is to get really intentional about the skills, tools and culture of the community to change the impact.

It was important to me that yesterday’s post resonate with the women who read it AND that men involved in open source read the post without feeling accused of being sexist or part of a sexist community. The goal is to generate discussion on how we can change the impact since, given most of the people I know in OS, the intent is already there.