It was a great experience. Mozilla sponsored our after-party (thanks Stormy!) where I emphasized Mozilla's mission to open and improve the web for everyone - from 450 million Firefox users all over the world to 40 developers in Tulsa, Oklahoma. Here's a quick summary of the projects that more-or-less finished (more details at the website):
http://cfbeo.qrimp.com - a public website to help our local food bank register and organize volunteers
At Mozilla we have lots of remote employees who live in towns outside of the "hugeness bubbles" like Silicon Valley. I want to encourage any and all remote employees to get involved with their local technology and developer communities. To promote the Hackathon, I went on a whirlwind tour of our local groups - I spoke about Solr @ Tulsa Java, mobile web development @ Mobile Tulsa, attended a Tulsa .Net developers meeting, arranged an HTML5 track at Tulsa Tech Fest (where Dave gave us the big auditorium stage!), and attended our community leadership town hall. It was tiring, humbling, and inspiring. I'm still processing it all.
Programs like Mozilla Reps help amazing and effective volunteers to promote the Mozilla mission in local communities. In fact, out of all this activity, one of our Tulsa Web Dev's is applying to the program. But that shouldn't offset employees evangelizing for a free, open, and better web right in our own back yards!
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
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.
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.
In addition to our work on MDN, this is a busy week for me in Tulsa - the annual Tulsa Tech Fest is Friday Oct 7th. Our Tulsa Web Devs group is doing an HTML5 track; my talk is the intro - HTML5: Code for all the platforms! (Soon to be a link to the slides)
TTF is a Microsoft-heavy event, but we've come a long way since TTF 2007 when Steven and I did the entire PHP track ourselves, covering Eclipse & PDT, PHPUnit & Selenium, CI w/ Phing & CruiseControl, DB refactoring w/ dbdeploy - sophisticated topics for 2007!
As far as the Tech Fest goes, I'm really looking forward to the community town hall the night before - developer group leaders from all around Tulsa get together to talk about how to grow the Tulsa developer community. I'm eager to see how the other groups are doing and to share experiences.
I'll spend all of Friday in the HTML5 room, unless I'm pulled off to the
Tulsa Hackathon
Tulsa Hackathon is a big event for me, as I've done a bunch of work for it.
It all started when Tulsa Web Devs took it upon ourselves to put Metro Tulsa Transit Authority data onto Google Maps. After a few hack days we made it work - barely. We still don't have all of MTTA's data, and we didn't make a shape file to smooth out the way Google draws the bus routes to match the roads, but we did pass the GTFS validation test! All that's left is to get MTTA to use our tool to publish the feed for Google - something that's proving harder than any of the code, I think.
Scott Phillips and I have arranged all the facilities and venues, logistics, swag, meals, etc. I'm anxious to see how much we actually get done. But really, there are just two goals - improve Tulsa, and our developer community.
Thank you Stormy (and Mozilla) for helping to sponsor our Hackathon! Everyone in Tulsa loves having Mozilla involved! I love that Mozilla promotes the web for public benefit - from hundreds of millions of Firefox users to a few dozen hackers in Tulsa Oklahoma.
Last weekend we did our Tulsa Hackathon - the summary post has links to sites and code we made and a local media live stream where I talk too much like an idiot.
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 
