Friday, May 27, 2011

Abandon your cake

Pretend you spend all day making your spouse a cake. You carefully research the ingredients and then painstakingly try to the best of your effort to do everything well. However, it comes out slightly too brittle; the hand-made frosting is a little tart. But you spent a lot of time on it.

You present the cake. After the overjoyed response, you proceed to cut the first slice and your spouse takes the first bite, rolls the taste around, ponders a bit and very seriously states, "A bit bland, the frosting needs some work. Let's go to the grocery store and get a better one."

You are shocked. "Let's go to the grocery store?!", you spent all day on that damned thing; the store wasn't even open when you started; there were not even cakes available for sale at the time you began.

But sure, you aren't a pastry chef and you probably made a few mistakes along the way, but it's your cake. You made it specifically for your spouse.

But now, of all things, your spouse looks impartially at it, throws out the idea that you had anything to do with it and does some objective comparison. The conclusion is inescapable; the store is in fact open now, and does sell better cakes than the one that you made and instead of making it yourself you probably should have just gone out and bought one when the store opened, spending all of 20 minutes.

However painful it may be, you must acknowledge that if you want to enjoy a great cake, you should toss yours in the garbage, forget about it, and grab one from off the shelf.

Software is the same way. Oftentimes you will find that a solution baked in-house by a colleague you know and respect is not as mature as one that is open source.

Sometimes although the in-house solution may predate the open source one by many years, the open source solution appears to have raced ahead in quality, stability, and features.

You know intellectually that you will get a better product if you go forward with the open source solution that is well supported and well written. You know that you will free up the time of all parties involved. It looks like a pure business and logical decision. It's easy to forget the fact that you are suggesting to toss out someone's handmade cake by effectively saying:
Hi. I just wanted to say that you wasted your time and your solution is inferior to something I found in 30 seconds on google. We should be using this instead.
Breaking this news is one of the most difficult things to do at a personnel level on any programming team. You look like the new kid tossing out personal insults, disparaging the quality of your colleagues works; suggesting that they produced inferior code that simply is not good enough to be put in any project that you want to work on.

The truth is though, adopting open source (ie, off-the-shelf) components over in-house solutions can often be a leading factor in whether a project is successful and done on schedule. Off-loading as much responsibility as possible permits your team to focus on the product and not the dependencies.

When you are the cake maker, this reality is a very difficult thing to accept. "My cake is worthless?", you incredulously pout. You skeptically go over the open source project with a fine-toothed comb. "But wait", you insist, "It can't do xyz, and I can. Ha!" or "Let's run some performance tests and see how this POS does".

However, you acknowledge that it is well done. They are catching errors that you were too lazy to check for; they have active mailing lists and people around the world fixing bugs while you are at home sleeping. Intellectually, you know what to do:

Abandon Your Cake.
Implement the stuff you have that the open-source project does not and submit a patch. Probably introduce yourself as someone who has written a similar project but has done the grief of switching over.

Once you get over yourself and toss your cake away, you can hop on the winning team with enough courage and strength.

Don't look at it as if you need to match the feature-set of the project but as a collaborative project with open-membership that you have specific expertise on.

You came up with a solution to a generic problem that many people face and you learned a lot by building it out yourself. You have a lot of knowledge to contribute. You were good enough to do the solution single-handed; you are certainly good enough to contribute to a group effort.

So someone else won the internet lottery fame game this time, it happens. Go join them and you will be a valued member of their team. After a little while you will be able to faithfully consider it your project as much as any other contributor.

It will be easier, you'll get more exposure, and you can claim part ownership of something that people actually have heard of instead of filling your resume with github projects that are only watched by yourself.

Sharing the fame beats pounding the pavement any day.