Consider that appc was basically a tactical move from CoreOS to force Docker to play ball and address concerns they had, or face unwelcome competition.

OpenContainers addresses one of the fundamental issues already with the initial "runc" tool - namely the issue of playing nicely with Systemd and not requiring a separate daemon.

It also appears to be headed towards addressing a second one: A spec.

It would also seem that what's there so far with 'runc' could easily be used as part of an appc implementation easily enough, and conversely, there seems to be little reason why this couldn't be supported by appc implementations (or others, like LXC).

So what we're (hopefully) getting is a compromise that lets people compete on value adds rather than fighting over the basics.

>But I thought a big selling point of a standard means it's written down, currently the spec returns a 404 on github [1] seems like a lot of unknowns on what's actually being proposed.

It was just announced.

I'm guessing because Docker didn't participate in App Container, so this is a compromise to bring Docker on board.

To clarify, the Open Container Project was started by Docker with the help of the Linux Foundation. Then other vendors were invited (including AppC maintainers). We did this because there was a clear demand for transforming a de-facto standard (the Docker format) into a proper standard (OCF), and for opening the governance of our runC implementation.

Since AppC is a completely different format from what Docker uses, starting from that would have defeated the purpose. However it made a lot of sense to invite the people behind AppC to join, so that we could all build a better spec and implementation together, instead of arguing on technical details that don't matter.