What can stop you (apart from giving up) is if you can't (or won't) learn some key thing, or can't (or won't) do some key thing. Which is why having mentors/colleagues is very helpful (for learning); and having co-founders and being able to employ/outsource/team-work is very helpful (for doing).

Another is Xerography being rejected by IBM after careful (and accurate) market assessments. The market significance only appeared after Xerography was actually in use. (from The Billions that Nobody Wanted.)

So when pundits (not cdixon) tell you it's impossible to discover a market retrospectively, they are simply wrong. But they're right that it's risky; and that it's much safer to launch with buyers waiting (of course!). I think the key take-home is that: a business needs customers. (Sounds obvious? Yet it's a perennial downfall of engineer-lead startups.) Finding customers (aka marketing) is at least as much work as creating the product in the first place. To put it in perspective: if creating the product takes a few prototypes over a few months or years, it's probably reasonable to put comparable effort into marketing: a few markets and 4 P's over a few months or years. The danger is when you exhaust yourself engineering it, and collapse at the finish line - just when the second marathon starts, of marketing it. (of course it's even better to run both marathons simultaneously... to torture the metaphor).

Not only can this provide faster responses for each continent, but it also enables peak times in one time-zone to be supplemented by resources in off-peak time-zones. Though I guess the latter is true of any cloud infrastructure, even if centralized.

Anecdotally, it seems fairly common that maths is independently re-invented by people applying it - famously for relativity, IIRC. That's because the maths guys don't actually know about the applications.

It's a truism for our industry that if a new approach really is significantly better (eg. x10) in practice, it will be adopted. You don't need to convince people; you just beat them. OTOH, there's a common wish to over-automate: to spend a week saving a second, and then it turns out to not handle the very next case. So, some people don't like to use frameworks because they are too constricting (don't handle all the cases in practice); and some (Alan Kay) even say if you can build your own infrastructure, you should.

Mathematical ideas usually only work on their own assumptions - a difficult part is matching those assumptions to an application. Though maybe this isn't a problem for the generics example.

There's also incidental practical issues, like the need to ship, then of back-compatibility, resulting in a current Java implementation that can't express List<Circle|Rect> (you need an explicit Shape interface/superclass). Although *ML has proper algebraic data types, does C# do it properly? I don't know.

That's often a big part of it: Someone who isn't a day-to-day user of something sees an issue in it and recognizes that it could be done in a cleaner way, but explains the solution in their own terms rather than in the local language.

Sun failed because of poor execution. They blew the cloud computing opportunity. Their sales people did not chase orders like the HP guys did (this is for a personal experience ). Their Java application server sucked when compared to Websphere and Weblogic. They could not deliver a good story with MySQL acquisition. They let Linux get ahead of Solaris , at least in mind share.

The crucial point isn't that it's a technology disruption, but a business disruption, in the sense that (1) customers of the new technology have different needs (or ranking of needs); (2) vendors of the new technology need to supply it in different ways.

One example from the book, on disk drives, is that in moving to smaller disk drives that were more popular in laptops, (1) for customers who valued small physical size and mechanical robustness over storage size and cost per MB; (2) the manufacturers of which came out with new models twice as quickly as the previous size (incumbent organizations found it difficult to change all their internal procedures to adapt to this new rhythm, new sales channels, new customer demographic - everything changes, both "build something" and "that people want", not just the tech).

Because it's not a technology problem, but a business problem, the proposed solution is not a separate tech lab, but a separate business unit - one that can be happy with tiny sales, and that can be organized by the needs, ranking of needs, and rhythms of the new market.

[It seems to me that sadly, this amounts to a startup, which the incumbent owns; this will save them financially, but won't save their organization.]

A current example is ARM CPUs in smartphones, which appear to have disrupted intel x86 architecture. But I hesitate to count intel out - they've been around the disruption cycle a few times (having invented the microprocessor and integrated circuit).

So, could you elaborate with specific criticisms of CatB?

Or just go to his blog and read the second article:

"Regular readers of this blog are probably pretty clued in about my better-known software projects – gpsd, fetchmail, giflib, libpng, INTERCAL, ncurses, Battle for Wesnoth, Emacs VC and GUD modes, and the like."

The entire place is an altar to the man.

Even Stuxnet, the super interesting piece of industrial hacking. Even it didn't escape ESR's blessing wand:

"[My friend] incited me to blog by asking me the following question: “Would you call the perpetrators of the Stuxnet worm `hackers’, rather than crackers”?"

The entire security scene stood up in awe, given the combination of effort and ingenuity. But not ESR, he found this an opportunity to play pope and bestow titles.

We now know that you hate ESR's self promoting behaviors, but where is the substance?

The substance is lacking because I am not motivated enough to think harder about the man's writing. Something switched in my head and one day I realized he was the antithesis of the hacker-ethic he preaches. "Real Hackers", much like the real Scotsmen, work silently, are under-appreciated, and often unknown.

Having said that, it takes one to know one; given an audience the size of his, I am 100% certain I would go on a similar journey of self-worship and rampant "blow-hardery".

Ahhh! what wouldn't I do for unearned public recognition and a permanent podium.