.NET Framework開源給開發者帶來不同影響

一些.NET Framework的原始碼開放了，基於MS-RL許可，並提供除錯整合到VS 2008當中了。從旁觀者的角度來說，這是Microsoft邁向開放與社群化合作的一大步，很多人也把這當作歷史性事件，然而對於一般的開發者而言呢？這事情到底有多大影響力呢？我認為對於開發者來說，不同角色的開發者遭受的影響是不同的，並且整體影響是導致分工繼續細化。

.NET最內層的本質是什麼？Microsoft曾經非常引以為豪的COM，.NET只是這種思想一路實踐並且進化而來的結果。.NET最開始設計為滿足RAD的需求，以便吸引使用其他語言、框架的程式設計師轉移過來，然而開放原始碼後RAD的程式設計師仍然是RAD的，這對他們幾乎沒有任何影響。想象你是一個習慣於拖放一切的ASP.NET開發者，基本上不想寫任何業務邏輯之外的程式碼，資料訪問層用Typed DataSet或者Linq to Sql搞定，介面用現成的Control和Extender，Microsoft這次提供的原始碼對你有什麼意義嗎？因為你不需要自己編寫Control或者Extender，自然你不會花時間去了解有關的模式，也無須檢視內建控制元件的程式碼。如果你呼叫內建控制元件出問題了，在Google以及除錯內建控制元件之間，你顯然會選擇前者。因此，對於習慣於RAD的程式設計師來說，開放原始碼這件事是沒有任何直接影響的。

然而，有些間接影響是不能忽略的。前面提到了使用Google搜尋問題的解決方案，然而Google自身並不懂得解決問題，答案其實來自於其他已經把問題解決了的程式設計師，因此這些原始碼如果確實幫助了其他型別的程式設計師解決了問題，那麼也就間接幫助了RAD程式設計師。

那麼，還有哪些型別的程式設計師呢？例如，做稍微底層一些工作的，編寫Control、Extender、HttpHandler、HttpModule等可複用元件以便為自己或別人提供方便的。編寫可複用元件最糟糕的地方就在於它是可複用的——你永遠不知道別人會將它以什麼樣的方式用在什麼樣的環境，因此按照一定的模式開發這些元件以便保證相容性就很有必要，而模式本身最好就參考自.NET Framework內建的同類元件，除非你想更大範圍地研究.NET Framework並重新發明輪子。因此研究與模仿內建元件的行為是元件開發者的必修課，而從ScottGu文章（Releasing the Source Code for the .NET Framework Libraries）中的截圖看來，內建元件豐富的註釋將有助於程式設計師更輕鬆地理解其原本的設計方式，從而更輕鬆地在自己的元件中模仿內建元件的行為。事實上，有很多內建元件是設計為對另外一些內建元件特別照顧的，這型別的耦合在Reflector中閱讀程式碼時是最難以理解的，如果閱讀有註釋的程式碼相信會輕鬆不少。

最後，開放原始碼可能將會導致對.NET Framework進行純粹思想或理論作研究的人數增加。事實上，無論.NET Framework多麼傾向於實用型，如果Microsoft需要獲取來自社群的創新思想，還是必須吸引一群思想家的，否則大多數的社群創新都只是應用與應用方法，Microsoft還是獨攬.NET Framework前進方向的控制權。這種中央集權有它高效的地方，特別是發展初期，Microsoft能夠根據自己的實力戰略性地安排新特性的研發順序。然而Microsoft也曾經因此吃虧，例如ASP.NET 2.0沒能引入AJAX支援，直到最後才急忙補上一個Callback特性，並承諾日後開發完整的AJAX庫。因此，傾聽來自社群的觀點很重要，而要求社群有觀點就必須先提供素材給他們討論，開放原始碼將能夠激發社群對.NET Framework的研究熱情並且提供更多能夠作為反饋資訊的新觀點。

因此，就.NET Framework開放原始碼這樣一件事情而言，對於不同的開發者其影響的大小是不同的。同時我們也能預期Microsoft本身肯定也是最大的受惠者之一，否則以其智慧絕對不會做這樣一個決策。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/12639172/viewspace-536479/，如需轉載，請註明出處，否則將追究法律責任。