Eclipse Che is doing pretty well. Approaching 20,000 usage hours every day from telemetry, up from a couple hundred at the beginning of the year.
Eclipse Che is focused on the dev infrastructure. It's about making the workspace completely portable and provisioned on any system without any effort from developers to have to set it up.
Lots of use cases:
1. Hosted workspaces with workspace project sync - we provide a che-mount capability for this and it's based upon a fuse file system with unison sync. It can be fine-tuned with excludes and dual unison clients in such a way where the performance is really screaming.
2. Migration of workspaces from location to location for purposes of backup and recovery.
3. Having workspaces match their production topology, so that developers are working on a workspace that is identical to their production deployment. This requires workspace runtimes that are constructed by orchestrators like compose or other syntax.
4. The commonly discussed situations with instructors or team leaders setting up a workspace template which is used by others to facilitate getting started quicker. We are about to launch a team capability that allows a team leader to define a basic template of a workspace that is defined by stacks, composefile structures, and other meta data, but more importantly it explicitly states the aspects that are personal to each developer, so as each developer creates their own workspace replica from the template, they have to populate it with their personal information such as SSH keys, oauth access, database credentials and so forth.
5. Big software vendors value the extensibility of the che platform because there are many products that need workspaces inside of their products, and they would rather customize an off the shelf product vs. build their own.
6. Better agile. Context-sensitive pull requests, git issues, git repositories, issues, and CI jobs - opening a context-aware workspace is a big deal. We do a lot of enterprise customers that focus on those cases. It's hard to set this up on a desktop or with vagrant.
We try to stay out of the IDE conflict. We are happy to work with any desktop IDE or provide our own for those that don't want to install something. But we are close to a future where each workspace can host multiple IDEs at the same time, including desktop IDEs that are pre-configured to work with the workspace configuration.
The point is that if you sit 5 developers around the table and ask them if they want to code in the browser, you can anticipate the response that you will get.
But if you sit 5 development teams around the table and ask them about problems they have with developer onboarding, agile team management, collaboration, developer support, vagrant and using VMs / virtual labs as development environments, then suddenly there are a lot of pains around the table.
We think Che is doing really well because we have tapped into this particular need with some efficiency. And we consciously try to avoid being the world's best IDE because of the issues stated previously.
Also, with the language server protocol that we announced with Microsoft and Red Hat this summer, it has really taken off. I can see us having support for 20 languages with intellisense + debugging by the end of Q1. It allows the language providers to maintain really good intellisense and we provide the infrastructure around that. And then we can focus on workspace provisioning and giving developers access (without installing software) to intellisense for the languages they love. And 90% of the world is covered by the 75% capabilities of most language servers on the market. So we can be increasingly language and tooling agnostic, while providing great services to teams.
Along these lines, we have a new team management offering shipping in a few weeks, not to mention Che 5 - which we'll announce at CheConf. And CheConf is our first users conference that we are holding on 11/15, and after two weeks of promotion, we are pretty stunned that we are approaching 1500 registrations.