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.
The 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.
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.
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.
eaves.ca 
Pingback: Glyn Moody (glynmoody) 's status on Tuesday, 28-Jul-09 19:29:57 UTC - Identi.ca
Hi!I think you are missing a number of different angles in your article:1) Someone does it for their resume. These contributors drop in and then drop out, but often they are good for a patch or two.2) Just for fun. There are a lot of people who do this because it is fun. They like code, and they like the community they become involved in. Community is a powerful motivator.3) Those who are paid. There are a lot of folks who get paid to do open source. They contribute a lot of effort, and put their energy into it. 4)…There are more examples out there for the “why” behind open source, your graphs paint a very limited picture, and one that is not overall accurate. Cheers, -Brian
Pingback: Emma Jane (emmajanedotnet) 's status on Tuesday, 28-Jul-09 23:26:00 UTC - Identi.ca
Hi Brian – thank you for the comment. I agree that there are lots of reasons why people participate in open source and this post and the model cover any of them. Any model is going to be incomplete. It will diminish or under describe some attributes of a system and accentuate others it's author believes are more salient. For the post that I've written above I not sure that the precise reason why people participate is relevant, it is much more about how do we create processes, tools, culture, etc… that encourages those who have an interest to maximize their participation and effectiveness.
Pingback: Matthew Davidson (freemjd) 's status on Wednesday, 29-Jul-09 01:19:58 UTC - Identi.ca
Pingback: Donna Benjamin (kattekrab) 's status on Wednesday, 29-Jul-09 01:52:32 UTC - Identi.ca
Pingback: duritong's status on Wednesday, 29-Jul-09 09:21:55 UTC - Identi.ca
I'm missing one thing here that I think is an important factor: people realizing that software is malleable, that they not just have to endure all the shortcomings of their software.When observing other people using a computer, I see how frustrated they can get at software, because they don't know how to make the software do what they want. That's going to be for one of two reasons: the software cannot do what they want (either because it's too hard or because the people who built the software haven't thought of it yet, for whatever treason), or because they can't find the UI to make it do what they want.So maybe there's an intermediate step between “that's dumb” and “I want to see that fixed”, which could be called “that could be fixed”. The new step would have everything to do with realizing that software is a product of human beings, is therefore imperfect, and may sometimes be improved by very small changes (e.g. some string changes to improve clarity).Maybe we should start by inviting feedback. Maybe Firefox should sport a help menu item saying 'Tell us what sucks'. Start by providing people with an outlet for their frustration by asking them to think reasonably about what fixing it would entail (or even just to cool off). The first run page provides all this info on what great new features we think they now have, but it would be nice if there was also “You think Firefox could be better? Let us know how.”.
I liked the idea for “Tell us what sucks” enough to file it in Bugzilla, see https://bugzilla.mozilla.org/show_bug.cgi?id=50…. Not sure how to get it in front of the right people, though…
Pingback: Links 29/07/2009: Debian on Time-Based Releases | Boycott Novell
I'm now trying to work out what that diagram looks like for Wikipedia.
Reminds me of Angie's typing of all Drupal users a few years ago. Arrogant and wrong.That and the girl's club nonsense made me take a giant step back from the community. Hey Angie, you're a dyke living in Montreal, therefore, according the the typing of Montrealers and dykes that makes you either A) ____ B_ __+_ __ or C)_]] How would you like it?Stinking profiling behaviours.
Pingback: tending the garden › My thoughts about community management
Hi! I commented via a long twitter thread that I “disagree with putting comm mgmt between user/dev. like @webchick's ideas better.” :)To flesh that out a bit — my gut reaction to the ultimate diagram you created is that it puts community managers *between* users and developers.. This is a convenient way to demonstrate a process, but ultimately, I have to disagree with the premise behind it.I work to break down barriers between “users” and “developers”. My ideal world is one where the two overlap to a very large extent. I dislike models of open source community development which seem to promote the idea that there needs to be an intermediary. I agree that most communities require an interface — it is rarely self-evident how one goes about joining a community if you were on the outside. Many times it is an organic process — your friends invite you, or you run into someone at a conference or bar, or you have to use or work on a piece of software for work. For those who, for whatever reason, are not already on the inside, having a single point of contact (a “community manager”, or in the amusing case of the open source developer group I primarily work with – a “liaison”) can be an invaluable tool.However, I do not see that role as one that ultimately should belong to just one person. If I do my job right, eventually, people won't even come to me any more. They will go directly to the individuals inside the community they most want to connect with — because I have managed to open up our community interfaces to the point that they are self-documenting, or easily found with a few clicks on our website.Possibly, this vision is a bit unrealistic in the near term. But I'll paraphrase my friend Audrey — it's way more fun to craft your reality, than it is to passively experience it.
Pingback: 5 Ways to get to the Next Million Mozillians | eaves.ca
This is definitely over simplified, and you're missing a major piece. One, the “this is dumb” should be something like “this is dumb / I have domain expertise / I have an awesome idea”. I don't identify dumb very well, but I have lots of crazy ideas :PMost of the time, I fall into the “I want to see it fixed” camp. Luckily, I *can* do something about it — just not directly by writing code. I can do something about it by 1) convincing developers that it's a great idea and they fix it / implement it 2) raising a community groundswell that does (1) or raises funds or 3) paying someone to do it.The biggest misconception is usually around “I want to see it fixed”. It's actually something like “I want to see it fixed and I understand open source enough to understand that I *can* get it fixed”. That's the biggest gap – people don't identify with communities, they think of them as a place where free-as-in-beer “stuff” comes from.As always, I agree that enabling more people to participate is a good thing, but boiling it down to a simple Venn diagram limits the many many many ways that people can enact change.
Deleting my comment that critiqued this and other over-generalized stereotyping by Angie that led this woman to take a giant step back from the Drupal community.Awful. Just awful.
Reposting : Reminds me of Angie's typing of all Drupal users a few years ago. Arrogant and wrong.That and the girl's club nonsense made me take a giant step back from the community. Hey Angie, you're a dyke living in Montreal, therefore, according the the typing of Montrealers and dykes that makes you either A) ____ B_ __+_ __ or C)_]] How would you like it?Stinking profiling behaviours.
Angietype1000 – racial slurs and derogatory terms relating to gender and sexual orientation aren't permitted on my blog. I will remove any comment that includes them. In addition, your comment wasn't related to the post, but appears to relate to a personal dislike you have toward Angie Byron – you can critique the post, but personal attacks that are at best tangentially related to the substance of the post are frowned upon here at eaves.ca.
I find it enormously offensive to be referred to a 'chick' in a professional context, particularly one dominated by men, but hey, there it is. dyke for chick – seems fair to me. Stereotype for stereotype for illustrative purposes. No one like to be typed or reduced to someone's simplified 'categories'.
Hey and see Angie's own site — http://angelabyron.com/presentations/women-in-o… 'dyke it' The site she herself references dykeit.ca ranks pretty high in that posting. No words minced there and it's no reference to Dutch approaches to flooding.And it's not Angie I'm attacking — it's her ongoing practice in stereotyping users in the Drupal community. You're presenting it here as something worthy to remix. I'm providing honest criticism. The word shouldn't be offensive to Angie given her own use of it, but I do hope the sliced up stereotyping knocked some sense her way. The arbitrary symbolic punctuation marks — that makes you either a) ___ b_ __+ or c)_]] was intended as pure nonsense
Posting again – this time to meet the eaves.ca censorship review panel standards: Reminds me of Angie's typing of all Drupal users a few years ago. Arrogant and wrong.That and the girl's club nonsense made me take a giant step back from the community. Hey Angie, you're a bleep living in Bhleeeep, therefore, according the the typing of Bhleeeepers and bleeps that makes you either A) ____ B_ __+_ __ or C)_]] How would you like it?Stinking profiling behaviours.
djc – totally agree. In talking to my OS friends one of the big challenges is that sometimes “bugs” get submitted that aren't bugs – but rather the user was not able to find a feature where they expected it or perform its function as they thought they should. Finding a way to track this (which is often done through support) is key.
David – let me know if you get a diagram up. Would be great to see.
I've given it occasional thought since then, not come up with anything :-)The intersection point – marked “These people power open source” – is pretty much anyone who knows something and can write it in a coherent sentence. But social structures have evolved to keep it from turning into complete rubbish. Sometimes way too much structure. This means there are all manner of social mechanisms to repel clueless n00bs, since there aren't the technical or thinking-style barriers there are to coding. And many of these are (IMO) inappropriately strong.How not to bite the n00bs is a perennial topic on Wikipedia, and I'm currently trying to get some old hands to edit as IPs so they can see how n00b-biting we actually are in practice. Results are disheartening so far.
And, further: some open source projects do similar things to deal with the “Linus doesn't scale” problem when they attract large volumes of people who can at least write code to a minimal degree. A high quality requirement on code is ony the start – there's getting attention to your code, jumping through the right hoops, dealing with obnoxious-nerd-stereotype personalities (there's a reason it's a stereotype), etc.That is: our problem is not getting people into that intersection point – it's what happens to people in that intersection point, how to keep them from flooding you and how to make sure those mechanisms aren't in fact damaging your project.I think I might write a blog post on the concept …
Pingback: Who Can Participate in Open Source…10.17.09 « The Proverbial Lone Wolf Librarian's Weblog