Feb 25 2007

Release a framework? Are you sure you *want* to?

Posted by Joe Rinehart at 5:10 PM
4 comments
- Categories: Model-Glue

There's a new twist on the eternal frameworks debate going on: now we're not just talking about whether or not frameworks are good, but if you should release one that you've written. In this post, I'm not going to state my opinion (Sean's said it better than I can, in just the title alone). Instead, I'm going to talk a bit about things I think you should consider before releasing code, mostly taken from lessons I've learned.

Be Ready for the Flames

If you release code, you're attaching your name to it. Even if it's a "take this, play with it, do whatever you want, I'm not finishing it" release, you're associated with it. No matter what you say, you will receive e-mail about it not working. People will ask for fixes. People will bad mouth you. It is inevitable.

Existing Products Exist for a Reason

Examine the market. If there's a perfectly good wheel out there, and yours is only 1% rounder, expect a "WTF?" response. If this is what you're looking at releasing, round out that existing wheel instead of rolling your own (pun intended). If you're going to release, do a litmus test of whether or not the differences in your implementation matter to anyone. Find out if anyone else things an alternate needs to exist. Sorry if it sounds harsh, but it may not.

You're Only 25% Complete

Somewhere, somehow, someone's going to do something completely unexpected (but, at the same time, completely reasonable) with your code. People doing this kind of thing will make up a small minority of your users. They're not trying to screw up your life, just solve those little edge cases that make a system unique. Everyone system has them, otherwise we'd just be assembly line workers in software factories.

Unless you're omniscient, you're signing up for a life of solving other people's edge cases, spending 75% of your framework development time solving other people's problems. Sucks, doesn't it? Open source is supposed to solve this, right? Dream on, Stallman. Most of the time, either you're going to solve the edge cases yourself, or the squeaky wheels will result in a cloud of bad press for you.

Be Ready to Kill It

So I'm the Model-Glue guy, right? I'm also the ChiliBeans, Arf!, Paste, and Rocket guy. Be ready to say "enough is enough" and kill your project. Sometimes, a project's done its job if it's done nothing but kickstart others into starting/furthering their own. No, I'm not saying anyone should kill Mach-II.

Comments

Brian Rinaldi

Brian Rinaldi wrote on 02/25/07 6:17 PM

Great follow up post. I would say one thing however and that is that sometimes I think people find out that there is interest or not *by releasing the code*. Often there is no good way to determine the worthiness within our own ecosystem. I think the market, so to speak, works at weeding this stuff out. The market isn't perfect either, it can actually kill a worthy project. People often need a compelling reason to change, and even though framework X may be "better" than framework Y, I am not going to change until some requirement compels me to do so.
Peter Bell

Peter Bell wrote on 02/25/07 8:39 PM

Hey Joe,

Great posting from someone who's been doing it for a while. Nice pointers - thanks!
Sean Corfield

Sean Corfield wrote on 02/25/07 9:20 PM

My trick is to release weird little niche projects that almost no one understands (Closures, Concurrency) so I get very few emails about it not working and almost no edge cases that weren't covered in the original design :)

To make up for that, I throw myself on the full-blown, public magnifying glass of Fusebox 5 (and now Fusebox 6)... I must be a glutton for punishment :)

Great post Joe!
Derek P.

Derek P. wrote on 02/26/07 12:31 AM

So, I wasn't supposed to understand what Closures and Concurrency is for then? Phew! :)

Write your comment



(it will not be displayed)