tl;dr;

Microsoft is trying to change the mainstream (corporate) .Net culture. They are genuinely trying to promote open source software, without bias. And I can’t thank people at Microsoft (like Glenn Block, Scott Hanselman, and Jon Galloway) enough for busting their asses trying to push open source initiatives. Unfortunately, a culture has built up that (so far) doesn’t look like it’s changed. The general stigma (in large corporate environments) is still: “if it isn’t made or endorsed by Microsoft, we won’t use it.”

Blog Responses

Others are taking the time to respond to what I’ve written. Happy to see conversations happening (if you have a response, let me know via email/twitter and I’ll link to it):


Perception Is Reality - .NET OSS Is Getting Better by Daniel Auger @danielauger


Perception is Reality - The state of OSS in .NET by Jimmy Bogard @jbogard


Reality is an illusion – .NET OSS is hard by Mark Rendle @markrendle


A timeline that shows how long mainstream (corporate) .Net devs wait

I’m hoping the following timeline illustrates how long mainstream .Net devs wait to take advantage of a new framework and to get some conversations going. It doesn’t have to be this way. We don’t have to wait for Microsoft to endorse or build a clone of a popular framework. There are developers out there that have already done a lot of the heavy lifting. Support them. Give them feedback, contribute to their solutions, raise awareness. Don’t just sit there and wait for Microsoft.

It doesn’t have to be this way.

Notable Comments

A lot of good comments have been posted. Here are a few them. For the full spectrum of comments you can follow these threads: my original tweet, this offshoot, another offshoot, this retweet, and reddit.


Not pointing blame per-say, I’m saying MS is one of the view tech companies that competes with it’s community

source


we’ve promoted Nancy for 2½ years and Web API had more users after 1 week =)

source


it sounds like you’re not arguing for OSS, but arguing against the manner in which enterprises assess risk

source


Lots of OSS frameworks seem obsessed with being highly opinionated and with “look at few lines that took”

source


Solve a specific problem and people will use it. Asking an enterprise to buy a philosophy is another story

source


I think [this blog post] is terribly unfair, especially to @shanselman & co who spend their days boiling frogs. Will comment later!

source

As was once written, we are a product of our environment, and therefore it is the environment which is at fault and not MS for supplying it. I also have to say we as developers bear responsibility for influencing and changing our environments, if that seems beyond your reach - change your environment - vote with your feet!

source


IT management doesn’t care, they want SLAs and someone to hold accountable

source


On the timeline presented there is a framework called ServiceStack which I successfully used to significantly simplify internal APIs, used by multiple internal systems, back in early 2011.

Recently we brought on a new developer whose first question was “Why didn’t you use Microsoft’s WebApi”. I had to gently explain that I couldn’t use something that didn’t exist. So I definitely feel the author’s pain.

source


Microsoft puts a lot of emphasis on visual designer support and integration with Visual Studio. The big bulk of people who build enterprise apps on .NET are more concerned with business goals rather than actual coding. They don’t want to leave Visual Studio, don’t want to mess with the command line, don’t want to edit XML files, don’t want to experiment with new things, and generally just want to drag and drop things, press the play button, and have the program do its thing. This has been the experience that Microsoft tools have been giving for the longest time, especially on the Visual Basic side.

People who contribute to OSS, on the other hand, have a completely different mentality towards development. In general, people who participate in OSS are enamored a lot more with computers and the experience of tinkering and experimenting, and have less concerns over deadlines or meeting business goals. A lot of the OSS tech has a steep learning curve that involves reading documentation, figuring out how to configure the thing, using command line tools, so on and so forth.

When Microsoft introduces new technology, it’s usually accompanied with massive training events, conferences, webcasts, videos, technotes, documentation, etc. All of this is necessary to push the new tech into the business developer’s consciousness and make him comfortable trying something new. This isn’t necessarily because they’re bad developers, it’s just most enterprise work requires that you spend less of your energy on implementation details, and focus more on the business logic, which is complex enough on its own.

Say what you want about how inefficient MS’s “clones” are, but for the most part, I’ve been able to pick up and start working with almost all of their technologies (with the possible exception of WCF and WPF) just by opening Visual Studio and clicking things until it did what I wanted. I’ve recently inherited an application written in VB6, and I’m really quite happy about how straight-forward it all is, even if it is often sloppy and inelegant.

If the OSS community wants more adoption by “the mainstream”, then they need to understand that “the mainstream” does not care who you are, they don’t want to read your manual, nor they care about how elegant your code is. They need tremendous amounts of support, they expect a huge focus on ergonomics and polished edges, and to appeal to them you will need to do a lot of hard things that are not as fun as programming your pet project.

source


I love OSS, I really do, but for “enterprise” and “corporate” developers, and even those of us who are more open to trying new things and don’t always rely upon getting our knowledge from the pre-chewed information spoon-fed to us by Microsoft, we’re almost always better off with the Microsoft “solution”. This is true for any developer (and this is probably most of all of us) who has a “deadline”.

Tooling, Documentation & Community (number of users) are the factors that ensure this is true time and time again.

source


It was always a problem.

Castle Monorail (inspired by RoR) was developed since 2004 but web-MVC only caught up with ASP.NET MVC in 2007.

Castle Windsor is (IMHO) most powerful DI/IoC container, and exists as long as Castle, IIRC. Besides it, there’re Spring.NET, nInject, AutoFac and some more. But for most IoC only caught up with Unity and MEF in 2008.

nHibernate started around 2005. So did Subsonic, xBatis etc. But people only got caught with LINQ to SQL and EF, which are much more limited in their capabilities.

nUnit was started in 2000, Visual Studio Test Framework was released with VS 2005.

And this is just plain sad.

I can understand delay between idea emerging in one ecosystem and its spread to other ones — people need time to adapt ideas. And here .NET isn’t always the slowest kid on the playground (e.g., with web microframeworks, Nancy predates both Express and Slim).

Eventually, idea gets caught at Microsoft itself, and guys at DevDiv are wondering why nobody uses this cool idea and implements its own version. That’s understandable too.

But the slowness and indecisiveness of average developer are astounding. And the fact that release of the similar tool by Microsoft usually puts one or more ALT.NET project to extinction is extremely sad.

Things might change a bit with Nuget simplifying access to packages developed by community. Ironically, Nuget is third or fourth package management tool for .NET I remember trying and the only one that caught, again, because it’s got MS blessing.

Disclosure: I express my own opinion which might be different from that of my employer, Microsoft.

source



blog comments powered by Disqus

Published

19 September 2013

Tags