Tag Archives: tools

Building community around Webmaker tools

How do we grow a community of contributors and architecture of participation around Mozilla Webmaker tools?

This post is a synthesis of ideas collectively brainstormed by the Webmaker community in Tuesday’s call. It’s part two of a discussion Mark Surman began with his “Tools for Webmakers” post. The ideas here aren’t mine — they’re everybody’s. :)

Contribution is the goal

We’ve said we want to make contribution the metric that defines all our work. That includes building Webmaker tools like Popcorn, Thimble and the X-Ray Goggles. Popcorn already has a growing community of developers contributing code. OpenNews is creating and sharing great code as well. And Thimble is, of course, just out of the gate, with a question around when and how best to build an architecture of participation.

So as we think about our plan for the rest of year and into 2012, where do we go from here?

Four keys to involving contributors:

  • On-ramps.
  • Tasks. Calls to action.
  • Documentation. Training
  • Celebration. Kudos.

What kinds of contribution are we seeking?  

What kinds of contributors do we want to work with and get to know better, over the next 6 – 12 months? We want to grow a community of contributors around building Webmaker tools in particular. And of course also plant seeds and build a community around webmaking in general, with Webmaker as a big tent for lots of different people and groups.

Where do we need to build better on-ramps for participation?

  • Code. We know there’s a small group that want to contribute to the “core” library — of a similar order of magnitude as people who submit patches to Firefox, for example.
    • Make it easier to submit. Build systems that let contributors submit this type of code without our review or evaluation. Via plug-ins, for example? or something comparable to addons.mozilla.org?
    • Avoid bottlenecks. We can easily become a bottleneck to our developer contributors. For example, if they need to conform to our style guide, or review a patch while we’re in the midst of an important release. More and better “remix / fork this project” options?
  • Templates.  Easy ways for people to create and share their own Thimble template, Popcorn template, or Webmaker.org project. Without less of us getting in the way or be in the middle.
    • One idea: provide easier ways to turn your Popcorn or Thimble project into a template. Like a “save as template” option in the Popcorn and Thimble apps. That way, you could use the Popcorn “Newscast” template, for example, to turn it into a “Call to Action” video for your campaign — then save it as a “Call to Action” template other people could use the same way.
  • Localization. Translation and localization. Lots of requests for this. Many instructors are already doing it, and building curriculum around our tools. Hackasaurus has already been translated into several languages. How do we build on that for new tools and  Webmaker.org projects?
  • Mentors and guides. Getting others involved. On-boarding. Lightweight mentoring and recommendations for interactions, people to get to know, etc.
    • Work with ReMo here. Build and borrow from what Mozilla is already doing here and here.
  • Instructors. Educators and instructors contributing projects, ideas, and great stuff we haven’t thought of yet.
  • Stuff we haven’t thought of yet…  Anyone working to build a more web literate planet and plant seeds for webmaking.

Things we need:

  • Better documentation and HOW TOs. “Cook books.” Easy step by step instructions on how to contribute. Better FAQs. We have lots of rough and ready etherpads and raw notes — we need more polished HOW TOs for contribution.
  • Great examples. Project galleries, etc.
  • Better on-boarding. Clarifying where to go, what channels to use. Setting expectations. Friendly humans with time to help.

Avoiding the “busyness trap”

“We’re too busy to help!” This was a commonly acknowledged problem. When we’re heads down and focused on shipping and meeting the next deadline, it’s easy to feel like you’re “too busy” to be able to bring community members into the fold.  We need people to feel like we have time for them.  And that they’re  actually a priority.

“Should  we create ’20% time’ to focus just on creating systems and  documentation for more and better community contribution?”

Get involved: how do we make our current documentation better?

One place to start might be to look at our current contributor documentation for Webmaker tools. Then have you suggest ways it can be improved. Or volunteer to work on it yourself.  All of this is going to see dramatic improvements over the coming weeks and months. But let’s start by listing what we’ve got — specifically for contributing to Mozilla Webmaker tools and software.

(This list is incomplete — please help flesh it out in the comments to this post and I’ll update.)

Can Mozilla make tools that teach the web to the world?

Each week, mind-blowing guest speakers join our Mozilla Webmaker Community calls for your questions, rabble-rousing and debate.

Audrey Watters is a prolific education technology writer, researcher and “recovering academic.” She recently kicked off a fascinating research project for Mozilla, aimed at answering:

What’s the best way to teach web-building to anyone? For example, should Mozilla develop a tool to help the world learn HTML5?

Audrey has been asking educators and ed tech developers what they think Mozilla’s role should be, at an educational, philosophical and technological level.

Without exception, everyone I talked to identified a dire need to improve web literacy. Whether it was elementary school teachers, college professors, hobbyists or entrepreneurs, everyone talked about a huge gap in our collective knowledge base around how the web works…. There’s still this sense of the internet as a series of tubes, and the web as a series of documents you can deliver through those tubes. –Audrey Watters

Some key questions and takeaways from the discussion:

  • Learners want to solve real problems and make real stuff. Not feel like beginners/outsiders.
  • There’s a lot of resistance to building a tool that’s de-contextualized or separate from the “real” web.
  • Learners need to make something quickly. With a takeaway that’s personally meaningful to them.


  • What do we really need to build? A community or a curriculum? A product or a process?
  • How can we learn from the successful past examples? Hypercard was arguably one of the most popular, user-oriented entry-level programming tools ever — even though real programmers hated it. Hobbyists and amateurs liked it. The professionals didn’t.

Mozilla’s David Ascher dug into the Hypercard analogy:

What made Hypercard powerful is that normal people were able to use it build really useful things…. The holy grail is something that doesn’t require people to learn the entire stack that “real developers” use, but at the same time, has real utility on a day to day basis. –David Ascher

MIT's "Scratch"

Mark Surman tried to tease out the balance of giving learners access to “real” code — not toys — while still lowering the barriers to entry, providing scaffolding, or useful constraints that help you to make something meaningful quickly:

The difference between then and today is: we now have a nearly universal platform people can use to consume, create and build: the web. We want to make tools that help people make stuff on the web. They may be scaffolded or supported, but what comes out is still the web.

This is the difference between what we’re trying to build versus Hypercard, Scratch, etc. There may be constraints that make it easier, but what comes out is still “real” code, the real web. –Mark Surman

Stay tuned for some further upcoming fireside chats with Audrey. In the mean time: