How about, "Pick your battles"? I agree that it's ideal to own something vital to your business or a product, but if you're trying to validate an idea and get something to market ASAP then outsourcing and/or using 3rd-party services can make a big difference. Trying to do everything yourself is a slippery slope. Related: http://en.wikipedia.org/wiki/Not_invented_here
I always took his statement to mean that if something is essential to your business, you should think very carefully about the risks inherent in outsourcing it. The two major exceptions to this are
1. Things which aren't essential to your business. (e.g.: things that could be replaced by nothing (even if just temporarily))
2. Things which meet the definition of a commodity, in the formal 'fungible goods' sense of the word.
Many .?aaS offerings fail both of these tests in that they're an essential component of a service, and also fail the commodity test in that there is qualitative differentiation between offerings. The features of EC2 (used to their fullest) are wildly different than those of Rackspace, and the two are only really fungible with one another across a small subset of their feature sets.
Examples of offerings that pass this commodity test include:
- Most mailers (sendgrid, mailgun, postmark, &c) when used simply. Switching from one backend to another isn't a huge endeavour, as they are all cut from conceptually similar cloth.
- VPS offerings when used simply (notice a pattern here?). A basic Ubuntu box in the cloud is a basic Ubuntu box in the cloud.
In contrast, Stackmob, Parse, et al. all fail this commodity test hard. Switching costs are very high (especially with Stackmob, whose iOS SDK bleeds anti-patterns all over your app), data migration is a nightmare, and major architectural assumptions can vanish in an instant
Part of the bargain of leaning on non-commoditized offerings to back essential services is accepting the risk that they may one day leave you in the lurch. In the metaphor of technical debt, outsourced services are extending you credit to finance your technical debt. Having one of your outsourced dependencies close up shop is really just them calling in their debts.
Of course, there's no right answer. I agree completely that the point is moot unless you ship; the GP wasn't really intended to be imperative; it was meant (or at least it was always how I understood it) as more as a heuristic to assess the risk associated with outsourcing a core dependency that can't be easily hedged.
If you are trying to validate an idea, then building it on a 3rd party service is fine, because your riskiest hypothesis is not, "We can run a real business."
But once you have validated the idea and are making a proper go of it, then yes, betting the whole of your company on some other highly risky company is generally a bad idea.
Basically, "never outsource something hard to replace" still applies, because early on you're happy to replace your entire business. If you have a few small customers and your vital 3rd-party service provider fails, then you say, "Oh well," accept that the customers are going to be pissed, and resign yourself to getting new customers. After you have rebuilt on a lower-risk platform, of course.
The company hasn't changed in ten years. Their notebooks today look virtually the same as those from ten years ago. Maybe a little thinner, plus they come in different colors, but that's about it.
Apple's Mac Pro looks nothing like any computer ever made before, and their new MacBook Retina machines are radically different from their 2004 Aluminum Powerbook models.
I kind of like HP's redesigns, it shows they're trying. The Envy isn't bad for a MacBook inspired knock-off.
