What Mongrel Isn't

Or, Write Your Own Damn Web Server

Every once in a while I get someone who sends me an e-mail a lot like this:

"Hey Zed! I got this great idea for Mongrel. All you have to do is completely change the internal processing, add 200 more methods to the HTTP parser, make it run on Solaris ZFS with AIX backends, serve Bittorrent over Ethernet, and have it save Korean orphans while eating a Mango in the back seat of an El Camino driven by twenty midget clowns. If you do that I'll be rich! Uh, we'll be rich!"

Mongrel is an HTTP server for Ruby applications. It does the bare minimum necessary to serve a Ruby application. That's it. No more, no less. I fight off features all the time until they're absolutely needed, and usually if someone needs it they can write their own special GemPlugin? and serve it up without even talking to me. Mongrel is great that way and I love when people extend it for their own uses.

Notice I said "I love it when people extend it for their own uses." I didn't say any of the following:

  • "I love doing other people's dirty work so that they can make millions off the sweat on my back."
  • "I am your whore, so sure I'll get right to writing that Bittorrent client."
  • "I would love to be your corporate tool since I'm all about getting screwed."
  • "Wow that idea is so brilliant I think I'll sign an NDA right away so you can take all my rights and all my work."

If you have a feature that you think would be great for Mongrel, then go for it, but you implement it first. I can give you advice, give you help, encouragement, meet you for coffee at conferences and I'll even take reasonable patches if you find bugs and do come up with nice little ideas.

But don't send me monster patches that make your application work better and expect it to get put into the Mongrel core within the hour. This is called "code fisting".

Code Fisting

I worked with this guy once who walked into my office one day to tell me that he had started reorganizing the code base for the product. Problem was he started this completely useless reorganization two days before a big deployment, checked it into the CVS repository without telling anyone, didn't get it working at all, and then had to go on vacation that same day. He was in my office to *tell* me to clean up his mess since his changes completely broke the build. He did all of this without telling anyone or asking first.

This is "code fisting", where you shove large amounts of code at people where it isn't wanted. When you do this all you're doing is pissing off the people you work with and costing your employer money. In an open source project it can get you kicked out, ridiculed in public, and jeopardize your reputation.

I find that people who do this seem to not understand the #1 rule about working with others on a software project:

"Whenever you do something make sure it causes the least amount of suffering for others."

Change is important and the project needs it to improve, but if you go thrusting your nasty designs on other people in surprise Ninja moves then you're not following the rule.

So how do you reduce the suffering that comes from big changes?

Code Lube

Code lube is the answer to *necessary* code fisting. Code lube is a combination of communication, coordination, and gently applying your changes slowly over time until they're in sync with the rest of the world. You have to baby step the other participants and if they aren't receptive, then put your stuff into a patch or a branch and come back to it later.

This includes changes that aren't related to code. Deployments need to be heavily coordinated. Moving servers, changing database schemas, installing new versions of tools, and changing important documentation all require talking with people.

Contributing To Mongrel

Hook everyone up with a bit of code lube. Talk with people on the project, contribute something small and useful first. Don't just change all the STDERR usage to $stderr so that you can get a nice printout for your unit tests (especially when there's already a simpler existing way). Talk with people first and see if they're receptive.

If they're not receptive, take the Mongrel code and do it yourself. You never know, maybe we're all stupid and you're brilliant. Since Mongrel is open source and you've apparently got the free time, then grab the code and try out your idea. If it turns out to be a great one *then* talk with people to get it implemented.

Otherwise, have fun with the project.