I am not a language specialist, so a lot of the technical terms used on the various proposed solutions eludes me.
However, I am a markets & investment specialist - so can predict the organizational strategies that will gain traction vs. those that will not.
Ultimately, JetBrains' advantage over the past decade has been their consolidation of language services into a platform that lets them build one kind of IDE repeatedly - each with different flavors.
Their vulnerability is that their language services libraries are core / private, and not something they would really want to be widely used, as that would enable others to slowly unseat their tooling advantage.
If we want to be successful going down the path, the advantage is in having a project with the language services, available for a variety of local / remote protocols, that is cross-company with defined levels of interoperability. You generally will want this to be seen as independent of any single editor and to include companies that have products competitive to the Eclipse Foundation. So be careful about initiatives that are embedded in the Eclipse Platform, or like Orion which is providing Tern _javascript_ services for Orion + Eclipse, but not Sublime or Che or VS Code. These efforts ultimately become very important proofs of concepts, but lose out on the ultimate goal. And I think your ultimate goal is to have language services built by the Eclipse Foundation powering every tool.
The influence of the end customer is strong with the UX part, but with UX being fluid and developers demanding choice of tools, there is no way for a single tooling solution to every gain plurality of share again. But it is possible to have plurality of share on language services, the interoperability protocol between tool + service, and how the language services move / upgrade / operate.
Some qualities that I'd be thinking about:
1. Independent project, something like Eclipse Language Services.
2. Provides common way to plug-in additional language services.
3. Interoperability protocol for local + remote access with pluggable protocols.
4. There are already 4 possible protocols: VS Code's stdin / stdout, Che's RESTful, Orion's RESTful, and Eclipse's SDK binding (essentially in-memory) -- you want to consolidate where possible and provide minimum, but complete choice set. Community definition is essential here because a key goal would be to recruit new tool providers to consume these interfaces. If the interfaces are too biased to a particular tool ideal, then it will be difficult to create ecosystem.
5. Adapters for popular tools - let it be Eclipse / VS Code / Che / Sublime ... so that you can see multi-language support over common protocol in a single tool.
6. Switching - some standard way to fluidly move between usage of a local language service vs. a remote one (assuming each are installed + configured).
While there is a mixed set of views on how pair programming scenarios should be handled (peer - peer) or (server-based operational transform), you could provide this as some sort of other project. I think there are two models - a centralized pair-programming server where tools can register their workspaces + users into the server allowing the server to orchestrate communications. This would need to be embeddable such that Eclipse or Che could ship it as part of its server. Or it could be some sort of client plug-in, which allows one client to peer-peer connect with others.
Tyler
