QCon 2007: Zed Shaw on Mongrel
Again, unordered notes. Mongrel, the Ruby web server, is about 2500 lines of code, 6 person months of work. It’s written in Ruby, C, and ragel. Lots of statistics about downloads, traffic on the web site. Lots of companies using Mongrel, especially (off Apple is putting a lot of work into Ruby/Rails and thus Mongrel support in OS X. All of the competitors (like FastCGI, Monorail, mod_ruby, Litespeed. The Mongrel community is way more active, in his opinion the key for this is documentation. A small project with a great impact; e.g. DHH confessed to him that he had about 400 restarts a day at 37signals when using FastCGI; those problems are gone. In his opinion, Mongrel enabled a lot of companies to actually do what they’re doing, and helped them raise millions of VC capital.
Slogan & naming — he came up with the name because he hated Tomcat. Stupid marketing tricks Documentation written based on an OpenWeb template, lots of CC-licensed pictures from Flickr, done using WebGen in 4 hours. Comedy and inside jokes, e.g. a joke certificate people took seriously. Frequent releases with announcements, but not too early and not too often. Expose quality processes, interviews and speaking engagements, answers to every question and email. Answers, not explanations — not “that’s because …” but “here’s what you need to do”. Cheaper to fix something than to explain why it’s broken over and over again. Documentation is the #1 requirement. Really successful open source projects have a 3:1 documentation to code ratio.
Mongrel was created to remove suffering, esp. with FastCGI. Things that didn’t matter: Insane configurability, extensive plugin extension API, Performance beyond Ruby’s capabilities, fixing frameworks, specialized I/O processing, keep-alives, pipelining, chunked encoding.
Chunked encoding was in there already — was taken out again because it wasn’t needed, but performance suffered. Mongrel’s reason for not doing keep alive is because it usually sits behind e.g. an Apache HTTPD. “Advice from the Marianas Trench”: As a corporation relying on open source, one needs to be like the new guy in the group — have some humor. Everyone’s usually trying to have fun. E.g. Apple submitted a patch and just expected him to include it — an attitude he calls “code fisting”. [How many Google referrals is that going to get me?]. As a company dealing with open source, you need to grow a thicker skin — you can’t control the communication channel.
Symbiotic, not parasitic — the first with mutual benefit, the second just benefits just one. Apple as a model — they asked him to change the license from LGPL to the Ruby license, and offered a conference ticket and OS X seed keys to all of the project developers. How to give back: donate patches, donate hardware or software, give free versions of your software, offer books or gift certificates, write glowingly about the project, most importantly: write documentation.
Beating Mongrel: He wants to see a company do a better Mongrel, because otherwise he’ll have to do it. Stop focusing on performance — unless your server is at least 10 times faster nobody will care. Ruby is not that fast. Problems to solve: clustering, sessions, caching, logging, recovery, management. Things to keep: one minute start (download, install, run instead of “Yak shaving”), no options required, strict operation (strict requirements of what the clients need to do — i.e. Google proxies didn’t honor connection close requests, and they complained to him about violating the spec). Documentation, again. Processes not containers, simple API.
Can it make cabbage? Hell no. No money to make with web servers, revenue would have come from services. What? First reason: Blame Java — Q.: What the hell is “Enterprise Ruby” anyway? A.: Yet another stack of ‘crap’ so complex that any salesperson can use Steak and Strippers to easily sell it to management thanks to the bikeshedding effect. Second reason: Zed, because his stuff already works.
Nice talk.