What I think is and is not better about .Net OSS these days

I meant to write this a couple months ago after I made a sarcastic remark about how saying “I take pull requests” was a fast way to end a conversation with .Net developers. That got retweeted quite a bit, but honestly, my experiences doing OSS work in .Net have gotten so very much more positive in the last couple years and this post might be warranted.

There’s a never ending stream of consternation and angst about the state of OSS development inside of the .Net community — and yes, I’ve been a part of that from time to time. One common perception is that OSS is not as vibrant in .Net as it is in many other technology stacks. Another complaint that I see frequently (and make) is that there sometimes seem like there’s a lot of “not invented here” type duplication between OSS projects in .Net.

A lot of that is probably true, and I think unlikely to ever completely change, but working on .Net OSS projects now is definitely far better than it was just a few years ago.

A quick rundown of my experiences and involvement for some context:

  • StructureMap has been around since 2004, and probably been widely used since about 2007/8. For whatever reasons, StructureMap has actually enjoyed a pretty significant uptick in contributions and development over the past couple years.
  • Marten is about six months old, but it’s already the busiest OSS community I’ve been a part of
  • Storyteller doesn’t have a lot of usage yet, but the early feedback has been encouraging
  • FubuMVC was a great learning experience and directly responsible for my current position and several personal relationships with other developers, but was a otherwise a massive failure as an OSS project and a tremendous opportunity cost for me

What I think is definitely better now

The most important difference in being an OSS author now as opposed to even just a few years ago is how much more pleasant my interactions are with users. In the past, it was all too common to deal with endless belligerence and an annoying sense of entitlement from users who were probably much more used to leaning on official support lines and documentation from software vendors. I still get a little bit of that once in awhile, but lately I’m seeing a lot more of:

  • Users acting as collaborators with me to solve their issues
  • Getting much clearer reproduction steps for their problems, often including failing unit tests to demonstrate their issues
  • Patience and pleasantness from users needing help
  • A willingness to take on pull request work to fix their issues and contribute back to the project
  • An obvious sense that the project is a community effort
  • Users helping each other in our Gitter rooms before I have a chance to respond

I think that GitHub and its like have definitely made OSS development a much more positive experience. I’d even say that Microsoft’s recent adoption and de facto endorsement of GitHub have definitely made git and GitHub skills much more common throughout the .Net community — and that in turn has made it much more common for users to be able to contribute back to OSS projects.

At least for Marten, we’ve been able to attract quite a bit of early interest and several active contributors and early adopters. It’s easily been the most positive OSS experience I’ve ever had.

I think it’s helped a bit that more .Net developers are comfortable and familiar with automated build and testing tools. I rarely see pull requests submitted without tests anymore, but that would have been a common occurrence a few years ago.

What’s still not great about .Net OSS

  • A large number of shops will simply not adopt anything that isn’t an official tool from Microsoft
  • I think that Microsoft still stomps all over the existing OSS projects in .Net by building direct competitors or not taking any cognizance of existing tools when they plan .Net framework changes. I should say that I don’t think this is purposeful, but I’ve never gotten the sense that the teams in Redmond have much awareness or visibility into the .Net OSS ecosystem
  • The unusual status of the .Net community being so centered on Microsoft and the tools that they provide out of the box just doesn’t leave enough Oxygen for community OSS projects
  • I think that the forthcoming CoreCLR / DNX / New Name? tooling is probably going to make a lot of the existing OSS projects go extinct. The runtime is very different in some aspects (it wasn’t that bad to move StructureMap up to the CoreCLR, but Storyteller will be much more work and Marten cannot work yet on the DNX runtime as we wait on Roslyn work). Even on top of waiting for your dependencies to support CoreCLR, I think that there won’t be enough interest or activity to bring a lot of tools forward. .Net OSS might be a lot better in the long term as .Net simply becomes a better platform for development
  • I think that ASP.Net Core and related efforts are going to take most of the .Net community’s attention for quite awhile
  • It’s still hard to get visibility for .Net OSS projects and that in turn makes it unlikely that a community coalesces around any one project. This is my working theory for why there are so many duplicated projects in .Net
  • There aren’t many venues, groups, or conferences dedicated to OSS efforts in .Net. Most .Net technical conferences tend to skew heavily toward Microsoft offerings
  • I think the MVP program skews the community toward official Microsoft tools and away from OSS projects

 

What about Microsoft being so much more involved in OSS themselves?

I honestly don’t know. It’s making much more developers aware of OSS in general, but I don’t know that it will really encourage folks to be more involved in community projects.

In Summary

My advice is yes, definitely get involved in .Net OSS projects or start your own if you enjoy doing that kind of work, you want to expand your technical skills, or want to make yourself more marketable. If you are making a big bet on the success of that project or have high hopes for it to be widely adopted, I think I’d advise you to set your sights much lower. You also have to realize that it’s very difficult for .Net OSS projects to gain visibility and widespread adoption.

I’d also discourage anyone from trying to compete directly with any tool from Microsoft itself. It can be done, but that’s an uphill slog. It’s probably a lot easier to either find niches where Microsoft tooling has not real entry, or focus on projects that try to add value to mainstream Microsoft .Net tooling. Then hope that Microsoft doesn’t start building their own version of your tool and send one of their celebrity programmers to conferences to sell it;)

 

10 thoughts on “What I think is and is not better about .Net OSS these days

  1. Why not just get out of the Microsoft bs entirely? Want a structured language? Go Lang is great. Jetbrains has you covered in Linux. It’s not worth rearranging the deck chairs on the titanic anymore.

    1. Golang? Really? I did quite a bit of that in college, but back then we called it “Fortran 77” — and that comparison should tell you exactly how highly I think of Golang;)

  2. The comment that “Another complaint that I see frequently (and make) is that there sometimes seem like there’s a lot of ‘not invented here’ type duplication between OSS projects in .Net.” is unfair. There’s an implication that this is a .NET OSS problem. Have you looked at the JavaScript OSS ecosystem lately? How many binding frameworks do we really need?

    I also get the feeling you’re looking for reasons to dump on MS. JSON.NET (while not an OSS project it’s still not MS) is the de facto JSON serializer and is the one installed when you create a new MVC application. SignalR at least started life as an independent project and is now an integral part. I’m making a big supposition here, but perhaps MS creates a direct competitors because they recognize that there are some shops that aren’t going to use OSS yet there is a demand for that functionality.

    As to the issue of shops shying away from OSS, I see two reasons for that.

    .NET is often used in large, corporate environments. Large, corporate environments have lawyers, and a lawyer’s job is at least partially to make sure the company doesn’t get sued. There are too many OSS licenses and the lawyers just say, “Screw it, we’re not going to deal with all these variations, you can’t use OSS.” How about blaming the community? Do we really need MIT, Apache, GNU (all three versions plus its deritives), MPL, and so on? If you go to the wikipedia page “Comparison of free and open-source software licenses” there are 54 licenses listed as approved by various subsets of the FOSS community. How about the community narrow that down to three or so to make it easier to give approvals as to what licenses might be acceptable in a corporate environment?

    The second issue is kind of the opposite. The lawyers want someone to go after if stuff doesn’t work. I’m sure we’ve all seen the “dude who broke the internet” articles recently when an OSS author pulled his packages from NPM and broke a boatload of other packages and applications. This kind of thing scares the crap out of managers and lawyers and gives them fuel to say, “See, look what can happen if we depend on OSS.”

    You also state (in reference to .NET Core) “I think that there won’t be enough interest or activity to bring a lot of tools forward.” Yeah, that’s how capitalism works. If people don’t want/need something, it dies. I’ve spent a week writing something for an application and the company decides it doesn’t want that feature after all so the code gets trashed. Oh well. That’s life in software development.

    Your assertion that it’s hard to get visibility may be true, but I would turn that around and ask, how do other ecosystems do it? AngularJS got visibility because it was promoted by Google. MS raised the visibility of JSON.NET and SignalR. Influential blogs like Hanselman promote interesting projects and libraries (that’s how I found out about Humanizer, which we use at work).

    When I read your posts on this topic I really get the feeling that you’re still a bit bent out of shape that FubuMVC didn’t take off, you blame MS for that, and it is coloring your perception. Creating large, foundational infrastructures for .NET will probably rarely succeed because you will bump up against Microsoft’s own implementation. However smaller, focused libraries that solve particular problems seem to be doing pretty well.

  3. I read this post yesterday and gave a day to digest it.

    I very much like this post, and it puts several of my sentiments into concrete words. I have some thoughts, and some questions.

    >I think that ASP.Net Core and related efforts are going to take most of the .Net community’s attention for quite awhile

    As opposed to what? Are they detracting attention from something else that is a detriment to .NET?

    >It’s still hard to get visibility for .Net OSS projects and that in turn makes it unlikely that a community coalesces around any one project.

    My theory on this is that this this is Not Invented Here syndrome at work. Companies and individuals are reluctant to use OSS, but they’re happy to use their own OSS because they are the owners, can drive direction, and don’t feel beholden to anyone else. Using an OSS project requires a degree of trust, and I think the .NET community is still weary to fully trust OSS in a corporate setting.

    >What about Microsoft being so much more involved in OSS themselves?

    A while ago I read a blog post about Agile called “Coconut Headphones: Why Agile Has Failed” ( http://mikehadlow.blogspot.com/2014/03/coconut-headphones-why-agile-has-failed.html ). Though nothing to do with Agile, I get a sense of that regarding OSS and Microsoft. They have their GitHub repos, their pull requests, and their continuous integration, but they don’t understand where the airplanes come from.

    I’ve had quite different experiences with different teams. The most pleasant OSS experience I’ve ever had (Microsoft or otherwise) was with the CoreCLR team. I feel like they “get it”. Roslyn and CoreFx I also had pleasant experiences with. Then there are the negative experiences. For these I don’t think they’ll do much to convince people to get involved in .NET OSS.

Leave a comment