• Massive funding from a visionary with a dream (in OSAF’s case, Mitch Kapor, in TOPP’s, Mark Gorton), where that dream may not always be perfectly articulated;
• Rapid staffing around an open source project attempting to satisfy that dream (OSAF’s Chandler to TOPP’s OpenCore /  OpenPlans CoActivate);
• Due to both of the above, a propensity to expand scope and broaden the potential market(s).

Since Dreaming in Code (the book chronicling the story of Chandler and OSAF) was published in 2007, Kapor has stepped away from the project and pulled his funding.  Through 2008, OSAF operated under his funding, but with a scaled down staff (10 down from ~25).  Long story short, the project failed to get enough traction and was just too expensive. There has been lots of commentary about why this happened, so I’m not really attempting to describe anything new here.

For my own understanding, though, I want to jot down the takeways that seem most relevant to my work at TOPP.  Here’s what it seems that OSAF couldn’t do, and what I’m hoping to do at TOPP Labs:

Choose one market to start with, and satisfy it fully. In Crossing the Chasm, Geoffrey Moore describes a (high tech) market as the following:

• a set of actual or potential customers
• for a given set of products or services
• who have a common set of needs or wants, and
• who reference each other when making a buying decision

According to Moore, it’s the last one that tends to hang people up — it’s not a market unless the members reference each other.  In other words, you need to focus.  In his “beachhead” (aka D-Day) strategy, he advises putting your full effort into your initial market segment, generalization be damned, and satisfying other users with what’s left over.

If there aren’t any real constraints, create some. If embrace change was the mantra of the XP movement, and embrace constraints is the mantra for web 2.0 startups, then perhaps introduce constraints to create change should be the mantra for over-funded tech non-profits.  Some constraints that are particularly relevant in this case are:  target market (see above), team size, project scope and timelines, and if all else fails, funding.  Granted, it is difficult (but not impossible, IMO) to introduce other constraints when funding is plentiful and reliable.

Don’t get too academic, OR, let the market drive your decisionmaking. This is perhaps just an extension of “constraints”, above, but I think it’s worth mentioning separately.  Looking at the way Things (team of 2 devs) and OmniFocus (experienced sofware entrepreneurs) ate Chandler’s lunch, it’s clear that there was a failure in the product development process.  While the Chandler team was debating database infrastructures and making endless product spec notes in their wiki, Things brought a simple, usable product to 1.0 in just over a year.  They didn’t have the luxury of lengthy debates; they needed to get something out there, get people using it, and get feedback.  Since their 1.0 release in January 2009, they’ve steadily released relevant updates based on real feedback.

Can you be market-based and constrained in an open source environment?  I think so; it just required leadership and understanding of these factors.   It could be argued that Chandler wasn’t able to implement these kinds of changes because of its open source nature and collaborative process, but I believe that it’s possible (and this has been clearly demonstrated) to maintain market focus and constraints in an open source project.

So, now that we’ve got that straightened out, it should be smooth sailing, right?

For a while now, I’ve been using Chandler to keep track of my to-dos.  Chandler is a semi-historic open source project which I’ve been following ever since I read Dreaming in Code (and in many ways, it’s saga parallels ours at The Open Planning Project with our work on OpenPlans)  I’ve been rooting for it through the last several releases, and have eagerly anticipated updates.

So, I was intrigued when I came across this post, which compares a handful of new to-do management applications for Mac.  My first reaction was “this field is getting pretty crowded,” and my second was “interesting to see that Chandler’s not on that list.”  Finally, my third reaction, after having checked out some of the tools, was “wow, these are just like Chandler, only better.”

Maybe it’s because it takes forever for it to load up, or that it takes forever for it to shut down, or perhaps it’s the fact that it heats up my computer and makes my fan go into overdrive every time I use it, but Chandler just hasn’t been working very well for me.  It’s a shame, really, because the project has such a long history, and is backed by so many good intentions.  But when it comes to the final level of polish and the feeling that the program gives you when you use it, it’s just not there yet.

Of the applications featured in the comparison, the two I looked closely at were OmniFocus and Things.  OmniFocus is the more powerful of the two, and is actually quite similar to Chander in many ways (both have “Clean up” button in exactly the same place). Both are proprietary applications that come at a price (OmniFocus is $79 and Things is $49), but I’m not an open source hard-liner (I’m typing this on a Mac); I’m willing to pay for software if it actually makes my life easier, though of course I prefer to use and support open source tools.

I’ve been using Things for a few days now, and in terms of usability and addictiveness it’s got Chandler beat hands down (at least for my needs).  It’s still pre-release, but the fundamental experience is very good, and the really important details are done right.  It does the things I need it to and doesn’t try to do the rest.  Creating, organizing, and viewing tasks is quick and easy, and the views they present me with let me focus on what I’m working on at the moment.

Above: Chandler’s main screen

Above: OmniFocus’ main screen

Above: Things’ main screen

So, the question is: how come these new applications are better (or seem better to me) than Chandler?  Offhand, I can think up a few potential reasons:

• Chandler paved the way for many innovative features in task management (e.g., turning tasks into calendar items).  Not particularly likely.

And on to the more likely reasons:

• Chandler is too complicated, and these other applications do less, better.  Yes.
• Chandler couldn’t cross the chasm between early interested techies and the mainstream market.  Seems true.  Interestingly, Things seems to be starting with the mainstream market and doing well.
• Chandler had too big a team and too much funding.  This much seems to be widely understood.  Looking through the project wiki, one can find years worth of theories and plans, but somehow those were never translated into actual, usable product, whereas Things was produced by a small, balanced team including just two developers.