We did a massive rewrite last year (https://c9.io/blog/announcing-the-all-new-cloud9-development...). We adopted a new plugin system and started with a completely new, clean code base. We ported the old plugins one by one, optimizing them and fitting them into the new system, and actually throwing out quite a few of them entirely. So the code is actually rather clean. But note that this figure includes code for a lot of backend systems that are part of the Cloud9 service infrastructure, such as backup workers and container management code, as well as code for partners and plugins that are not exposed to the normal user base.
The URL is very similar but notice how the subdomain differs. The outer Cloud9 runs on (ide.)cloud9-lennartcl.c9.io. It responds on that URL and on *.cloud9-lennartcl.c9.io. That's where the inner Cloud9 runs: (ide.)cloud9-lennartcl.cloud9-lennartcl.c9.io. Visit that URL and you actually go through 3 proxies: the production proxy of c9.io and those of two inner instances. And note that the user names look the same in this case in this case, but that's really just for symmetry; ide.cloud9-2-lennartcl-2.cloud9-lennartcl.c9.io would have looked too awkward :) Each instance can have its own database with user names and workspaces. And each workspace runs in its own container.
In this case the tech team recently switched to Ghost for blogging and didn't realize that it doesn't automatically scale images when you upload them :)
You have good eyes :) The screenshot uses the "legacy" white theme that didn't have the flat look yet. It did have a few more dark colors at the edges, which is why it was used for this screenshot. We plan to work with our designer on darker versions of the flat light theme. Until we release those, I can recommend using something like f.lux (https://justgetflux.com/) to make it nicer to work with bright web sites and applications in low-light conditions.
Ahh Enterprise. Protip for anyone applying for an enterprise job: just copy-paste https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... when they do the mandatory fizzbuzz test in the job interview. And then complain in the github issue tracker if you didn't get the job.
As you can imagine we're getting a big load of traffic on release day. Which is fine; we have many servers hosting these containers. Some new ones are being spawned as the traffic increases. What we're finding now, though, is that we need to tune our load balancing logic, especially for the scenario where many new users show up. This requires the use of some other metrics than the "normal" scenario with many users leaving their workspace for several hours and then coming back. Right now there is one host in particular that has more users on it than it reasonably should. But, in short, we're working on making it better :)
The new version is based on a completely new code base. We have a new core and eventually ported and rewrote most of the old plugins one by one. We're working on the APIs and documentation right now and want to bring the new version to github again pretty soon.
The new version absolutely has SSH workspaces. You can SSH into your own machine or get an SSH box from e.g. digitalocean.com and use that with Cloud9 if you like.
It's definitely possible to have a server-side component for doing that kind of stuff, and that has been something we've been experimenting with ourselves. The interface for these services is already fully asynchronous, which helps communication with a server component, but it still requires some manual work for the network communication and marshalling.