Perception is Reality–The state of OSS in .NET

A response to Amir Rajan’s post that .NET OSS is DOA.

The history of OSS in .NET is a long and winding road. It involves many different champions in the community, many different teams in Microsoft, and a very interesting sea change in the attitude towards OSS in large organizations.

At one point, MS employees were not allowed to look at OSS tools for fear of getting sued. This resulted in straight-up duplicate tools/frameworks/libraries being developed by Microsoft when there was no clear differentiator/advantage to the OSS tool that clearly dominated the space. This is really the Dark Ages of OSS at Microsoft, where these tools were created:

  • MSBuild over NAnt
  • MSTest over NUnit
  • TFS Source Control over SVN
  • EF over NHibernate

All of the tools on the right were clear “winners” in their respective space, and the tools on the left were more or less copies of the functionality the frameworks on the right provided. Some are less copies (EF has a LONG and interesting history, spanning multiple teams and even organizations).

I remember conversations with the PM on MSTest at ALT.NET Seattle many years ago, where a room full of NUnit/TestDriven.NET users were asking why MSTest was even created, as it was much, much slower and had fewer features than NUnit (and required a specific SKU in Visual Studio). The reality was that at the time MSTest was developed, its developers were not even allowed to look at NUnit for fear of accidentally copying some functionality.

That was the reality back then, and the ALT.NET movement arose as a (temporarily) unified voice to more or less let Microsoft be aware that there is a set of OSS practitioners in .NET, they are getting upset at the direction of MS tooling, and that they were in danger of losing many of the “Alphas” to other frameworks and platforms, particularly Ruby and Rails.

And then a lot of stuff happened

Microsoft is a container ship. It doesn’t turn on a dime, nickel, quarter, or even elephant. Shifting the attitudes and realities of such a disparate set of teams is really, really hard. You might have one team that embraces OSS rather quickly (ASP.NET) and some that might never (SQL).

It’s a complex group, but one thing is very, very clear: OSS is .NET is getting better. It has been getting better for many, many years, and will continue to get better.

A few examples.

jQuery has been fully supported by Microsoft, and they have abandoned their own library (ASP.NET Ajax), which was a direct competitor but inferior tool.

ASP.NET MVC is fully open source, accepting community contributions. You might wonder why ASP.NET MVC is even around, when another MVC tool existed at the time: Castle Monorail. To anyone that has actually used Castle Monorail, there is no mystery. ASP.NET MVC and Monorail aren’t direct competitors – they’re solving similar problems in different ways, and Monorail goes a lot further to provide a similar experience to Ruby on Rails.

.NET FINALLY has a package manager with NuGet. The OSS community had been trying for *years* to create a package manager. Some were more successful (OpenWrap), but there was no clear “winner”. I remember conversations at ALT.NET conferences about building a package manager, or using Gems, but nothing won. NuGet is fully open source, accepting community contributions.

A project that actually started as a side OSS project by an MS team member on GitHub is now a core part of ASP.NET (SignalR). This was UNTHINKABLE just a few years ago.

ASP.NET Web API started completely open source, back when it was WCF Rest Toolkit. Instead of re-inventing JSON seralization, the Web API team picked the clear “winner” in the .NET community, the OSS library JSON.NET. Again, this is a complete 180 degree turn from the previous decade.

What about those other tools?

Amir’s post talks about MS creating Web API instead of just going with the clear “winner”. Besides his timeline being just plain wrong (that blank space where “nothing was happening”…plenty was happening). He gives examples of Ruby tools:

  • RSpec
  • Sinatra

And that for some reason .NET developers should have just “jumped on board” building clones of those other frameworks. Do you know what .NET OSS developers were doing during that time? Actually using those Ruby tools!

Early on the OSS period in .NET, cloning was the norm. One just has to look at all the OSS tools that have a Java counterpart (jUnit, NUnit, Hibernate, NHibernate, Ant, NAnt). At .NET conferences I went to during that period, those other Ruby tools were being demonstrated. Some were cloned early (NBehave was an early clone of RBehave/RSpec), but TOO early because it wasn’t clear those tools had real value in .NET. I remember seeing demos of Sinatra years ago, and a lot of .NET developers telling each other, “we should have that in .NET!” Well, now we do, and have for quite a long time, and a much better version than a copycat could have been.

I don’t know how one makes the leap that Web API is a competitor to Nancy, but to call OSS DOA because of one dissimilar tool that didn’t “win” is absurd to the point of insulting to those actually working to further OSS in .NET. Service Stack and Nancy shouldn’t be compared to Web API, because they’re solving different problems in very, very different ways. If they were the better ways to solve the same problem, then they would have “won”. The timeline also ignores other OSS competitors that worked better with existing frameworks (Restfulie, for example).

You can point to your favorite tool and think it should dominate the space, but that’s really just an opinion. Plenty of OSS tools dominate spaces in the .NET ecosystem. But if you’re trying to create or promote a tool in an already a crowded space, you should really, really reset your expectations.

Calling OSS DOA because MS didn’t embrace Nancy or Service Stack or SASS/LESS is sorely misguided and dismisses the real work that has been going on for years in the .NET OSS community. OSS still has a ways to go in .NET, but the right people are in place, and more importantly, the right attitudes are in place at Microsoft. The long history of OSS in .NET is a murky one, but the present is clear and the future is bright.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Community, OSS. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

    Agreed 100%. You can also speak about the frameworks debugging symbols (most of them) available for all. It’s not OSS but it’s a big step also.

  • Excellent post. You could have mentioned TypeScript too, since it’s built in a way that fits in a general Javascript-centered workflow (e.g. by building the compiler itself in javascript, using npm, etc).

    What is still lacking from MS, and what will probably never really happen, is the embrace of C#/.NET as a truly portable, cross-platform language. Sure, it’s cross-platform, but the platforms are all Windows-based.

    Clearly Xamarin is doing a great job on Mono, but it’s still not Microsoft actually doing it.

    On the JVM side there’s *so much* cool stuff happening in the realm of server-side whereas on the .NET side there seems to be much less traction.

  • Jay Tuley

    I would says that Microsoft is embracing SASS and LESS now.
    “LESS, CoffeeScript, SCSS, Sass Bundling.”

  • darrencauthon

    I agree that OSS in .Net continues to get better, and that it’s poised to get even better in the future.

    But even given these improvements, the truth is that OSS is still marginal compared to what comes out of MS with respect to acceptance and community support. Releasing certain Microsoft products as “open source” doesn’t change the fact that Microsoft is driving them, not the OSS community. And I don’t know if accepting things like jQuery is a matter of embracing OSS as much as it’s embracing reality. And… you can’t discount efforts like Typescript where Microsoft introduces the “Microsoft Way” to do Javascript in a world where Javascript is becoming more important. This attitude towards OSS is in stark contrast to other communities.

    The default reaction is that this is a bad thing, but it doesn’t have to be. Different companies and different developers look for different things. Those who need to be able to turn on a dime or elephant should look elsewhere, and those who are in places where… “consistency?”… is important, you found your tech. You’ll be a few years behind others, but that might be ok.

    As a developer with many years of .Net experience, I’ve found more peace jumping out of .Net to use the new stuff rather than trying to dragging them into .Net. It’s easier to just accept .Net for what it is, take what it gives you, and use other stuff when it doesn’t. Our lives and careers are too short trying to pound square pegs into round holes.

    • jbogard

      And that I think reflects that MS is a tanker ship, but it’s leading a horde of other tanker ships. The MS ship has turned, but it will still take time for companies to make that turn. MS endorsing non-MS built OSS tools went a LONG LONG way to helping that out (jQuery, JSON.Net), but yeah, those other companies are taking quite a long time to follow MS’s lead.

      • darrencauthon

        Jimmy, the “tanker ship” analogy cuts both ways.

        If Microsoft is a “tanker ship” that takes a long time to turn, how much effort must be put into creating efforts like the example I mentioned, Typescript? And if there’s that level of energy and effort to move in a completely different direction than the Javascript community and all of the OSS work there, have things really changed to the level you claim?

        There are plenty of other examples. Some as big as Typescript, and some as little as comments made (or not made) by Microsoft guests on podcasts *today*. You can cherry-pick examples and make a better case, but the truth is that this ship isn’t on the heading you think.

        Here’s another analogy: The 800-pound-man lost 100 pounds in a year with diet and exercise. Jimmy points to the 100 pounds and says he should be considered an example of health and fitness. The rest of us think the weight loss is great, too, but we think he still has a long way to go.

        • jbogard

          TypeScript is a bit different, I think. Most folks around me prefer CoffeeScript, basically infusing the “Ruby Way” in to JavaScript. I don’t see the difference between RoR making CoffeeScript the default and MS developing TypeScript.

          • darrencauthon

            The difference is that Coffeescript is an OSS project, created by, maintained by, and used by the community. It grew organically from nothing to being a very popular way to develop JS apps. If I’m not mistaken, Coffeescript is more popular on Github than even C#.

            So given this, when Microsoft looks at Javascript and decides how to work with it, their response is: Forget JS, forget OSS Coffeescript… what .Net devs need for “application-scale” Javascript development is a new language that Microsoft developed. And to make your life easier, your copy of Visual Studio will support it!

            Just because MS released the source for Typescript doesn’t mean it exists for the OSS community.

          • luisrudge

            I don’t see why are you ranting about typescript.
            It would make NO SENSE AT ALL to introduce coffeescript to c# devs. Can’t you see that? If a c# developer isn’t comfortable using javascript, how comfortable do you think he/she will be using coffeescript that has no similarity with c# at all? Typescript is trying to bring c# devs to the javascript world. That’s it.

          • darrencauthon

            I’m not ranting about Typescript; I’m talking about it as an example of a larger point in a polite discussion.

            C# programmers are not a flock of sheep that need shepherding into new areas by Microsoft. If a C# developer wants or needs to use Javascript, that’s great… do it. Learn Javascript, learn the techniques and methods used by professional Javascript developers, find ways to participate in that community, etc. The only reason I’d ever suggest Coffeescript to JS devs is that many JS devs use Coffeescript. This is a fact, not my opinion.

            What people who are interested in Javascript *don’t* do is find a way to make it look like their favorite programming language, and then write in that new form without ever writing Javascript directly.

            If Typescript was “trying to bring C# devs to the javascript world,” then wouldn’t it be a book or online course instead of a new language?

          • luisrudge

            Coffeescript is a new language. Typescript is not.

            You’re talking about c# developers in general as if they were all like us: engaged into learning more, communities and open source… This is wrong. Most of c# devs are dealing with legacy of webforms (with bad code or not) projects and simply don’t want to try javascript. Can you imagine this type of dev making any effort to learn js? I can’t. Can you imagine this type of dev wanting to learn coffeescript? Wow. I definitely can’t.
            I believe Microsoft created Typescript to move the web forward for this kind of devs.

            And let’s not forget that most of typescript features will be available in ES6.

          • darrencauthon

            It’s funny that you bring up Webforms while describing a Microsoft product designed to assist developers from one paradigm develop in another, all without directly learning it. Oh, but it’s different this time, it’s OSS! :)

          • luisrudge

            I’m not sure what is your point, actually. Web Forms moved web forward. BIG TIME. They brought a whole bunch of devs to the web world.

          • darrencauthon


          • luisrudge

            What? I don’t like web forms and i don’t use it, but i can’t say that people who use it are not productive. They probably aren’t building stuff we’re seeing or using, but they are building stuff. Maybe some intranet apps and LOB apps. But they are making a living of web development because of web forms. You should respect that.

          • TheArchitect

            Whatever you said about CoffeeScript is a complete fuss. I would suggest you to go and write a couple of programs in CS and then TypeScript & then come back & tell your thoughts. TS gives you powerful type inference, static + dynamic typing, interfaces and a “standardized” OOP system.
            Any IDE can run static code analysis on TS. TS isn’t only open source but also widely supported by almost all the JS tools including WebStorm. In fact WebStorm has more TS support than Visual Studio.
            Even if one masters the JavaScript, he will always find it hard to design a large maintainable system in JavaScript & in CoffeScript. Because none of these were designed to have those goals. Knowking TypeScript means you can design large scale systems with good maintainability support. Static code analysis is all about that. Most of TS syntax is the ES6 which is going to be the next generation JS after all.
            Whatever comes from MSFT isn’t evil.
            And finally sharing knowledge should be more important than ranting on internet forums.

          • darrencauthon

            Sigh. I never said everything from MS is evil. I know some think so, but it’s not a default answer you can give to every criticism of MS.

            I’ve written JavaScript-only apps and Coffeescript-only apps. I’ve also written dozens of dozens of C# and Ruby apps. I’ve never written a Typescript app, but the benefits and drawbacks of static typing are not lost on me. The TS benefits you mention, mostly around “maintainability,” just don’t exist. When programmers follow solid programming principles, use TDD, and have the experience to avoid common mistakes, code in *any* language is very maintainable.

          • TheArchitect

            Darren, You’ve negate the one major benefit of static code analysis (maintainability) completely and saying the dynamic typing (if used with TDD) have the same code maintainability as any static typed language.

            And the rest of the world including academia, companies and individuals are either ignorant or never used TDD to have a maintainable code base with dynamic typing.

            I can tell you clearly, there is no practice (TDD or any *DD), no tools (any IDE) or anything that can beat “static typing” when it comes to maintainability.
            Ruby, Python, CoffeScript or whatever dynamic languages are there will never be able to have code bases as maintainable as any static typed language.

            TS has a very nice type system which beats everything out there in JS world. It is open source and is supported by many IDE. You can scale a project to 1000s of files without any pain. You can refactor any part of code with pleasure.
            There is a reason when MSFT “scale” your apps when it comes to TypeScript.

          • Phil

            Typescript was released with an Apache 2.0 License, has the full source code available on CodePlex, and can be used without Visual Studio. If you use Node you there’s an npm package setup already:


  • Very well put together. I will use this as my go-to link from now on any time someone challenges the state of OSS in .NET.

  • beton

    Great read Jimmy – as always.
    ALT.NET FTW :)

  • Jonathan Allen

    Last I checked, NUnit still doesn’t offer multi-threaded tests or Assert.Inconclusive. So as far as I’m concerned it isn’t a “clear winner” in any technical sense.

    TFS still has a way to go, but SVN is just plain garbage.

    I’m no fan of ORMs, but the people I know who do use them hate NHibernate’s poor support for LINQ.
    NAnt is the only one of your list that could be considered better than its Microsoft counter-part. But MSBuild is somewhat constrained because project and solution files literally are MSBuild scripts. If we changed NAnt enough to fulfill that role it would probably end up just as bad as MSBuild.

    • jbogard

      Really thinking back to when these tools were developed initially, the teams developing the MS tools couldn’t even look at the OSS tools.

  • hyrmn

    One note about OpenWrap / NuGet…. I might be wrong, but wasn’t NuGet adopted from Nu which was started as OSS. So, it’s not like they even started a new project to compete in that space, they just picked a ‘winner’ as it were.

    • jeremydmiller

      Nuget only took a little bit of the name from “Nu” more or less out of politeness. Nuget was started more or less in secret at MS and shared no code with what the Nu guys were doing w/ gems. And yes, MS killed a pair of existing OSS projects with Nuget yet again.

  • rickasaurus

    Just jumping in to remind you guys that F# is open source and has been since VS2010.

  • Pingback: The Morning Brew - Chris Alcock » The Morning Brew #1450()

  • Pingback: Reality is an illusion – .NET OSS is hard – codeface()

  • Pingback: Diving into C#/.NET ecosystem – An analysis of the C#/.NET platform Paulo Ortins | Paulo Ortins()

  • Pingback: No todo el OWIN es Katana | Blog de Nicoloco()