One downside of VP9: the VP9 spec is still under NDA from Google. There is no publicly available spec. As far as I know, the only people that have written a software VP9 decoder are either Google employees (libvpx) or ex-Google-employees who worked on VP9 when they were there (rbultje, who wrote ffvp9 with Clément Bœsch).
There's a public RFC, but it's by no means usable as a bitstream spec.
There's an official text document describing the bitstream format (several hundreds pages), but it's under NDA.
We use it at work, and getting an updated version is far more trouble than downloading a file on a public server.
The document in itself is nearly worthless, though, as it's far from complete. In the end, you still need to dig into libvpx to understand how things work.
Lots of people have produced decoders for vp9 including both hardware and software vendors. Including companies like ittiam, Intel, samsung and qualcomm.
Lack of a non NDA public spec may have made things more difficult for some but it certainly didn't stop everyone.
Actually, as a decoder implementer, I found that having the C source code of a reference decoder (libvpx), whose behaviour is authoritative over any text document, actually made things a lot more easy.
Because now, whenever you ask yourself "how should a VP9 decoder behave in this situation?", you have a non-ambiguous answer "do like libvpx does".
We didn't have this luxury with HEVC. The HEVC reference decoder (HM) is horribly complex, and has been easy to crash in many different ways for years. As a consequence, it could by no means be considered as authoritative. Which is a pity, because there were a lot of discrepancies between the reference decoder and the .doc spec.
