While this is somewhat true for the image-spec (with some very notable exceptions where the semantics have deviated heavily), it's absolutely untrue for the runtime-spec. As one of the people who maintains the legacy of what Docker did before the OCI (libcontainer which is now part of runc), the interfaces and semantics are very significantly different.

Docker does use the OCI runtime-spec internally now (with plans to support the image-spec at some point), but that happened after the spec had become fairly stable.

The most important thing is not where the spec design came from, but that it's now being maintained by a community that will make sure you don't end up with fragmentation and lock-in.

How much does the OCI image spec differ from the one developed by CoreOS for appc? When OCI was announced, image spec was outside of its scope (https://coreos.com/blog/making-sense-of-standards.html), so coreos's work in this space seemed highly important. So has all work essentially been abandoned? Or did it inform the image spec of OCI (and 'what docker does') at all?

Not really though. Equating docker with OCI is kind of like saying gmail is the same thing as SMTP. Gmail works with SMTP to send messages, and docker works within the confines of OCI to create images.

While Docker is mostly OCI compatible these days (I say mostly as they extend their tools beyond it, making it hard to replicate the build without using docker itself. Not in-and-of itself a bad thing, but still annoying for portability), it shouldn't be confused with the OCI itself, which is there to help safeguard against companies like Docker going off and doing incompatible things.