“Teach a man to fish and you’ll feed him for a lifetime.

Teach a man to teach fishing, and you won’t have to go around teaching fishing for the rest of your life.”

… okay, it’s a little less catchy than the original.  And, honestly, we already have so many overfishing problems in the world that this probably isn’t the right analogy.  But you know what I mean!

We’re at an interesting point in the Mozilla Foundation.  We’re in the middle of our Summer Code Party, and we’re starting to look at the roadmap for our tools like Thimble.  And, of course, there’s a million things we want to do with it.  From enabling javascript, to internationalization, to badges, to a gazillion other things, there’s a lot we want to do, and easily enough work for several developer-years.

There’s sort of two solutions to this problem.  One is to scale our engineering efforts: become a software company with tons of developers, engineering managers to manage them, product teams, UI teams, managers for those teams, etc.

The other solution, and one that feels more Mozillaey to me, is to use the developers we do have to build tools / processes / etc. that empower everyone else in the world to do the fishing.

For example, one of our top feature requests is to create a simpler version of MDN (the definitions we link to in Thimble) that would make sense to novices.  This seems like a great opportunity to create a quick interface to allow anyone out there to provide/edit the definitions.  If we open it up to the world, then not only can it evolve at the speed of the web, but we can also get things like localization.

There are often lots of folks who want to help and participate, but like all of us, they don’t want to do it if it’s going to be a lot of work to just get started.  These things have to be easy, designed processes.  That’s not to say that they have to be complicated.

Compare and contrast two tech support systems.

1) A form that you can fill out on a webpage somewhere to ask questions.  It emails an internal list, and someone there answers the question.

2) A twitter hashtag where you can ask questions.  Suddenly not only can internal people answer the questions, but maybe you know the answer too.

It’s a good example of how designing for community participation doesn’t necessarily mean creating a complicated tool or program.  It just means including participation as a first-order design principle.

There’s absolutely no way that the Mozilla Foundation can personally host events to teach web making to the world.  But I do think that if we do this right, we can build a movement that others build on, and make their own.

We can teach people to teach people to teach people to fish.  And soon there will be no fish left in the sea.  (But in this case, that means “everyone learns web making” so it’s not quite so ecological disastery.  … I hope.)

What do you think?