1 files changed, 97 insertions, 0 deletions
diff --git a/site/src/not_mongrel.page b/site/src/not_mongrel.page
new file mode 100644
index 0000000..b7ff121
--- /dev/null
+++ b/site/src/not_mongrel.page
@@ -0,0 +1,97 @@
+---
+title: Not Mongrel
+inMenu: true
+directoryName: Not Mongrel
+---
+
+h1. What Mongrel Isn't
+
+h2. 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".
+
+h2. 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?
+
+h2. 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.
+
+
+h2. 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.