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.