It always seems like a loss to me Joe's blogs read he's still selling the Midori C# OS to some extent, and either sees no real downsides to it or doesn't want to talk about them. Like, on the page introducing the series, he says his biggest regret is it wasn't out there so "the meritocracy of the Internet could judge its pieces appropriately," as if perhaps the big problem was just misjudgment in a non-meritocracy. (And, hey, the Internet's judgment sure has its warts too.)
It's fine to try to salvage good ideas from a project that failed at its initial goals (and MS seems to have!), or even to hold on to thinking the basic ideas were good even though the implementation failed. But if he could just be candid about what wasn't right, he could spread those expensive insights you get by actually building a thing, and show a real ability to learn from failures. Who wants a postmortem that doesn't discuss what went wrong? How useful is it to talk architecture if you aren't clear about downsides and tradeoffs?
Concretely: What did the decision-makers who finally canned Midori dislike? What were the performance bottlenecks (and numbers) after all their tuning? Had they given up too much safety by the time they had it performing well? Was it a compatibility thing, and if so what are his thoughts on an approach to that? Was it just going to take too much investment to finish? I think a little candor about the limitations, downsides, and hard-to-swallow parts of Midori could advance the thinking about its basic ideas much more than a lot of posts about implementation tricks.
Looking at the history of similar fate in other safe stacks, the political reasons or desire to cut research money are higher on the list than technical issues.
Everyone that was able to use Oberon or the Xerox stacks knows that it is possible to have such systems and do productive work on them.
I don't think the project was canned on technical grounds, but more on project management grounds. The project ran for several years with no real deliverables or deadlines, and management inevitably had to question whether the project was bearing fruit.
Looking at Microsoft (and any other company of comparable size) decision making process, I'm seriously doubt the main reason to drop some project is technical most of the time.
It's fine to try to salvage good ideas from a project that failed at its initial goals (and MS seems to have!), or even to hold on to thinking the basic ideas were good even though the implementation failed. But if he could just be candid about what wasn't right, he could spread those expensive insights you get by actually building a thing, and show a real ability to learn from failures. Who wants a postmortem that doesn't discuss what went wrong? How useful is it to talk architecture if you aren't clear about downsides and tradeoffs?
Concretely: What did the decision-makers who finally canned Midori dislike? What were the performance bottlenecks (and numbers) after all their tuning? Had they given up too much safety by the time they had it performing well? Was it a compatibility thing, and if so what are his thoughts on an approach to that? Was it just going to take too much investment to finish? I think a little candor about the limitations, downsides, and hard-to-swallow parts of Midori could advance the thinking about its basic ideas much more than a lot of posts about implementation tricks.