.NET开源社区存在的问题
生活随笔
收集整理的這篇文章主要介紹了
.NET开源社区存在的问题
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
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
總結
以上是生活随笔為你收集整理的.NET开源社区存在的问题的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Nemuria UML架构图 第2次迭代
- 下一篇: 取得Servlet文件的絕對路徑;文件讀