Yes, only expose APIs you have clear use cases for.
Yes, keep the surface area as small as possible.
Yes, have very focused requirements.
Yes, document the hell out of things.
Yes, implement strong parameter validation and other things to try to reduce the chance people do bad things.
Do all these things and more (these are all part of what makes exposing APIs hard work, that many people don't do).
But do not, for one second, believe that someone still won't do it wrong or abuse your perfectly designed API eventually... especially if it is successful.
I agree with all of what you just said. But I think that the post is not a good demonstration of that.
Microsoft failed at keeping the surface area as small as possible. When their surface area expanded to a hack to deal with Adobe's hack of replacing code behind Microsoft's back, they went into very dangerous territory.
They will blame both initially. Pissed off people are pissed off, and distribute blame randomly. That is the short term pain. However if it broke AND Microsoft stated up front that it really was Adobe's fault, Microsoft would have taken less of the blame. Not none, but less.
The flip side if Microsoft had bitten that painful bullet up front, then I believe that going forward companies like Adobe would have learned to not try to hack the system like they had. That would have given everyone, including Microsoft, a better reputation.
But of course Microsoft did not do that. And now Microsoft has such a history of nasty bugs that, even if Microsoft is in the right, nobody is going to believe it. (Which of course locks Microsoft into its current strategy of bending over backwards to accommodate everyone else's bugs, causing more bugs...)
It's not as simple as that. If it's just Adobe WhateverIUse that breaks, sure, people will blame Adobe. But if it's Adobe WhateverIUse that breaks AND WordPerfect WhateverSomeoneElseUses and maybe also Borland SomethingSomeoneElseYetAgain uses word will get around that the new operating system "breaks things" and people will stay away from it.
Even if noone will ever use all three of the broken apps.
In this sense, maintaining backwards compatibility is simply a matter of reputation management.
> If it's just Adobe WhateverIUse that breaks, sure, people will blame Adobe.
Not a chance. People will blame Microsoft, because WhateverIUse worked perfectly before. The only parameter which changed is that they updated the OS, therefore the OS is to blame.
That is a wish, not the truth. It is self-evident that if I upgrade my OS and an app stops working, it is the upgrade's fault. I'm sure there is a "law" of "whoever last changed something broke it."
I think this is very naive/utopian.
Yes, be super focused in your design.
Yes, only expose APIs you have clear use cases for.
Yes, keep the surface area as small as possible.
Yes, have very focused requirements.
Yes, document the hell out of things.
Yes, implement strong parameter validation and other things to try to reduce the chance people do bad things.
Do all these things and more (these are all part of what makes exposing APIs hard work, that many people don't do).
But do not, for one second, believe that someone still won't do it wrong or abuse your perfectly designed API eventually... especially if it is successful.