Virtual Machines and Real Humans

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

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

Clouds and 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.

Virtual Machines and Real Humans / groovecoder by groovecoder is licensed under a Creative Commons Attribution-ShareAlike CC BY-SA
  1. Great post and breakdown. Also I wouldn’t say I was an exception on the commitment level. I just hate having problems I can’t solve, especially when it is something as “trivial” as setting up an application, I call it stubbornness.

    I have mentioned to you I think in the long run it might be time better spent to spend a few minutes every so often to make sure installation instructions still work over spending hours and hours and hours getting some automated VM up and running. The risk reward scenario, as you point out, is just too high and time consuming.

    Also, as you point out in another post, getting started is easier on potential devs, after initial setup, when it is local. I have kuma installed locally and not in a VM so all I have to do is cd my terminal over and I am ready to start testing. However, if i was using a VM i would have to boot it up and spend a lot of time waiting just to get started. By the time I am ready to start coding I might be out of motivation to start.

    It is a fun discussion to say the least. Community contribution and interaction has always been an interesting subject to discuss and problem to crack. I am curios to see how well Mozilla can crack this particular nut.

  2. Great post. Very interesting to hear how you helped Buddy get started and then to see what he went on to do once he got familiar with things.

    I also like this line:

    “Of course, we can’t spend all our time recruiting and mentoring community developers to do our work for us.”

    I think we can find a good balance between doing everything ourselves and spending all of our time mentoring.

    Without having a good balance, it seems pretty clear that it can be very hard for new people to get involved.

    As you point out above, there are few webdev contributors that aren’t employees, but we have a lot of web developers expressing interest in getting involved. Mentoring seems to be one way to fix this disconnect.

    The trick with mentoring seems to be how to use the time available in the best possible way. It wouldn’t scale to try to mentor everyone who expressed interest so who do you mentor, what are good projects to start with…

    David

  3. David, you have a lot more history in Mozilla than I do – do the other product areas of Mozilla (Firefox, Thunderbird, etc.) have full-time mentor types? I.e., someone whose full-time paid job is to ramp community contributors onto Mozilla projects?

    • There haven’t been many people who have had bringing community members into Mozilla as their full-time job, although that’s started to change recently. For instance, SUMO now has a community manager role.

      As Mozilla grows and problems with scaling become even harder to deal with, I think it definitely makes sense to make sure each team has someone with this role (or several people who share the role).

Leave a Comment

NOTE - You can use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Post comment

What is Persona?

Virtual Machines and Real Humans / groovecoder by groovecoder is licensed under a Creative Commons Attribution-ShareAlike CC BY-SA