You know, I keep seeing this "proprietary NaCl" statement around, and having played with it myself, I have a bit of a soapbox. There's nothing
proprietary about NaCl: all the specs are open, and Google actively wants Mozilla and others to support them.
To be charitable, though, I guess what most people mean by "NaCl is not open like Javascript" is that it's low-level--compiled binaries instead of readily-accessible script. And that's true; it exposes less to the user--and although it would be perfectly possible for every NaCl module to be debuggable through the browser with embedded symbols, just like Javascript is, it hasn't happened yet.
But you know, NaCl isn't for that, as far as I can tell. It's not a thing to write the business-domain logic of your web app in. It's far too clunky to develop with, if that were the intent.
Instead, what NaCl seems perfectly suited as, to me, is an architecture for writing pluggable scripting-language virtual machines. In other words, to give freedom of choice to use a backend other than V8 to write your web app against. Java-in-the-browser, Ruby-in-the-browser, Erlang-in-the-browser; any of those would be possible, and just as transparent+useful as Javascript-in-the-browser (in fact, V8 itself could be lifted out to being just another NaCl module.) And since the site would deliver the "runtime" for the scripts itself[1], any compatible browser could pull it down and execute it, instead of waiting for IE, Firefox, Chrome, etc. to all adopt the new language before anyone can start using it (a Sisyphean wait.)
There's already one perfect example of how this all would work: Adobe Flash. Flash is, in Chrome at least, an NaCl (PPAPI) module. Now, Flash isn't a shining example of openness--but using a custom interpreter is not where it goes wrong.[2] You can easily imagine Flash without that problem: a world where you can have and the Flash runtime will reach in and execute that code, just like the Javascript runtime reaches in and executes your JS.
---
[1] This doesn't necessarily have to be true, though. The browser can come with default language runtime modules, and then the webapp can suggest a site-specific runtime module, but the browser doesn't have to take that suggestion. Which is exactly the way a thing that is considered "open" on the web works: fonts! Think of an NaCl module as being no more or less than a custom @font-face rule for the execution of a script.
[2] Flash goes wrong by embedding its programs into proprietary binary asset packages [SWFs]; goes wrong again by drawing everything onto a single canvas, not allowing for anything like DOM manipulation; and then goes wrong a third time by having only one de-facto implementation with no open standard.