[hawkice]

There are quite a few things in the fourth category, and I'd like to say, for instance: Beeminder. Specialized, but there is a lot going on. Honestly, I like it. I could just keep a text file if I didn't want those features, and I honestly can't think of any features I would subtract. Which raises the larger question: are the advocating flexible but simple tools, straightforward but domain specific tools, or are they just advocating against building something that is a complete mess and a waste of time?

It's important to remember that while quite involved and extremely domain specific, Beeminder has an API. He seems to care a lot about that, and I have no idea if his real point is "make things that don't suck and avoid digital vertical integration".

[icebraining]

I could just keep a text file if I didn't want those features, and I honestly can't think of any features I would subtract.

But the point about simple & flexible tools is not to miss on features for the user, but to separate those into different tools. The people who prefer a simple text editor to an IDE aren't doing everything else by hand, but using a set of different tools to accomplish the same as the IDE built-in features would.

Taking the Beeminder example, and with the caveat that I've never used it: the graphing system seems cool, but it can't be used by anyone who doesn't have access to a credit card; if the graphs and the commitment payment systems were two separate tools that you could connect instead of a bundle, one could use the former with an alternative commitment system.

[dreeves]

I'm tempted to quibble that you can use Beeminder without a credit as long as you never go off track. But ultimately I think you're right, we're guilty of this. Ideally the Quantified Self part and the commitment contract part would be independent but interoperable tools.