Taking a look at their "idea" page, I found myself nodding along with most of their bullet points (or shrugging and saying "not exactly my preference, but I can see why you'd want that"), until I hit:<p><pre><code> Ghost would have cut-off points with major versions,
allowing core developers to remove old code from the
codebase and evolve the platform to allow it to improve.
No one expects an app written for OSX 10.4 Tiger to work
on OSX 10.8 Mountain Lion.
</code></pre>
Oh, hell no. Backwards compatibility is way more important than some shiny new feature. When I upgrade my software, I expect it to work better, not break. If I have a working plugin from 5 years ago, why should I have to fight with some pointless API redesign just to get it to work again?<p>In the real world, people need compatibility more than they need whatever cleanup you're able to do by breaking compatibility. Heck, in many cases you can get both by doing your rewrite but leaving a compatibility layer on top that gives you the compatibility that you need.<p>I'm so sick of trendy "modern" frameworks like Rails that break compatibility every 5 minutes, and listing breaking compatibility as a major feature is a huge turnoff.<p>How about focusing on spending the pre-1.0 releases iterating and designing a really good API that will be amenable to backwards compatible extensions, and then sticking to that API and backwards compatible extensions to it for the forseeable future?