Encouraging contributors to open source website development
Mozilla, like any good open source project, is a community. 25% of contributions to Mozilla Core, Firefox, Thunderbird, and other products come from the community rather than employees. We, i.e. Mozilla Webdev, want more community web developers to contribute to Mozilla websites. Here are community contribution stats for some Mozilla websites:
- SUMO
github: kitsune
ADV*: 357k
community contributors: 0† - AMO
github: zamboni
ADV*: 736k
community contributors: 3-4† - Socorro
github: socorro
ADV*: ?
community contributors: 1-2† - MDN
github: kuma
ADV*: 56k
community contributors: 4
* Average Daily Visitors
† Guesstimated figures - looked at commit logs and our LDAP phonebook; open to corrections
tofumatt wrote a good post about how we're starting to use vagrant and puppet to give developers easier access to working on Mozilla Webdev sites. lmorchard has a passion for this idea, and he's been extremely patient with all my troubles and questions about Vagrant and Puppet as I've tried to jump on the bandwagon of putting clouds in boxes. I don't want to discredit their work and opinions, but let me offer my own.
I am slow and make mistakes
Instructions for humans are nowhere near as good as instructions for computers. Humans make mistakes, misunderstand, and are generally not as fast as computers when doing this kind of thing.
- tofumatt
Amen to that. If you read some choice excerpts from our #mdn chat log, you'll see how slow I am (and how patient lmorchard is) re: vagrant. Even though I'm slow, I presumably have more "sysadmin" experience than the oft-cited hypothetical design contributor just trying to make a CSS fix, and yet vagrant and puppet make me cringe. So far, vagrant and puppet have only introduced MORE setup pain - and not the regular MySQL setup pain that I (and yes, even designers) have done dozens of times already.
Making boxes put boxes into clouds for your boxes
I've also started playing with Puppet by itself, to build plain-vanilla VM appliances and to spin up cloud servers on Amazon EC2 and Rackspace Cloud Servers. It's going pretty well, and it's conceivable we could do without Vagrant to script the build of downloadable VM appliances and to spin up disposable cloud servers.
- lmorchard
lmorchard is spot on - maybe because he's tired of dragging my slow brain thru vagrant and puppet. Our CI machine should generate vm images with 1-button deploy to Rackspace or Amazon. I think this idea of using VM's to encourage community contribution to website projects is an all-or-nothing deal. If it doesn't work 100%, it's worse than failure. If a community contributor runs into problems with vagrant or puppet, it's much worse than if they run into problems with MySQL or pip. At least there's a bunch of established resources to debug MySQL - I couldn't find much debugging resources for vagrant, besides lmorchard.
At SourceForge we had this kind of "ideal" setup for years. The Service Operations Group at SourceForge maintains sandbox servers with an admin dashboard for creating, managing, and destroying per-developer sandbox vm's that run instances of SourceForge.net. (Though sadly it's behind corporate LDAP - only given to employees) I don't know if/how that model could scale from a single site to dozens of sites all with different moving parts. And there are big latency issues developing on a remote vm. Still, it's exactly what we would want for that elusive CSS designer who wants to fix Mozilla sites without setting one up. She clicks "Create MDN Sandbox" and gets an email containing the domain and access credentials to start editing code on her sandbox. Beautiful.
The virtual machine is us
The web is no longer just linking information ... the web is linking people. People sharing, trading, and collaborating.
In all this technology, we sometimes lose track of the people. I don't want to abandon the idea of using virtual machines to encourage community contribution; the SourceForge sandbox model is, for me, the ideal system for enabling easy contributions from casual community developers. I'll join work for something similar at Mozilla.
I do want to highlight an additional on-ramp for getting community developers involved with Mozilla websites - Mozilla webdev's should get involved with our developer communities!
A couple weeks ago at our Tulsa Web Devs coworking day, Buddy and I were talking about Mozilla and he asked how he can get a job at Mozilla. I said Mozilla really likes looking at your open-source code, and also likes hiring community contributors. He asked how he should become a contributor. The easy answer is go to the Get Involved with Mozilla page, but since I was working on MDN that moment, I showed him the kuma repository I was working on. He forked it and went thru the "menial and often fragile setup" in our installation.rst; I fielded his questions as he went.
It was incredibly valuable - he filed a kuma setup and installation bug and made the appropriate fixes. Then he went on to fix an easy 1-liner bug, and got comfortable enough to do a significant bug involving cron, urllib, and json to generate a humans.txt file for MDN - which now includes him as a community contributor!
Of course, we can't spend all our time recruiting and mentoring community developers to do our work for us. [Or can we? ;) ] And Buddy is an exception in his level of commitment to contribute. So, yes we should reach out to those developers looking to make a casual CSS fix without wanting to set up a whole website environment (though we've received those 1-line CSS commits into MDN even without vm's). That's a good reason to pursue turn-key VM's.
But if you're at a conference or an event and someone asks you how to get involved with or fix a bug on Mozilla websites, don't just send them to a page or a virtual machine - pull up a chair and work with the real human sitting next to you.
Buddy Lindsey
2011-10-11 20:40:55 -0500
