引用自51CTO，希望對(duì)你有幫助：
.NET最開始設(shè)計(jì)為滿足RAD的需求，以便吸引使用其他語言、框架的程序員轉(zhuǎn)移過來，然而開放源代碼后RAD的程序員仍然是RAD的，這對(duì)他們幾乎沒有任何影響。想象你是一個(gè)習(xí)慣于拖放一切的ASP.NET開發(fā)者，基本上不想寫任何業(yè)務(wù)邏輯之外的代碼，數(shù)據(jù)訪問層用Typed DataSet或者Linq to Sql搞定，界面用現(xiàn)成的Control和Extender，Microsoft這次提供的源代碼對(duì)你有什么意義嗎？
因?yàn)槟悴恍枰约壕帉慍ontrol或者Extender，自然你不會(huì)花時(shí)間去了解有關(guān)的模式，也無須查看內(nèi)置控件的代碼。如果你調(diào)用內(nèi)置控件出問題了，在Google以及調(diào)試內(nèi)置控件之間，你顯然會(huì)選擇前者。因此，對(duì)于習(xí)慣于RAD的程序員來說，開放源代碼這件事是沒有任何直接影響的。
然而，.NET Framework開源有些間接影響是不能忽略的。前面提到了使用Google搜索問題的解決方案，然而Google自身并不懂得解決問題，答案其實(shí)來自于其他已經(jīng)把問題解決了的程序員，因此這些源代碼如果確實(shí)幫助了其他類型的程序員解決了問題，那么也就間接幫助了RAD程序員。
那么，還有哪些類型的程序員呢？例如，做稍微底層一些工作的，編寫Control、Extender、HttpHandler、HttpModule等可復(fù)用組件以便為自己或別人提供方便的。編寫可復(fù)用組件最糟糕的地方就在于它是可復(fù)用的——你永遠(yuǎn)不知道別人會(huì)將它以什么樣的方式用在什么樣的環(huán)境，因此按照一定的模式開發(fā)這些組件以便保證兼容性就很有必要，而模式本身最好就參考自.NET Framework內(nèi)置的同類組件，除非你想更大范圍地研究.NET Framework并重新發(fā)明輪子。
因此研究與模仿內(nèi)置組件的行為是組件開發(fā)者的必修課，而從ScottGu文章（Releasing the Source Code for the .NET Framework Libraries）中的截圖看來，內(nèi)置組件豐富的注釋將有助于程序員更輕松地理解其原本的設(shè)計(jì)方式，從而更輕松地在自己的組件中模仿內(nèi)置組件的行為。事實(shí)上，有很多內(nèi)置組件是設(shè)計(jì)為對(duì)另外一些內(nèi)置組件特別照顧的，這類型的耦合在Reflector中閱讀代碼時(shí)是最難以理解的，如果閱讀有注釋的代碼相信會(huì)輕松不少。
最后，.NET Framework開源可能將會(huì)導(dǎo)致對(duì).NET Framework進(jìn)行純粹思想或理論作研究的人數(shù)增加。事實(shí)上，無論.NET Framework多么傾向于實(shí)用型，如果Microsoft需要獲取來自社區(qū)的創(chuàng)新思想，還是必須吸引一群思想家的，否則大多數(shù)的社區(qū)創(chuàng)新都只是應(yīng)用與應(yīng)用方法，Microsoft還是獨(dú)攬.NET Framework前進(jìn)方向的控制權(quán)。這種中央集權(quán)有它高效的地方，特別是發(fā)展初期，Microsoft能夠根據(jù)自己的實(shí)力戰(zhàn)略性地安排新特性的研發(fā)順序。
然而Microsoft也曾經(jīng)因此吃虧，例如ASP.NET 2.0沒能引入AJAX支持，直到最后才急忙補(bǔ)上一個(gè)Callback特性，并承諾日后開發(fā)完整的AJAX庫。因此，傾聽來自社區(qū)的觀點(diǎn)很重要，而要求社區(qū)有觀點(diǎn)就必須先提供素材給他們討論，開放源代碼將能夠激發(fā)社區(qū)對(duì).NET Framework開源的研究熱情并且提供更多能夠作為反饋信息的新觀點(diǎn)。
因此，就.NET Framework開放源代碼這樣一件事情而言，對(duì)于不同的開發(fā)者其影響的大小是不同的。同時(shí)我們也能預(yù)期Microsoft本身肯定也是最大的受惠者之一，否則以其智慧絕對(duì)不會(huì)做這樣一個(gè)決策。