12月9日， Oren Eini ，以色列的一位热衷于.NET开源项目的开发人员，在他的Blog上写了一篇文章分析了.NET开源社区存在的问题，文章的题目是：The Problem of Open Source in the Microsoft World，然后Jeremy D. Miller和David Hayden在CodeBetter上针对该文发表了他们的想法：
Ditto on Ayende's Microsoft OSS Post
Microsoft OSS Community - Too Much Duplication of Effort?
Oren Eini参与了NHibernate 和Castle的开发，而且是Rhino Mocks的创始人，也参与了Boo的开发，他已经在.NET开源社区活跃了三年。
他在文中写道：
“我不是开源狂热者，不会高举GPL的大旗闯入微软总部去解放那些被微软控制的代码。我只是看好开源软件的发展前景，相信开源软件在基础平台软件中的价值”
“仅从开源软件的用户数比较，.NET开源社区与其他开源社区(比如：Java)相比，还存在不小的差距。这个问题已经被讨论过很多次，经过几年的发展，现在.NET社区已经没有理由把Java开源社区发展得早作为借口。”
“通过分析.NET社区的特点，我们就可以看出为什么会出现这个差距。.NET社区中有一个具有领导地位的商家-Microsoft，Microsoft重要的角色让他可以聆听到社区中来自开发人员、团队负责人、架构师的声音，但Microsoft并没有为建立一个强大的.NET开源社区做过任何努力。”
“让我们看看Java社区，有着很多开源项目，比如：JUnit和Ant，这两个开源软件是Java社区为了解决Java开发人员实际开发中遇到的问题而自己开发的。在Java社区中，好的开源软件会得到整个社区的支持，比如：像JUnit和Ant这样的优秀的开源工具软件会被所有主流的开发工具所支持。Hibernate和EJB 3.0也证明这一点。”
“由于Java开放的本性(no single source, even though Sun can dictate stuff)，类库和工具进行着优胜劣汰的竞争，只有付出更多努力、做得更好的软件，才会在竞争中胜出。Java社区建立了良好的竞争环境。”
“在.NET社区，情况却大不相同。比如：在.NET社区也有开源工具：NUnit和NAnt ，而2005年微软发布的Vistual Studio 2005中却包含了类似的工具。”
“对应于NAnt，微软提供了MsBuild，由于NAnt使用了GPL协议，所以微软不能在Visual Studio中使用它，微软自己开发MsBuild是可以理解的，微软为开发人员做的这个工作也是应该得到肯定的”。
“对应于NUnit，微软提供了Ms Test，由于NUnit使用了商业友好的开源协议，所以微软基于NUnit的原型开发了Ms Test，却使用了不兼容的语法。”这是作者对微软不满之处，参考NUnit开发了Ms Test，却不与NUnit兼容，显然是想扼杀NUnit。
“作为一个.NET开发人员不得不面对像NUnit与Ms Test，NAnt与Ms Build这样的选择，而微软的工具越来越臃肿，花哨的界面，使用向导等等，如果选择了微软的工具，将面临这样的问题：当需要进行一点改进时，会很麻烦。比如：Ms Test不支持Abstract Test Case ，在核心代码中解决这个问题很简单，只需要在执行测试方法时，去掉BindingFlags.DeclaredOnly ，但对微软来说，不是这么简单，还要改变界面、向导等等，本来一个简单的改动现在却变成了一个需要投入很多资源的大工程。”
“在.NET社区，你会发觉微软在重复着这样的故事：总是想用微软自己的工具软件替代已有的开源软件，比如：
1、NDoc与Sandcastle
2、Log4net与Logging Application Block
3、Castle Windsor/Spring.Net与Object Builder
经过一段时间的观察，我发觉这样一个现象：在开源软件中存在的功能，如果微软没有提供，微软就会在自己的软件中开发这个功能，而不是把现有的开源软件集成到微软的软件中(通常这些开源软件都没有限制商业使用)。”
“我希望看到的是微软与开源社区合作，在现有优秀的开源工具软件的基础上为.NET开发人员开发更好的开发工具，而不是让开发者在同样功能的开源软件与微软软件之间进行选择，学习不同软件的使用方法。”
“我不希望微软去开发与现有的开源软件产品重复的新产品，特别是经过几年发展比较成熟的开源软件，微软很难开发出比它们更好的软件。我希望微软官方推荐用户使用像NHiberate这样的、微软自己没有的、优秀的开源软件，而不是对用户说：'手工去做，或者等1年后的LINQ'。在微软提供的软件产品的空隙中总有出现一些优秀的开源软件产品，微软这样的重复开发对微软与.NET社区来说都是资源的浪费。微软应该利用成功的开源软件更好地帮助开发人员，Java的模式是值得借鉴的，假设微软将NHibernate集成到Visual Studio 2005中，NHibernate将会有更好的文档，更多的示例，更易用的工具，微软在核心功能上的基础上增加新的功能，NHibernate就会得到更好的发展，大家都会从中受益(除了DLinq开发团队)。”
“.NET开源社区最大的问题就在于：作为.NET的领导者，微软自己却没有参与到.NET开源社区中。CodePlex虽然是微软建立的开源平台，但并没有让微软成为.NET开源社区的一员，和社区共同去完善CLR和.NET相关的工具集。比如：mvp.xml开源项目，mvp.xml有很多在xml方面有用功能，但我们并没有看到微软把mvp.xml中的代码迁移到System.Xml中。“
“我不敢奢望微软成为开源社区的一员，但希望微软对待.NET开源社区的态度有所改变。”
相关资源：几个月前，.NET社区中关于微软应该为.NET开源项目提供赞助的话题：link 1, link 2, link 3。
Jeremy 在Ditto on Ayende's Microsoft OSS Post中的观点是：
“.NET开发社区中软件开发工具使用现状：
1、等待微软开发的新工具并且在没有进行权威评估的情况下使用。
2、从Java和Ruby中移植到.NET中。
.NET社区缺乏创新是非常令人失望的，期待微软和模仿Java(将Java的工具迁移到.NET中)扼杀了.NET社区的创新能力。微软提供的工具主要是与快速开发相关的，而在微软提供的工具之外，还缺少很多重要的工具，比如：Inversion of Control tool, a released O/R mapper, a Continuous Integration tool, or a mock object library。.NET 开发人员可以比微软更快地开发出他们自己所需的工具，微软不可能预知开发人员的每一个需求。”
Jeremy的想法是：.NET开发中还缺少很多重要的开发工具，.NET开源社区完全可以依靠自身的力量去开发这些急需的开发工具。
Jeremy建议开发人员多参与开源项目，他参加了两个项目：StructureMap和StoryTeller，他觉得参与开源项目可以 给他的职业发展带来了帮助，至少给他提供一个很好的实践机会。
David Hayden在Microsoft OSS Community - Too Much Duplication of Effort? 写到：
他想参与开源项目，但他面临的困难是：
1、怎样找到一个有价值的项目？
2、怎样找到自己感兴趣并有能力开发的项目？
3、如何判断一个项目是否有成功的可能，并能满足一定的需求？
他觉得.NET开源社区的主要问题就是重复开发，重复开发不仅影响了类似项目的开发进度，而且给想参与开源项目的开发人员带来了混乱，不知道该选择哪个项目。
比如：
1、StructureMap, Spring.NET, or Windsor?
2、NHibernate, Gentle, IBatis, Retina?
3、dasBlog or SubText?
4、log4net or NLog?
他觉得一个社区不应该有多个竞争性的项目，应该集中力量做最有价值的项目。
“如果我们有组织地集中力量去做好开源项目，开源社区将发展得更快，开发出更多满足需求的软件，用户使用时也更方便。这样，我们可以专注于这些软件的销售与对用户进行培训，发展更大的社区帮助开源软件的发展。”
“作为一个开源项目的志愿开发者，我很希望将我的精力投入在得到社区支持的、有价值的开源项目。”
“作为最终用户，我很希望能够方便地知道在当前的应用程序开发中应该选用什么样的开源软件。”
他的想法就是建议开源社区应该加强组织，集中力量，让参与开源项目的志愿者的工作更有价值。
欢迎大家针对.NET开源社区存在的问题进行讨论。
为.NET开源社区的发展作出贡献是博客园的重要任务之一，目前正在进行的NBear项目就是一个开始，期待园子里更多朋友参与.NET开源社区的发展。
Ditto on Ayende's Microsoft OSS Post
Microsoft OSS Community - Too Much Duplication of Effort?
Oren Eini参与了NHibernate 和Castle的开发，而且是Rhino Mocks的创始人，也参与了Boo的开发，他已经在.NET开源社区活跃了三年。
他在文中写道：
“我不是开源狂热者，不会高举GPL的大旗闯入微软总部去解放那些被微软控制的代码。我只是看好开源软件的发展前景，相信开源软件在基础平台软件中的价值”
“仅从开源软件的用户数比较，.NET开源社区与其他开源社区(比如：Java)相比，还存在不小的差距。这个问题已经被讨论过很多次，经过几年的发展，现在.NET社区已经没有理由把Java开源社区发展得早作为借口。”
“通过分析.NET社区的特点，我们就可以看出为什么会出现这个差距。.NET社区中有一个具有领导地位的商家-Microsoft，Microsoft重要的角色让他可以聆听到社区中来自开发人员、团队负责人、架构师的声音，但Microsoft并没有为建立一个强大的.NET开源社区做过任何努力。”
“让我们看看Java社区，有着很多开源项目，比如：JUnit和Ant，这两个开源软件是Java社区为了解决Java开发人员实际开发中遇到的问题而自己开发的。在Java社区中，好的开源软件会得到整个社区的支持，比如：像JUnit和Ant这样的优秀的开源工具软件会被所有主流的开发工具所支持。Hibernate和EJB 3.0也证明这一点。”
“由于Java开放的本性(no single source, even though Sun can dictate stuff)，类库和工具进行着优胜劣汰的竞争，只有付出更多努力、做得更好的软件，才会在竞争中胜出。Java社区建立了良好的竞争环境。”
“在.NET社区，情况却大不相同。比如：在.NET社区也有开源工具：NUnit和NAnt ，而2005年微软发布的Vistual Studio 2005中却包含了类似的工具。”
“对应于NAnt，微软提供了MsBuild，由于NAnt使用了GPL协议，所以微软不能在Visual Studio中使用它，微软自己开发MsBuild是可以理解的，微软为开发人员做的这个工作也是应该得到肯定的”。
“对应于NUnit，微软提供了Ms Test，由于NUnit使用了商业友好的开源协议，所以微软基于NUnit的原型开发了Ms Test，却使用了不兼容的语法。”这是作者对微软不满之处，参考NUnit开发了Ms Test，却不与NUnit兼容，显然是想扼杀NUnit。
“作为一个.NET开发人员不得不面对像NUnit与Ms Test，NAnt与Ms Build这样的选择，而微软的工具越来越臃肿，花哨的界面，使用向导等等，如果选择了微软的工具，将面临这样的问题：当需要进行一点改进时，会很麻烦。比如：Ms Test不支持Abstract Test Case ，在核心代码中解决这个问题很简单，只需要在执行测试方法时，去掉BindingFlags.DeclaredOnly ，但对微软来说，不是这么简单，还要改变界面、向导等等，本来一个简单的改动现在却变成了一个需要投入很多资源的大工程。”
“在.NET社区，你会发觉微软在重复着这样的故事：总是想用微软自己的工具软件替代已有的开源软件，比如：
1、NDoc与Sandcastle
2、Log4net与Logging Application Block
3、Castle Windsor/Spring.Net与Object Builder
经过一段时间的观察，我发觉这样一个现象：在开源软件中存在的功能，如果微软没有提供，微软就会在自己的软件中开发这个功能，而不是把现有的开源软件集成到微软的软件中(通常这些开源软件都没有限制商业使用)。”
“我希望看到的是微软与开源社区合作，在现有优秀的开源工具软件的基础上为.NET开发人员开发更好的开发工具，而不是让开发者在同样功能的开源软件与微软软件之间进行选择，学习不同软件的使用方法。”
“我不希望微软去开发与现有的开源软件产品重复的新产品，特别是经过几年发展比较成熟的开源软件，微软很难开发出比它们更好的软件。我希望微软官方推荐用户使用像NHiberate这样的、微软自己没有的、优秀的开源软件，而不是对用户说：'手工去做，或者等1年后的LINQ'。在微软提供的软件产品的空隙中总有出现一些优秀的开源软件产品，微软这样的重复开发对微软与.NET社区来说都是资源的浪费。微软应该利用成功的开源软件更好地帮助开发人员，Java的模式是值得借鉴的，假设微软将NHibernate集成到Visual Studio 2005中，NHibernate将会有更好的文档，更多的示例，更易用的工具，微软在核心功能上的基础上增加新的功能，NHibernate就会得到更好的发展，大家都会从中受益(除了DLinq开发团队)。”
“.NET开源社区最大的问题就在于：作为.NET的领导者，微软自己却没有参与到.NET开源社区中。CodePlex虽然是微软建立的开源平台，但并没有让微软成为.NET开源社区的一员，和社区共同去完善CLR和.NET相关的工具集。比如：mvp.xml开源项目，mvp.xml有很多在xml方面有用功能，但我们并没有看到微软把mvp.xml中的代码迁移到System.Xml中。“
“我不敢奢望微软成为开源社区的一员，但希望微软对待.NET开源社区的态度有所改变。”
相关资源：几个月前，.NET社区中关于微软应该为.NET开源项目提供赞助的话题：link 1, link 2, link 3。
Jeremy 在Ditto on Ayende's Microsoft OSS Post中的观点是：
“.NET开发社区中软件开发工具使用现状：
1、等待微软开发的新工具并且在没有进行权威评估的情况下使用。
2、从Java和Ruby中移植到.NET中。
.NET社区缺乏创新是非常令人失望的，期待微软和模仿Java(将Java的工具迁移到.NET中)扼杀了.NET社区的创新能力。微软提供的工具主要是与快速开发相关的，而在微软提供的工具之外，还缺少很多重要的工具，比如：Inversion of Control tool, a released O/R mapper, a Continuous Integration tool, or a mock object library。.NET 开发人员可以比微软更快地开发出他们自己所需的工具，微软不可能预知开发人员的每一个需求。”
Jeremy的想法是：.NET开发中还缺少很多重要的开发工具，.NET开源社区完全可以依靠自身的力量去开发这些急需的开发工具。
Jeremy建议开发人员多参与开源项目，他参加了两个项目：StructureMap和StoryTeller，他觉得参与开源项目可以 给他的职业发展带来了帮助，至少给他提供一个很好的实践机会。
David Hayden在Microsoft OSS Community - Too Much Duplication of Effort? 写到：
他想参与开源项目，但他面临的困难是：
1、怎样找到一个有价值的项目？
2、怎样找到自己感兴趣并有能力开发的项目？
3、如何判断一个项目是否有成功的可能，并能满足一定的需求？
他觉得.NET开源社区的主要问题就是重复开发，重复开发不仅影响了类似项目的开发进度，而且给想参与开源项目的开发人员带来了混乱，不知道该选择哪个项目。
比如：
1、StructureMap, Spring.NET, or Windsor?
2、NHibernate, Gentle, IBatis, Retina?
3、dasBlog or SubText?
4、log4net or NLog?
他觉得一个社区不应该有多个竞争性的项目，应该集中力量做最有价值的项目。
“如果我们有组织地集中力量去做好开源项目，开源社区将发展得更快，开发出更多满足需求的软件，用户使用时也更方便。这样，我们可以专注于这些软件的销售与对用户进行培训，发展更大的社区帮助开源软件的发展。”
“作为一个开源项目的志愿开发者，我很希望将我的精力投入在得到社区支持的、有价值的开源项目。”
“作为最终用户，我很希望能够方便地知道在当前的应用程序开发中应该选用什么样的开源软件。”
他的想法就是建议开源社区应该加强组织，集中力量，让参与开源项目的志愿者的工作更有价值。
欢迎大家针对.NET开源社区存在的问题进行讨论。
为.NET开源社区的发展作出贡献是博客园的重要任务之一，目前正在进行的NBear项目就是一个开始，期待园子里更多朋友参与.NET开源社区的发展。
来源：https://www.cnblogs.com/dudu/archive/2006/12/12/589031.html