On April 3, 2014, Anders Hejlsberg set us on our open source journey when he made the .NET Compiler Platform (aka “Roslyn”) source code public live on stage in San Francisco. Without much open source experience to guide us (or a Grey Wizard), we anxiously yet excitedly hit the open roads. This post details the real and true story of the trials and triumphs we’ve experienced in Roslyn’s first year of open source.

The Call to Adventure

Previously, in order for developers to build a code-focused tool or application they would have to develop their own semantic analysis engine that would imitate what our compiler would do. Guessing how the “black box” of the compiler works is expensive, time intensive, and doesn’t always lead to the correct behavior. We built Roslyn in order to remedy this problem by re-architecting our compiler as a platform. Providing APIs for the compiler platform lowers the barrier-to-entry for developers to build all sorts of code-based innovations: meta-programming, interactive use of C# and VB, code generation/transformation, code analysis, refactoring, and more. With this goal in mind, our team began our work on redesigning the C# and VB compilers in 2009.

Crossing the Threshold

The decision to make Roslyn open source did not come out of the blue. In our original architecture discussions in 2009, we dreamt of open sourcing our language compilers. Access to the platform source code as well as the APIs would empower developers to take their code-based innovations to a whole new level and explore new depths. Our vision enabled us to proactively define principles that would make it easier to go open source if that’s what we decided to do in the future.

Despite this dream of going open source, we didn’t cross the threshold until about five years later. We saw the success the F#, ASP.NET, and TypeScript teams experienced with their open source approach and we quickly followed in their footsteps at Build in 2014.

Trial and First Failure

When we began this journey in April 2014, we did not have a specific map to follow. Instead, we decided to find our path in the open—allowing everyone to see us stumble into Rivendell, dredge through the snowstorms on Caradhras, and explore every cave and nook and cranny in our search for the perfect path. We took a risk with this “learning in the open” approach, but we believed in establishing an open development process from the start. Luckily, the community has been extremely supportive with helping us find the best course-corrections.

Naturally, we didn’t avoid all the cobwebs or snowstorms in our pathfinding. But our open strategy allowed us to catch our mistakes early and adjust to find better ways to manage our project. For example, we now publish our language design notes each week, test our external build scripts, and increase our responsiveness to issues/questions

Meeting Allies

Along the way we have made some great allies (we love dwarves, hobbits, elves, and mankind!) who have really helped and supported us along this journey. The immediate community feedback on our Language Design Notes was vital in some of the decisions we made for VB14 and C# 6.0. For example, this discussion made us realize we had to yank primary constructors. We also gained valuable insights into null-conditional operator syntax and string-interpolation.

Furthermore, the community has already made some truly awesome tools. Here is a sample of community-driven projects that are a part of The Fellowship of the Roslyn Project:

• C# Pad is an interactive shell that lets you run and execute C# in your browser.
• CodeConnect.io creates visualizations of your call stack at design-time and includes refactoring and search features.
• DuoCode cross compiles your C# 6.0 code into JavaScript code
• LINQPad.CodeAnalysis is a library that adds capabilities to LINQPad to make it easier to work with Roslyn.
• Mono/Roslyn is a cross-platform, open source implementation of the .NET Framework.
• OzCode v2.0 uses Roslyn to provide magical debugging experiences.
• Scrawl by FluentCo.de is a light-weight editor for modern web developers.
• scriptcs is an open source project that lets you use C# as a scripting language and provides a command-line C# REPL.
• Try Roslyn demonstrates Roslyn and shows how to repro a compiler bug.
• WebEssentials Markdown editor is powered by Roslyn.

Based on the quantity and quality of projects in the community that use Roslyn, it is clear we made the right move by open sourcing our platform.

Growth & New Skills

We originally put our source code on CodePlex because it was fast and easy to do–as well as the established “place” for Microsoft open projects at the time. However, many of you told us that you would prefer GitHub as a platform and so we moved our source there.

When we moved we also changed our workflow to follow some of the best practices we saw other Microsoft teams using. Before the move, we were using a “source open with limited contributions” model. This means that our issue tracking and code review system were all internal and while we made an effort to bring community contributions into our code base, we did not directly merge their code (instead we copy/pasted their code and merged it ourselves).

Since our move, we have adopted a “fully open source” model where we are developing and working entirely in the open. We file bugs and design notes in GitHub’s issue tracking system and submit all of our code changes as pull-requests. We use GitHub’s code review system as our own and use Markdown to link issues or communicate about code. We also established a crisper idea of what we accept for pull-requests, what sign-offs we require for pull-requests to be merged, what style guide we recommend, and what an acceptable time frame for closing a pull-request is (roughly 10 days, if you were wondering).

This workflow change was critical in getting widespread community participation. By making core committers on the team follow the same code submission process as everyone else in the community we democratized participation in the project and increased the levels of transparency. And now, gone are the days of users telling us what they want and not knowing when it’s going to get done! Developers can look at our issue tracker and see if anyone has started working on their issues yet. Issues are assigned to milestones to communicate our prioritization—which is always up for discussion or up-for-grabs.

Transformation

Moving to a workflow that has our team working in the open as much as possible and using the same contribution model as the community has allowed us to almost double our community engagement in a third of the time:

Our user base for Roslyn is also steadily increasing (the more the merrier!). This graph illustrates how our pull-request users and issue-logging users are growing since our new model:

Here are some additional statistics on our response-rates and engagement that we track to ensure our core team is suitably prioritizing acceptance of code over net-new development:

Our response rate for issues is half that for pull-requests—which is expected due to our high volume of incoming issues! Regardless, we are happy with these numbers and are always looking for ways to make them better.

We have also been open sourcing more code. Since January we have open sourced three more components of our platform:

• Scripting
• Expression Evaluators
• Visual Studio Language Services

Our Interactive design meeting notes are also now in the open.

Acceptance

With the first year of our journey under our belt, there is still plenty more to do. Currently, we are trying to iron out some finer details on our open source system. To start, we still haven’t ported our historical issues from CodePlex into GitHub. We also haven’t really figured out labeling for issues on GitHub and we’d love a way that we could make labelling more democratic:

I inspired a new issue label in #Roslyn! https://t.co/jNjT1c0hdv

— Schabse Laks (@Schabse) March 15, 2015

Also we need to figure out how we map commits to different product releases. How do we best communicate what code has made it into which release, product, or NuGet package? Do you have any ideas on how to make this clear, transparent but democratic without polluting the history too much?

To top it off, we are working on making it easier for F5 builds to pick up the changes you made to the compiler and workspace layer.

The Road Ahead

We still have a long road ahead (fraught with who knows what perils?) but the journey has been thrilling so far. We cannot thank the community enough: thank you, thank you, thank you! You all have created fabulous technologies already with Roslyn and your quality feedback and code contributions have been critical to our success. As Galadriel reminds us, “Even the smallest [pull-request] can change the course of the future.” It has also been an absolute pleasure getting to work and know you all better through Gitter, GitHub, Twitter, etc. So thank you all for being our very own Samwise Gamgees and wish us well on the remainder of this journey! For those of you who haven’t joined our fellowship, check us out and help us on our journey into Year Two.

“End? No, the journey doesn’t end here.”

— Gandalf, The Lord of the Rings, J.R.R. Tolkien

Kasey Uhlenhuth, Program Manager, Managed Languages Team