Does a great UX thwart collaboration?

Shortly after posting my last entry about the goodness of .NET, I read some other great entries about how the things I glorified were precisely .NET's flaws. It got me thinking about how a great design and a collaborative development process in general are inherently at-odds with each other–they are opposite extremes of a continuum. To illustrate, I'd like to use the .NET framework once again as a case study.

A friend of mine put it very nicely: in C#, you code at the speed of thought. There is very little standing in the way between you and the problem you're solving; all of the other stuff like memory management or configurations are neatly abstracted away from you and you get to play in the sandbox Microsoft provided for you. Everything is beautiful in this sandbox, and coding is super easy and super fast. So what's the problem?

Well, there's two actually:

1. There is a lower barrier to entry because everything is so simple, so the .NET framework sees a higher percentage of grunt, code-monkey, 9-5 developers than other frameworks. These are the people who simply memorize Microsoft's versions of all the abstractions without really understanding the problems the abstractions are solving, and they don't really understand how those abstractions work. A good developer must understand why the abstractions (s)he's using exist, and should at least be able to imagine implementing them*. I've seen too many .NET developers who don't have this understanding and end up posting exactly the kinds of questions on forums that leave you wondering if they even know what they're talking about.
2. Very few engineering-minded people have a great sense of UX, so even if a good developer offered a FOSS abstraction for .NET, the result would probably be a very complicated/convoluted API that's frustrating to use (sounds familiar?). The effect is further amplified by the number of people collaborating on the API. It's just very hard to get things right without any central leadership. (This lack of UX goodness is my main personal gripe with open source software in general, there's no visionary leadership directing its future; design is not a democracy)

Both problems (but especially the second**) lead to an attitude among .NET developers of "well, let's wait for Microsoft to do it for us." There is little incentive to do it yourself because even if you did, Microsoft would make a way better version of it once they get around to it and completely trump your version. This is the reason there's little collaboration in the .NET community. It is absolutely NOT because the .NET framework is somehow lacking in power or customizability, or is otherwise difficult to build things with. Frankly, I think it's one of the best platforms on which to build things. There is little collaboration simply because Microsoft sets a very high bar on what you should expect from the .NET framework, and when you compound that with the problems above, very few people are actually motivated to create things and share them with the community for fear of wasting their time once Microsoft addresses the same issue themselves. Is it a bad thing? Depends how you're reading "it" in that question. If you're reading "it" as "the lack of collaboration", then yes, it's bad. If you're reading "it" as "the great UX of the framework", then no, it's not bad. For better or for worse, they're two sides of the same coin.

I'm interested in learning of some FOSS development platforms that you found to be absolutely beautiful and satisfying to work with, and I'm also curious to hear about instances when .NET has miserably failed as a platform for you, so leave some comments and share your thoughts.

* I don't have the hard requirement of necessarily being able to implement them outright. Some abstractions are actually huge and take a team of people to develop. But you should at least be able to picture what such an implementation would involve and be able to explain the various use cases–that's what I mean by "imagine implementing them".

** Hell, maybe the effect of the second problem is so strong that the first problem doesn't matter. In fact, maybe I'm unfairly assessing .NET developers and the first problem isn't even true. Let me know in the comments.