I find the opposite. Back when I was working in .net, I remember one argument I got into with my boss with regards to software evaluation. MS has a testing framework and a build tool that are basically a generic xunit and an ant clone. Now, there are a great many better xunit implementations on .net, and I think we can all agree at this point that xml isn't the greatest programming language for build scripts. I was pointing out various choices that beat out the MS ones in terms of community, maturity, and features. His argument was basically that if MS doesn't have the best product, eventually they will make it better and it will become the best.
Every community has strengths and weaknesses. IMO the big weakness of the .net community is also the worst thing about MS itself from a tech point of view - a real unwillingness to look at what everyone else in the world is doing. Because of that, you see this strange effect where enterprise trends seem to happen about 5 years later in .net then they do in other communities. For example, it is only extremely recently (like in the last two years) that it started to become normal for .net shops to use ORMs, and the hot debates over whether or not to unit test are just starting to die down. And it is really in the last year that the most bleeding edge shops have started to look at DCVS (the cutting edge ones are on svn, and the majority on a cvs type system).
And for the record, I don't think .net is a bad platform or anything like that. What I do think is that the single thing that could improve most .net shops is being more open to non ms technology.
Because of that, you see this strange effect where enterprise trends seem to happen about 5 years later in .net then they do in other communities.
I think this is a different issue. And this I think is true, but actually by design. It's funny because when I consulted I ran into the opposite problem. I'd go into shops and the devs wanted to do some cutting edge stuff. I usually came in and convinced them that this was a bad idea. :-)
The reason for this was pretty simple -- usually the stuff they wanted to use wasn't ready, and didn't match the culture of enterprise shops. For example I remember NHibernate picking up steam and lots of shops wanting to use it, but there were a lot of holes in it still.
And DVCS is another great example. In enterprises there is very little advantage of Git over SVN. SVN's offline support has been great for years now. I can add/revert without touching the network. And in the enterprise you don't have a model of "anyone pull down a branch". You want a very controlled version of the code around. Yet, again, a lot of .NET devs want to use Mercurial and my recommendation, in most cases, is that its not a good idea.
BUT source control is a great example where .NET devs have clearly not towed the line, given that I rarely see a shop using TFS. Everyone uses SVN or Mercurial. Just as no one used Source Safe in the past. If .NET devs just followed MS blindly we'd see all of these .NET devs using TFS and waiting for MS to make it better. Hasn't happened.
I think you were consulting in fairly good shops, OR it is more a geographical thing, but man, that wasn't my experience. I was working in one of the better .net companies in toronto -- we were an MS gold partner, our CTO was an MVP and was frequently on the conference circuit, and we sponsored the local user group. I met and worked with a lot of great devs in the MS community, but frustration at that tunnel-vision thing was probably what ultimately got me to jump platforms
I sort of disagree on the DVCS point, just because the technology is so much better all around. If I start working on something, I make a branch for it. When I am done, I pull master, and rebase my topic branch back on top of the other work people have done. This allows for a few things.
1) If I get interrupted and need to work on something else, not only am I able to, but switching back to master, pulling, and branching again takes under 20 seconds and is 3 commands.
2) If someone else is working on the same part of the code base, I can pull their half done work from them directly if I need to, while keeping the mainline clean and in working order. Where I work we do pair programming, so this is really huge, any time we want to switch roles it is just a local commit and pull away.
3) no single point of failure. I don't know if this has happened to you before, but if your svn server gets corrupted, basically work completely stops until it is fixed. Reconstructing a recent version of your code base based on whats on dev machines is pretty much asking who was the last one to pull, because again, dev work doesn't mess with master since branching is so easy, so everyone should have a clean version of the mainline on their machines.
I think the advantages of DVCS are _way_ more obvious for open source projects, but you can see a lot of benefits using it pretty much anywhere.
Every community has strengths and weaknesses. IMO the big weakness of the .net community is also the worst thing about MS itself from a tech point of view - a real unwillingness to look at what everyone else in the world is doing. Because of that, you see this strange effect where enterprise trends seem to happen about 5 years later in .net then they do in other communities. For example, it is only extremely recently (like in the last two years) that it started to become normal for .net shops to use ORMs, and the hot debates over whether or not to unit test are just starting to die down. And it is really in the last year that the most bleeding edge shops have started to look at DCVS (the cutting edge ones are on svn, and the majority on a cvs type system).
And for the record, I don't think .net is a bad platform or anything like that. What I do think is that the single thing that could improve most .net shops is being more open to non ms technology.