Volunteer-powered product development?

Standard

Over the last few weeks, I’ve had the pleasure of working with the small-but-growing team that’s building the software offerings that are part of the Webmaker effort.  If you don’t know about Webmaker, you should — go check out the website, and Mark Surman’s blog for more details and an inside view about why Mozilla’s doing it.  The really short version is that one of the major initiatives Mozilla is engaging on in 2012, apart from some of the already incredibly ambitious projects that you may know about (Firefox, Firefox for Android, Firefox Mobile OS, Identity, Apps, etc.!), is to teach the world that the web is not just something to consume, but something that everyone can help create.  In Mitchell Baker’s words:

“Mozillians are people who make things. Moving people from consumption to creation is Mozilla’s goal.”

Now, Mitchell’s words often inspire me (she’s probably the biggest reason I joined Mozilla full time), but this phrase in particular has been bouncing around in my head for weeks.  It’s also one that resonates deeply with many people I talk to, regardless of their degree of familiarity with the web, technology, Mozilla, open source, etc.

Now, the premise of the Webmaking software offering is both incredibly exciting and so ambitious as to be scary.  We want to reach large but diverse populations and find ways to make creating on the web both compelling for them, and fun/productive.  That means that we need both specialized tools, specialized content, and deep connections with whole new populations of Mozillians who can join Mozilla to build these offerings, bringing their passion, skills, knowledge, connections, etc.  We’ve already got great start in a few beacheads: kids/tweens, filmmakers, newsrooms to name a few.  There are many more on the roadmap.

Each of these slices of webmakers will require specific content, and likely tooling, which we think of as a “product.”  As an example, Thimble is a combination of a code editor (a tool) and learning projects (content) developed in partnership with a bunch of great organizations, aimed at giving people who don’t know anything about the web the first bit of a clue, and the first bit of a sense of agency over the web. It’s an early effort, that we built really quickly, but it’s showing a lot of promise.

Initial approach

We built Thimble v1 “the easy way” — a dedicated designer, a dedicated product manager, and a dedicated engineering team, working full-time over a few weeks, coordinating with professionals who themselves had well-defined roles and responsibilities.  It wasn’t really easy, but it was familiar territory for most of us.  We knew what to expect of each other, we could rely on the traditions of both open source projects for the “code”, and product development for the integration of the code into an overall “consumer experience” (although the word consumer is particularly ironic in this context). 

I don’t think we can expect to keep this approach and scale the way the Webmaking project deserves to. (Michelle Levesque thinks so too!).

Now, one might think that that’s what Open Source projects do, but I think in fact very few open source projects are run as products.  In particular, in my experience, a good product team has learned that code is only part of the equation — design, project management, writing, engagement, etc. are equally important, for which there is no equivalent to the code open source culture.  As an example, good designers, as a result of decades of abuse by clients, typically refuse volunteer work. There is no global culture around any of the non-coding skills (with a few notable exceptions, such as QA and localization, and most interestingly, the legal profession, who has incorporated pro bono work into its professional culture).  Now, Mozilla as a whole has been tackling all of these issues for years to support the main products (Firefox in particular), but even then we have not yet figured out how to gather volunteer contributions in many parts of the workflow.

I’m hoping that within the Webmaking effort, which I think is so compelling to so many non-engineers, we have another opportunity to refine our approach.  I used the title “volunteer-powered” rather than “open source” in the title because I think that while open source has a lot of lessons to bring in, it also has a bunch of antipatterns.  Forcing non-developers to think or act like developers isn’t the answer.

Question!

Here’s my question for the day: are there collaborative models of work in non-engineering disciplines where people have developed ways of working that I should be reading about or talking to people about? 

To make it more precise and hopefully a bit controversial: I fear that a lot of the tradition of “collective action” has its roots in cultural norms around equality, fairness, and making people feel good about their contributions ahead of all other values.  And as a result, in my experience at least, a lot of volunteer groups for example end up very pleasant and “nice” but lacking the urgency, the drive, the decisiveness, the ambition to kick ass in the market that turns ideas into shipping code that users love.

How can we combine the rapid pace, deliberate action, role assignments of a product team, and the openness to volunteer and part-time contributions of open source?

4 thoughts on “Volunteer-powered product development?

  1. “very few open source projects are run as products… (and the rest of that paragraph)”

    Wow, you really resonate with me on that one! As I’ve been trying to work with a group of people on the future of Thunderbird, I am amazed at how little understanding and appreciation there is of product management and other non-coding disciplines around the project. I don’t have an answer – but I am sure interested in the question!

    Coming from a business background, I keep wondering if we could penetrate the pay firewall as part of the answer. That is, can we generate income as a project/product,share that income in some way with our team of non-employees, and use that partly as a way of enforcing product management discipline?

  2. Participation and contribution is definitely a tricky subject in non open source, non coding communities. I think some people have an overarching desire to participate, but we don’t make it easy for them to understand that their ability to, say, clean up images is actually something we need. The idea of open isn’t as widespread as we like to think. We need to engage there.

    I also think that it isn’t entirely clear that we want to establish a strong feedback loop. For example, I recently remembered reached out to a huge organization that totally <3s us – they are running events with our content, evangelizing for our work, yet they weren't telling us about it. We had to find out for ourselves and reach out, and I have to wonder why. It seems like we need to make it more clear that we have a feedback loop.

    To the controversial point – I agree, and we are perpetrators of the nice factor! But for volunteer contributions to reach that urgency, volunteers kind of have to feel like they matter, like without their contributions we're sunk, don't they?

    I wrote the following post before I started working for Mozilla. Upon reread, I find that I still agree with myself, maybe there's a note in there (or two?) that will help establish a model?

    Friendly Tips for Keeping your Contributors: http://www.zythepsary.com/techie/friendly-tips-for-keeping-your-contributors/

    Also, I wonder if giving participation some fun added value might help. Game Mechanics and Participation: http://www.zythepsary.com/techie/game-mechanics-and-participation/

    Great post, by the way :)

  3. Great post. One of the things your notion of “volunteer-driven ass-kicking” reminds me of is actually the endgame in World of Warcraft: it’s entirely volunteer-driven, and there are all kinds of raiding guilds out there, but the most humane and successful ones manage to really kick ass without requiring their members to disown their real-world friends/family. Granted, they are working through an experience that was specifically *designed* for collaboration, which is very different from building a thing in the real world, but there’s still a lot of creative thinking involved.

    Would defining an extensibility architecture be one way of solving this problem? Browser extensions and personas/themes, for instance, allow anyone to “contribute” to a browser without any kind of negotiation, thereby allowing for all kinds of sub-communities to form, from pleasant/nice ones to really ambitious product-focused ones. Would similar “points of extensibility” in Thimble effectively allow the contributor base to scale massively? Or am I missing your point?

  4. Hey David,

    I really like this post; especially the point you make about reaching large but diverse populations. The somewhat common idea that there might be some homogeneous group for which any teaching/learning effort is perfect for misses the point of interest driven learning, as well as the sense of individual agency.

    And while I agree that open source projects rarely run as products, and I could not agree more that a good product team is composed of many different disciplines and variables—not just coding—I disagree that other aspects of the team don’t have associated cultures. The design profession actually is quite well known for their pro bono work: indeed, I’d suggest that large design firms regularly engage in pro bono and prosocial work. IDEO and frog design spring immediately to mind. And of course, a variety of independent, professional designers do “volunteer” work on a regular basis.

    I mention this specifically as someone who has worked for many years in the design industry and therefore as someone who recognizes the difficulty of asking creatives to do what might be considered work on “spec.” Work on spec is anathema to just about any established designer because it asks for your time and experience without any guarantee of remuneration or even recognition.

    Now, because Mozilla is a non-profit, I have a hard time thinking of the work we do as playing into work on spec, but rather as another form of pro bono or volunteer work. I don’t believe this to be simply semantics, either. The role we’re playing here is nearly entirely altruistic: we want to help people recognize and achieve some of their potential through code. If we can clearly communicate the specific needs of our teams and accurately represent the prosocial aspects of our endeavor, it may help to galvanize the non-coder folks (i.e., the rest of the world) into specific action.

    And yes, “volunteer-powered” resonates precisely because of the agency that it suggests. We need more rethinking/re-engineering of our asks along those lines.

Comments are closed.