I think, the fact that people that advertise their "API" and "platforms" and provide a glorified REST frontend to their website are actually diminishing the value of true platforms and API, where actual thought was put in making a business case, architecting them, making sure they'll be there long-term and changes planned with regards of backwards-compatibility. You can actually see one of the comments here on NH that claims that it is "vitally important to remember that external APIs are unreliable and temporary". No, they are not, if we are talking about platforms. While this is true that new API subsets are being added with every new release (more: "Fire and Motion" by Spolsky), with platforms you can expect that existing API are still there for some time, and not until the end of next month, because "platform" vendor "pivots" while burning through VCs money.
Well, given the choice between a world where the only APIs in existence are "true platforms", backed by enormous corporations with tons of resources who pledge to make them absolutely backwards-compatible for ten years... and a world where, in addition to the true platforms, every half-assed hack also has some sort of API so that other people can build upon it with half-assed hacks of their own, my first instinct is still to prefer the second world.
Yes, this means that the word API no longer connotes "true platformness". That's a branding problem for the "true platforms", but I'm sure Microsoft and Oracle can handle it. They have resources.
Now, what your instinct says about viability of business that is built on top of "half-assed hack"? Or we'll just stick with the business model where there's VC or an angel with extra cash to burn, while we're making sure our instincts are happy?
I'm not sure I'm reading your sentence correctly, but the scary truth is that many, many brand-new businesses are initially built on top of half-assed hacks. By design! That's what all this "minimum viable product" talk is about.
The canonical example might be Twitter. There's absolutely no question that their initial Rails-based infrastructure was not up to the task of running Twitter. But it was up to the task of running Twitter for a few thousand users, long enough to prove that they really needed a better, custom, designed-and-maintained-in-house-by-an-expensive-team-of-hardworking-experts architecture, which they then built, using money raised on the strength of the initial hack.
And it's absolutely true that businesses built on half-assed hacks generally aren't viable in the long-term. But most businesses aren't viable, period. The trick is to upgrade the viability of the codebase as the business continues to prove itself. Nobody said that this was easy to get right, and you can fall behind ("OMG our codebase is horrible and the fail whale has its own fan club"), or you can get too far ahead ("OMG we spent a fortune overengineering our product"), and sometimes you don't even know whether you are ahead or behind, but that is the game.
Meanwhile, let's not get completely stuck on businesses. There's room in life for half-assed mashups that cannot possibly "work" long-term, but are a lot of fun. Even before Twitter was a rickety service with a dozen public users, it was a hilarious idea with no public users at all. The toy stage is important too.
Absolutely. I'm postulating a very conservative lower bound here.
(And, obviously, a very rough approximation of the actual history. If we could see Twitter's Git repository presumably we'd find that the service actually went through dozens, perhaps hundreds, of performance tweaks as it grew.)
