一些NET Framework的源代码开放了基于MSRL许可并提供调试整合到VS 当中了从旁观者的角度来说这是Microsoft迈向开放与社区化合作的一大步很多人也把这当作历史性事件然而对于一般的开发者而言呢？这事情到底有多大影响力呢？我认为对于开发者来说不同角色的开发者遭受的影响是不同的并且整体影响是导致分工继续细化
NET最内层的本质是什么？Microsoft曾经非常引以为豪的COMNET只是这种思想一路实践并且进化而来的结果NET最开始设计为满足RAD的需求以便吸引使用其他语言框架的程序员转移过来然而开放源代码后RAD的程序员仍然是RAD的这对他们几乎没有任何影响想象你是一个习惯于拖放一切的ASPNET开发者基本上不想写任何业务逻辑之外的代码数据访问层用Typed DataSet或者Linq to Sql搞定界面用现成的Control和ExtenderMicrosoft这次提供的源代码对你有什么意义吗？因为你不需要自己编写Control或者Extender自然你不会花时间去了解有关的模式也无须查看内置控件的代码如果你调用内置控件出问题了在Google以及调试内置控件之间你显然会选择前者因此对于习惯于RAD的程序员来说开放源代码这件事是没有任何直接影响的
然而有些间接影响是不能忽略的前面提到了使用Google搜索问题的解决方案然而Google自身并不懂得解决问题答案其实来自于其他已经把问题解决了的程序员因此这些源代码如果确实帮助了其他类型的程序员解决了问题那么也就间接帮助了RAD程序员
那么还有哪些类型的程序员呢？例如做稍微底层一些工作的编写ControlExtenderHttpHandlerHttpModule等可复用组件以便为自己或别人提供方便的编写可复用组件最糟糕的地方就在于它是可复用的——你永远不知道别人会将它以什么样的方式用在什么样的环境因此按照一定的模式开发这些组件以便保证兼容性就很有必要而模式本身最好就参考自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也曾经因此吃亏例如ASPNET 没能引入AJAX支持直到最后才急忙补上一个Callback特性并承诺日后开发完整的AJAX库因此倾听来自社区的观点很重要而要求社区有观点就必须先提供素材给他们讨论开放源代码将能够激发社区对NET Framework的研究热情并且提供更多能够作为反馈信息的新观点
因此就NET Framework开放源代码这样一件事情而言对于不同的开发者其影响的大小是不同的同时我们也能预期Microsoft本身肯定也是最大的受惠者之一否则以其智慧绝对不会做这样一个决策
