There appears to be some debate about "the divide is between wanting an SDK and wanting to know the underlying protocol" (see http://www.tbray.org/ongoing/When/199x/1999/08/18/BitsOnTheWire).
I don't really understand what this is referring to, or why they are mutually exclusive.
What is the philosophy of each approach and why do they conflict?
Suppose client C needs to talk to service S provided by vendor V. If all you have is an SDK, then you must install vendor V's SDK software on the client C in order to talk to S. On the other hand, if vendor V documents exactly how to talk to service S down to the bit level, then you can write your own software on client C to talk directly to service S.
They don't have to be mutually exclusive, it's just that anyone providing a service will either focus on the SDK or the wire protocol as their public customer-facing promised interface. You could have a service that provided both, and let your customers choose which one to focus on, but that might be a luxury.
While it is helpful in some situations to know what is going on at the bit level especially for troubleshooting, using a vendor's SDK may be the best way to isolate your integration from any future changes that the vendor may make in their messaging structure.
This is not to say that there won't be an inconvenience in terms of getting the latest SDK and such, but at least if the vendor did their job right, you don't have to worry about changing your code, just using their new SDK.
For example we have worked with a company called ISD who specializes in payment switch products. We coded to their SDK. While their products have gone through some versioning, the most we had to do is update the DLLs on the client machines. The DLL retained the same public interfaces.
They're not really mutually exclusive. It's more of a continuum, but the development philosophy behind systems tends to gravitate towards one end or the other.
Essentially bits on the wire says the communication protocol is simple enough that it can be described to outside developers via some relatively simple (or even informal) specification. This means the service can be used in all kinds of unforeseen ways, and the service consumer need not be an official supported platform.
On the other hand, companies with monolithic offerings like Apple and Microsoft have the luxury of choosing another philosophy, which is to build a complete end-to-end SDK. In theory this makes life easier for developers by abstracting away the complexities of the underlying protocols, simultaneously freeing up the product to do more complex things, and reducing developer error. Of course there are still bits, and they still go over the wire, and they can be reverse engineered. However this will be considerably (orders of magnitude) more difficult to do than to use a protocol that was designed to be understandable, especially if it was intentionally obfuscated or encrypted to serve business interests.
If you go the SDK route, it's very important to not also provide the bits on the wire spec, as happened in this story.