"in response to Sparkleberry"
Wrong person.
By the way, I would not be too quick to attribute it as 100% developer fault. I think both Apple and MS are working together to resolve this.
As evidence:
About the OS X El Capitan v10.11.1 Update - Apple Support
Background
http://www.computerworld.com/article/2990427/mac-os-x/microsoft-gets-an-earful-a s-office-for-mac-2016-users-amp-ire-over-crashes.html
http://www.theinquirer.net/inquirer/news/2428997/use-outlook-on-a-mac-dont-upgra de-to-el-capitan
http://www.techtimes.com/articles/95534/20151017/microsoft-latest-update-office- 2016-mac-fix-el-capitan-crashes-hints-apple-fault.htm
Further background
See long thread in ArsTechnica
http://arstechnica.com/civis/viewtopic.php?f=19&t=1258233
And look for comments by a knowledgable contributor such as Schwieb who works on Mac Office such as:
The issue with hangs in 2011 on El Capitan was completely unrelated to the issues with 2016.
The 2011 hangs were due to a bug in a header in the SDK from OS X 10.5. Since Apple no longer supports this SDK, but our build system for Office 2011 is frozen in time, we had to inject a customized header with a fix into the compiler include paths. Any other app built with this header would have the same problem on El Capitan, but practically every other app has long since moved their codebase forward to the latest version of Xcode and the system SDKs. We're not doing that for Office 2011 because the engineering effort to move it over to clang is many developer years with lots of risk (we've already done that work and absorbed that risk in Office 2016). We knew about the bug for some time but it was really tricky to track down the root cause, and then it took more time to come up with a safe fix that didn't involve hacking on Xcode and the SDK itself.
The 2016 issue turned out to be a bug in sqlite. I don't know if the bug was in Apple's fork of it or in the open source codebase itself. There was an unfortunate misinterpretation of a struct between some 32-bit and some 64-bit code, such that the system ended up waiting on a semaphore with a multi-billion-second timeout. If you could wait a few thousand years the timeout would trigger and the app would un-hang, but unfortunately our hang detection code refused to wait that long and would presume the app was dead. Apple has fixed that bug in the build of sqlite that ships with El Capitan in the 10.11.1 update, and we're adding UI to our hang detection code that will let the user choose whether to wait longer or abort the app now. (That UI choice still wouldn't have been helpful with this particular bug, as nobody would wait more than a few minutes anyway...)
Schwieb