How the Omnisharp roadmap affects .NET in Cooperations

Published on Saturday, June 18, 2022

The announcement to make the LSP server host of OmniSharp closed source hits me hard. I cannot understand why the DevDiv leadership of Microsoft is so willingly and ongoingly destroying the reputation of .NET (Core). .NET Core is one of the three core pillars (VS Code, TypeScript and .NET Core) which generated respect for Microsoft in the wider programming community within the last 10 years.

I am a .NET fanboy but I have a perspective on the broader spectrum of programming languages. I am an architect, decision maker/influencer and regularly involved in questions on whether Visual Studio Subscriptions are needed. I am not in a Microsoft shop, I am not in the silicon valley and I am in a conservative polyglot business.

Note: See Update in Appendix U

What defines a state of the art programming language

In the past, programming languages consisted of a runtime, compiler and debugger. Microsoft's own Anders Hejlsberg (of Pascal, C#, TypeScript) explained in an awesome video named "Modern Compiler Construction" how previously considered IDE features like code completion, syntax highlighting, code analysis or code refactoring are now part of the compiler. C# (Roslyn) and especially TypeScript have been (modern day) forerunners of this. This combined with the general industry adoption of the language server protocol developed by the VS Code (Monaco?) team basically defines what a modern programming language is:

  • A modern, modular, non-black-box compiler
  • A debugger
  • A rich out-of-the-box library and runtime
  • A LSP server written in the same programming language

.NET is awesome in all of them: The compiler is awesome, the debugger is awesome, the base class library is awesome and the LSP server ... well ... is there. But make no mistake: The other languages have this whole portfolio as well or are on the way there (Java, JavaScript/TS, Python, Go, Rust, PHP, ...).

The core attribute of most application programming languages is developer productivity. But that is a full spectrum reaching from simple auto-completion to AI-guided auto-coding. For me the hierarchy is the following

Basic Productivity

  1. Syntax Highlighting
  2. Meaningful errors during compilation / editing
  3. Debugging (stepping, breakpoints, ...)
  4. Correct context specific auto-completion (as in IntelliSense)
  5. Code Navigation
  6. Refactoring / Code Fixes

Advanced Productivity

  1. Advanced Debugging (as in IntelliTrace, break and edit, hot reload, ...)
  2. AI / statistical guidance (as in GitHub CoPilot, IntelliCode, ...)

Super Advanced Productivity

  1. Visual Designers (remember why we bought Visual Studio in the 90s)

Everything in basic productivity is in 2022 elementary state of the art and comes for free (rhetorically up to here: free as in beer).

What makes a programming language adopted in a coorperation?

When making decisions about programming languages, we decision makers have to consider ...

hard factors

  • The Architect asks: Does the programming language fullfill the needs?
  • The R&D lead asks: Can I hire easily for this programming language? Does my team know this language?

soft factors

  • The Apple, Linux, Web, or Windows fanboy / IT admin asks: Does it run on my platform?
  • The R&D lead asks: Do I need licenses for it?
  • The careful person asks: Is it free software? Is it Open Source Software? Can I own it? Can I rely on it?

So in a free choice situation it boils down to these soft decision factors.

On platform coverage: The gigantic success of VS Code and .NET Core have opened up the platform coverage topic for C#/F#. .NET can freely compete with Java due to this.

The actual trigger for the announcement is further investment into that. That is good and everyone likes it.

On licenses: For C#/F# we could always argue that there is VS Code and Omnisharp and "everything" is MIT licensed. We decision maker buy anyway the Visual Studio licenses because of increased productivity. The same applies with Java on the Eclipse / JetBrains IntelliJ split.

And the trigger for the announcement is further investment into that. That is good and everyone likes it.

However, there is the fundamental split between basic productivity and advanced productivity and our willingness to pay for it.

✅ Are we willing to pay for advanced productivity? Answer: Yes! Evidence: Many many Visual Studio and JetBrains subscription.

❌ Are we willing to pay for basic productivity? Answer: No! Evidence: Adoption of Omnisharp and Creation of Visual Studio Community.

Why we do not pay for basic productivity features: because it is 2022 and there are excellent alternatives out there. Java has all the whistles and most others have at least the basic productivity features.

On open vs. closed source: How deep can I inspect it when something misbehaves? Can I fix it? Am I dependent and locked on a single vendor (for price hickups, discontinuations, ...)? Can I archive the package for 30 years and fix it myself? Is it secure?

❌ All of these questions flip with this announcement. There is no trust in big cooperations to either discontinue a product, not care about a product or extort money from us developers. We developer got burned by Apple, Google and Microsoft on every opportunity when it comes to this. The only trust establishing situation is real open source. For basic productivity the full end to end stack needs to be open source (incl. debugger and "LSP Tools Host") as in MIT/Apache/GPL licensed or viable alternatives needs to be present (as in Eclipse for Java). Advanced productivity can be always be optional from this safeguarding perspective.

A way out

This is the simple part

  1. Make the "LSP Tools Host" and the .NET debugger open source (license wise).
  2. Make both of them pluggable with Microsoft commercial plugins for the advanced productivity. I know, especially for the debugger, that this is an hard thing.
  3. Sell us a "C# (Commercial)" with advanced productivity edition next a fully free "C# (Community)" with basic productivity edition (free as in beer AND in open source license).

I do not see how Microsoft can loose intellectual property, thought leadership or market share to anyone else. Not on the short term and not on the long term when trust is established. We talk here communication bridges and adapters.

Considering, what happenend with Pylance (and IMHO PHP language server): The above should be a playbook for any language not only .NET/C#/F#.

Appendix A: An architecture side note

  • There is an awesome LSP protocol client/server library as part of the OmniSharp library. No matter what, do not close source this even if it is extended by proprietary Microsoft extensions. It is a human readable protocol. The .NET community builds language servers beyond just the languages C#/F#.
  • Do not break the Roslyn project and the public availability of code analyzers/fixes (and other aspects of the "Modern Compiler Construction"). It is a modern compiler and not only an AST exporter.
  • I assume the "LSP Tool Host" is nothing else than interacting with and editor based on text via LSP/DSP and then forwarding the events into the commercial and non-commercial plugins. Why is a stable, reliable, easy, multi-provider language/debugging server such a secret. Especially when the DSP and LSP are such a thin wrapper around human-eye visible, standardized text editor features.

Appendix D: Disclaimers

  • I am not speaking for my employer
  • I am not advocating in favor of free software vs. open source software. MIT is for me, in this local context free software.

Appendix E: An ethical side note

  • There are countless contributors who have contributed to OmniSharp, Hot Reload and the .NET Foundation (as an entity). Do not screw them. Do not steal their work (intelectionally, morally, reputation or physically).
  • We developers very well accept Microsoft's need to earn money. Go Open Core with .NET. Be open about it, be smart about it (see all of above) and include the community on the road. We developer have zero tolerance for this kind of messaging (remember: we deal with a CPU who is not ambivalent in its outcome: it is either true or false) where we are told half of the relevant information. We are now in the third communication debacle within a year (.NET Foundation, Hot Reload, "LSP Tools Host") just because Microsoft management is not willing to tell us their roadmap and real intention.

Appendix U: Update in December 2023

A year into the new license change and the release of the C# Dev Kit, I am happy to oberserve that Microsoft seems to have listened to the community and kept the LSP Server Host open source, and released a MIT licensed "C#" plugin and a commercial "C# DevKit". This is really good. I am still in hope they realize that the money is with visual designers and one day we get model Apps like we did for WinForms.

We are still waiting for the debugger.