C# and VB are open sourced

Posted on by

For literally years now the Roslyn team has been considering whether or not to release the C# and VB analyzers as open source projects, and so I was very happy but not particularly surprised to watch on Channel 9 a few minutes ago Anders announce that Roslyn is now available on CodePlex.

What astonished me was that its not just a “reference” license, but a full on liberal Apache 2.0 license. And then to have Miguel announce that Xamarin had already got Roslyn working on linux was gobsmacking.

Believe me, we cloned that repo immediately.

I’m still mulling over the consequences of this awesome announcement; I’m watching Soma discuss Roslyn on Channel 9 right now, and Anders is coming up again soon for a Q&A session. (At 12:10 Pacific Daylight Time, here.)

I am also on a personal level very excited and a little nervous to finally have a product that I spent years of my life working on widely available in source code form. Since I always knew that open sourcing was a possibility I tried to write my portions of it as cleanly and clearly as possible; hopefully I succeeded.

Congratulations to the whole Roslyn team, and thanks for taking this big bold step into the open source world.

52 thoughts on “C# and VB are open sourced”

    • I think this is very true. For libraries or products intended for developers to use, having the source encourages trust, maintains interest, and does more to keep the code flexible in the direction that its users want than any amount of focus groups or market research can hope to achieve.

      It promotes the organic growth that is crucial for any large piece of software to be great.

      Reply ↓

  4. That is very cool; congratulations.

    If you’re so inclined, I’d love to see you pick a few parts of Roslyn that you found especially interesting or enjoyable and review them on your blog (or, perhaps, revisit some of your previous articles with code-in-hand). With the source being open, you can include extracts and references without worry of some kind of legal violation.

    Reply ↓

    • No doubt. One of the Build speakers said that in DevDiv the attitude is now “we need a good reason to NOT open source a library”. That is a complete 180 from how things were even a few years ago.

      Reply ↓

      • To what extent does open-sourcing constitute documentation of (and commitment to) implementation details and associated quirky corner-cases, and to what extent can code still say “Even though this code will have predictable effects in various cases whose behavior is not defined by specification, programmers should not assume that future versions of the code will continue to have such effects.” On the one hand, if a method has various tricky but potentially-useful corner cases, specifying the behavior by specifying the code may be easier and more accurate than trying to list all the corner cases. On the other hand, such specification may preclude a more efficient implementation. How does one decide not just what a method should do, but the extent to which its behavior should be specified, and–if the code is published–what aspects of behavior should be explicitly disclaimed as unspecified?

        Reply ↓

  6. With the NSA revelations in mind, I would argue this also increases confidence in the framework’s benevolent behavior, which may have been a factor of at least slight issue before.

    Reply ↓

  7. Is it too much to ask which parts you wrote, or contributed the most to? I’m personally interested in seeing and learning from your coding and design style.

    Reply ↓

    • Everyone works on a little bit of everything, but most of my work was in the semantic analyzer. That is, anything that happens after lexing and parsing, and before code generation.

      Having not looked at the code for over a year, it’s undoubtedly been reorganized and rewritten. I’ve cloned it but haven’t read it yet; I’ll look over the code next week and see if there’s anything I want particularly to call out.

      Reply ↓

      • In BUILD 2014 they mentioned .NET Native where IL code is passed to the VC++ backend compiler and getting highly optimised code. Anders said that this was “cool” and it was on their “wish list” for a long time. I recall in one of Charles “expert-to-expert” talk with you (and Erik Meijer) that its getting harder to maintain the “old technology” used behind the C# and VB compilers at the time of the interview and that the Roslyn project was suppose to take the place of the “old” technology of C# and VB compilers. Does this mean a 180 degree turn-around from the use of VC++ based compilers (based on the preview of .NET Native) and that VC++-based compilers still have a use and Roslyn will be meant for other uses?

        Reply ↓

        • The C# compiler, including the reimplementation codenamed Roslyn, is in the business of consuming source code and producing MSIL.

          @Antonio, why do you think that competes with, replaces, or inhibits the use of a better optimizing compiler for the MSIL->machine code step?

          Reply ↓

          • In SemanticModel.cs there’s a commented block as : Consider the following example:

            public class Base
            {
            protected void M() { }
            }
            public class Derived : Base
            {
            void Test(Base b)
            {
            b.M(); // Error – cannot access protected member
            base.M();
            }
            }

            I wonder where I’ve seen that before. (-:

  8. Since I always knew that open sourcing was a possibility I tried to write my portions of it as cleanly and clearly as possible.

    Whereas, for closed-source products, you do what exactly?

    🙂

    Reply ↓

    • Well, consider the following choice:

      (1) take an idiomatically-written-in-C, messy but efficient and correct algorithm from the original compiler. Port it over line-for-line to C#; do not bother to make it idiomatic C#.

      (2) Refactor the algorithm into idiomatic C#, but go no further.

      (3) Rewrite the algorithm from scratch to match the style and conventions of the Roslyn codebase.

      These are in order of both increasing cost and increasing likelihood of introducing a subtle bug — particularly a subtle incompatibility between the original compiler and the Roslyn compiler.

      My personal “sweet spot” preference was (2), but the guidance I got from the architects and managers of the Roslyn team was consistently to go for (3), even if it meant taking more time, writing more tests, spending more money and running higher risks. Had the project been closed source, if the only people who would bear the penalty of doing a merely “good enough” job were insiders, then (1) or (2) might have been the wiser choice.

      Reply ↓

      • I think that’s great, personally. I love it when management support keeping the codebase clean and modern.

        Bugs in a clean codebase can be fixed, but a messy codebase is very hard to tidy up piecemeal. You never get it as good.

        Reply ↓

  9. Was the only way Microsoft could get you to carry on contributing to Roslyn. Expect them to start assigning you issues on codeplex imminently.

    Reply ↓

  10. Isn’t it funny that code quality suddenly rises when you expect that important people, or large amounts of people, will scrutinize your work? This forces the last bit of laziness out of a developers working process.

    Reply ↓

    • I must say that the code is of *very* high quality.

      And I did not realize that the compiler contains a non-trivial XML parser to parse XML comments 🙂

      Reply ↓

  11. Pingback: It’s a great day to be a .Net developer | Caffeinated Geek.ca

  13. Does that mean your default answer to “Why doesn’t C# do X?” will now be followed by “… but feel free to implement it yourself”?

    Reply ↓

  15. Yes!!! I’ve got a few mates who are big Java fans, and I’ve been fighting this uphill battle: they admit that C# is a more powerful language *but*! It’s not free, not open source, and made by Microsoft (the Enemy, the Evil Empire of the Software Universe, etc.) 🙂
    Now my time has come! C# *is* now free and open soucre, it *is* multi-platform, and it’s still more powerful than Java! Hooray! Victory!!!

    Reply ↓

    • When confronted with this, I tend to point out that Java is very much owned by Oracle, and that there are ISO standards for earlier versions of both C# and the CLI.

      Reply ↓

  17. Pingback: C# – Я свободен! | klnhomealone

  19. Fortunately Apache 2.0 does not protect integrators of Roslyn from infringing Microsoft patents. So the implementation is freed from copyright hassles, but if you create your next .NET based set-top-box that competes with Xbox, you might be screwed by MS if you grew too big.

    Reply ↓

    • Apache 2.0 does protect against patents that are used in the licensed work, I believe. Just not against any and all MS’s patents (that would be crazy). The patent issue was one of the reasons Linux distributions were hesitant to include Mono, but it seems to me now that that would no longer be a valid reason.

      Reply ↓

  20. Pingback: Dew Drop – April 4, 2014 (#1758) | Morning Dew

  21. This, and .NET native, and (finally!) SIMD via RyuJIT…I’m quite excited to be a C# developer right now 🙂

    Reply ↓

  22. What makes you “a little nervous”?
    The fact that the code you wrote will be analyzed, reviewed and scrutinized by thousands of experienced developers that will blame you for any minor or major mistake?
    Not considering the crowds of black hat hackers that will exploit any single security vulnerability you caused… 🙂

    Reply ↓

  24. Pingback: Top 10 | Links of the Week #10 | 04/11/2014 | The SoftFluent Blog

  25. “Xamarin had already got Roslyn working on linux was gobsmacking.”

    What does this mean for Mono? Should we expect Mono to revive and replace code with Roslyn?

    Reply ↓

  26. Pingback: C# and VB are open sourced | Fabulous Adventures In Coding « The Wiert Corner – irregular stream of stuff

  27. Visual Studio 2013 Professional required for compilation ? Could that be a bit of a barrier to entry ?

    Reply ↓

  28. Pingback: Comment commentary | Fabulous adventures in coding

Leave a comment