為什麼有一些程序員認為開源有助於發現軟體中的缺陷？

01-01

程序員寫的程序普遍缺陷很多。有一些程序員認為，相比閉源項目，在開源項目中，所有人都能夠直接閱讀源代碼，因此開源項目中的缺陷更容易被發現。為什麼他們會有這種想法？

該說的其他人都說了

我是反對這一觀點的

這是片面的

只有當一個擁有強大社區的開源軟體和一個商業支持很弱的閉源軟體對比這才成立

而很多人有喜歡拿微軟做例子

我就說說微軟的商業支持，如果windows server爆出了一個和心臟出血一般嚴重的漏洞，那麼微軟從製作到發補丁，最快只需20分鐘!!!

不是一定要到每月中旬才發補丁的，如果嚴重，可以馬上發

最重要的一點——很多漏洞不是靠看源碼發現的，而是靠調試發現的，除非核心貢獻者，否則很少有人仔細讀源碼，而更多的漏洞是在使用過程中被發展的，否則黑客怎會發現那麼多win漏洞？靠看源碼？

第二，閉源商業軟體的開發實力不輸於開源社區，Linux kernel有3000多位核心開發者，上億位用戶，微軟也有3000多位核心開發，上億位用戶，並且能進微軟的，其實力不輸於某些開源社區的高手

最後，開源就更容易發現漏洞這不正確，不論開源閉源，只有開發者多，使用者多，才更容易發現漏洞!!

有人提到閉源發現漏洞藏著掖著，這個真的可笑，這樣的醜聞放出去會害死一家商業公司，稜鏡門事件微軟沒有參與，但是已經損失了巴西政府這一重要客戶了，傷不起了，每年200多萬哦

如果有一天你遇到一個應用程序在某個閉源庫中崩潰而該庫無源代碼只能跟蹤反彙編去調試時你就希望該庫是開源的了。

我覺得很多人是搞錯了，或者說是故意在混淆概念。

開源無助於發現軟體中的缺陷，開源只是有助於解決軟體中的缺陷。

對於商業軟體而言，如果你不是他的客戶（譬如說你裝的盜版軟體），即使有缺陷，他也不會為你解決（其實微軟算厚道的了，你不關掉自動更新還是會給你打補丁的，只是友情提醒你是個盜版用戶而已）。如果這一軟體已經停止維護，例如Windows XP，那麼這一缺陷可能永遠都無法解決。

而開源則沒有這個問題，當你發現了缺陷後，只需要自己擼袖子上就可以了。

什麼？你看不懂代碼？！

我認為，很多人都搞不清楚理論和實踐。沒錯，軟體的質量是靠「開發過程」來保障的，但是，你靠什麼在有限的資源下實踐正確的開發過程？

在我看來，至少有一個 proprietary 軟體的質量可以和優秀的開源軟體媲美，就是 VxWorks。VxWorks 的開發實踐是什麼呢？資金充足，有 NASA 這樣的鐵杆用戶。二十幾年沒有增加大 feature，做自己認為的 right thing，但是從未減少力量修改 bug。

But VxWorks is an exception rather than the rule of proprietary software. 試問唯投資者馬首是瞻的商業軟體有幾個能堅持做 the right thing。如果這個 right thing 是二十年不增加不必要的 feature，還能有開發者幾十年如一日的修改 bug？

開源軟體也是軟體。對開源軟體的品質影響因素的衡量標準，和私有軟體相比沒什麼不同。軟體品質的影響要素無外乎：

問題的複雜程度
開發者素質
使用者反饋
流程式控制制

問題的複雜程度是不可變更的，比如HFS和GFS在問題上可以看作是相同的，MySQL和Oracle也是相同的。

開發者素質與流程式控制制緊密相關。有商業公司參與的項目，通常開發人員素質更高，流程式控制制也更加合理。典型的例子包括LLVM，Apache，Git（這也是由基金會開發的），WebKit，V8等。如果OpenSource是沒有什麼收入來源的項目，特別是魚龍混雜的非知名項目，其素質可想而知。

使用者反饋可以分為兩個方面，一個是使用者數量，一個是反饋的質量。前者或許某些開源軟體會略有優勢，因為整個社區都傾向於使用免費和有開源代碼的東西。但是反饋的質量，才是真正的問題。例如我在LLVM中發現了一些Bug：

首先我無力對所有的bug都提交補丁；
其次我所使用的很可能是一些Corner case，對一般用戶沒有幫助，所以LLVM社區也未見得願意對我的需求做出修正；
再次，我沒有付費，不受重視是很普遍的事情。
最後，即便我有能力做出調整，也未見得願意將反饋融入到主幹之中。如果我是付費服務，那麼我更願意反饋回開發者去修復我的問題，畢竟是花了錢的。如果是Open的軟體，我既可以選擇自己私藏，也可以選擇根據我自己的需求另開分支。開源社區的版本分裂和私有化問題大家也是有目共睹的。

所以說，使用者數量本身並不是OpenSource的優勢所在，相反可能還是掣肘的重要因素。所以開源與否對產品品質沒有什麼影響，更加重要的是這個項目是不是有足夠的利潤來源讓開發者有足夠的動機來維護和改進產品。LLVM這樣的平台雖然不一定立即接受我的申請，但是起碼這是一支有錢的團隊，我當時提出的issue基本上已經修的差不多了。

換言之，商業化程度才決定了軟體的質量。相反的，軟體質量也左右了商業化程度。這是馬太效應顯著的又一領域。

我要是覺得，我這個程序缺陷很多，我一定不好意思開源，多丟臉。如果你不是名人，你開源的是一坨翔，沒人願意吃。

其實這個問題和有沒有無關，和你的產品好不好，用戶多不多，用的人越多自然發現得問題越多，彙報問題的人越多。如果差不多的東西，一個免費一個收費你說哪個用的人多？況且軟體這個東西很多時候沒辦法一眼區分好壞，你說同樣的功能，我幹嘛不用免費開源的啊？況且開源的萬一有問題，還能自己改。

PS：我以前做嵌入式的，由於嵌入式的特殊性，看過不少閉源軟體的源碼，因為要交叉編譯到我們平台，他們沒法做的，只好源碼拿來。說真的和開源軟體真的是半斤八兩（其實我還看過一個閉源包裝開源的，一個過渡設計的閉源），都是人寫出來的，開源軟體大多出於熱愛，閉源大多出於工作。閉源一個很大優勢就是你用了人家軟體，出了問題有擔當，其實他覺得開源閉源區別不大。

首先，我的觀點其實並不認可「開源有助於發現產品缺陷」。我覺得產品缺陷的控制要靠優秀的開發過程。

但是既然LZ有此疑問，我就從我的角度做一些分析。 @Milo Yip同學的觀點其實很有代表性。我嘗試以他提到的這個普遍的情況進行一下分析。

從「源代碼級的跟蹤調試」來看，我認為回答者想表達的是，作為一個「解決方案整合者」，技術水平、產品品質控制能力要高於解決方案中各個產品的提供者。這就揭示出了國內很多中小型軟體公司目前的「困境」（之所以困境兩個字用引號，是因為某些情況下可能反而是優勢）主要是試圖使用一系列「質量不那麼高」的產品組建出個高質量的產品，然後通過採購成本和銷售金額的差價中體現自己的價值。

這種思路本身沒有錯，所有的公司都是靠這麼賺錢的（包括微軟，谷歌也不例外啊），但是我想提出這個觀點的同學也許刻意迴避了軟體和硬體有著類似的「品質」屬性。你是願意花千把塊錢買雙New Balance來獲得較佳的跑步體驗，還是只願意花個百十來塊買雙回力隨便跑跑，雖然不同的用戶選擇都是對的，但是我敢肯定，100%這兩種鞋都穿過的人都會同意New Balance的鞋子好穿些（此處沒有詆毀哪個牌子的意思，只是舉例說明不同產品的品質確實可能存在不同）。

所以LZ這個問題在我看來，其實是一個更經典的，更經常被客戶們問的問題的翻版：「你的軟體憑什麼賣這麼貴？能不能再便宜點？」，不懂技術的銷售聽到這句話頭最大了。為了保證銷售，要求研發人員降低解決方案中的各個產品的採購價格就成為了一種很容易想到，也相對更容易實現的「節流」的做法。（此處我無償推薦 @徐強的一系列關於銷售的文章，我覺得那才是真正正確的銷售方法），於是「開源軟體」的市場需求就這麼出現了。

現在回頭說一下我對開源軟體出現的理解。我「堅信」開源軟體一開始的出現並不是為了讓大家更方便的「源代碼級的調試」的，因為那種方式從軟體開發的角度來看，實在是一種很糟（或者叫最下策）的項目開發實踐。在我看來，「開源」一開始是沖著「分享」去的，即希望通過「開源」的手段，實現軟體世界的資源共享，促進軟體世界開發技術的發展（而不是被某些巨頭所壟斷）。但是很遺憾，我認為這種願望帶有強烈的理想主義色彩，在商業社會主導的當前社會，是不可能完全實現的烏托邦（但是我同樣認為它的某些理念是能夠被商業社會所接受的）。

說了這麼多好像離題的分析，我的推斷是，這些認為「開源有助於發現產品缺陷」的人，估計是因為他的TODO list中優先順序更高的是便宜的價格，而非品質。這句話是為了讓他的理由更有說服力所找的託詞。而至於我為什麼不認同「開源有助於發現產品缺陷」，那屬於另外一個問題，就不在這個問題下分析了。

推薦Coverity，技術源自於斯坦福大學的最新一代的源代碼靜態分析工具，Coverity能夠快速檢測並定位源代碼中可能導致產品崩潰、未知行為、安全缺口或者災難性故障的軟體缺陷。具有缺陷分析種類多、分析精度高和誤報率低的特點，是業界誤報率最低的源代碼分析工具（小於10%）。Coverity Development Platform目前包含以下功能：

代碼質量缺陷與安全漏洞檢測：

Coverity 的智能靜態分析引擎能夠幫助開發者在工作流程中找出質量缺陷和安全漏洞，提供精確、可行的修復指導，在開發過程中識別關鍵質量缺陷，降低風險並減少項目成本。通過深刻理解行為和問題危急程度， Coverity SAVE 可以智能測試，精確找出那些潛在的難以發現的能夠引發崩潰的問題，包括C/C++, Java （JSP）和 C #（ASP），Objective-C, Android，Javascript, Python, PHP代碼庫。

能夠檢測出的質量缺陷類型示例：

? 空指針引用，資源泄漏，死鎖，內存崩潰，安全缺陷/緩衝區溢出，API使用錯誤，未初始化變數，類層次結構不一致，性能效率低下，安全最佳實踐違反，代碼維護問題，程序掛起，錯誤處理問題，並行數據訪問違規，競態條件，錯誤表達，控制數據流問題，內存非法訪問，不安全數據處理。

代碼安全與Web 應用安全審計:

Coverity 的安全審計引擎能夠通過識別JSP和ASP網站中可能導致安全漏洞的關鍵缺陷，降低風險和項目成本。Coverity Static Analysis Verification Engine 能夠智能檢測出C/C++應用和Java web應用中的缺陷，包括緩存區溢出、整數溢出、格式字元串錯誤、SQL注入、系統命令行注入、資源泄露、目錄遍歷和跨站腳本攻擊 (XSS)等問題，全面覆蓋OWASP Top10。

以往的安全工具在開發中失敗的主要原因是高誤報率或結果不正確。Coverity設計的新引擎，能夠解決現代應用的複雜問題，並獲得更為精準的結果。

適用於web應用安全的Coverity SAVE 分析創新包括：

?企業框架分析器: 深刻理解現代web 應用，增加源代碼分析包括依賴性注入，進入點以及MVC範例

?白盒模糊測試自動驗證日常數據清理慣例，對不可信數據進行充分清理，確保使用環境正確

客戶狀況：Coverity是第一個能夠快速、準確分析當今的大規模（百萬行、千萬行甚至上億行）、高複雜度代碼的工具，目前已經檢測了超過50億行專有代碼和開源代碼。全球有超過1100個像華為，中興，聯想，百度，三星，騰訊，Apple，Honeywell, NEC, BAE Systems, Juniper Networks, BMC Software, Samsung, France Telecom, Sega, 和 Schneider Electric這樣的品牌和企業依靠Coverity確保其產品和服務的質量與安全。

如果想了解更多信息的話，直接聯繫我。

哈哈應該說，在相同的資源投入下.

不設前提的對比是沒有意義的.

開源項目OpenSSL漏洞Heartbleed的曝光引發了開源閉源項目安全的爭論。Coverity每年都會掃描大量開源和閉源項目的代碼，評估其質量發現其缺陷。最新的報告顯示，開源項目的代碼質量（以缺陷密度這一數據進行衡量）優於閉源項目。Coverity掃描分析了超過700個開源C/C++項目和閉源企業軟體項目的樣本，發現開源C/C++項目的平均缺陷密度為0.59（缺陷密度1代表每一千行代碼發現一個缺陷），企業閉源項目的平均缺陷密度為0.72。報告稱，Linux平均修復一個新發現缺陷的時間僅僅只需要6天，它的850多萬行代碼的缺陷密度為0.61；被掃描的Java項目開發者只修復13%的已識別資源泄漏bug，而 C/C++項目開發者修復了46%。

http://www.solidot.org/story?sid=39173

我還是直接上數據吧。

那本《大教堂與集市》就有說這個，因為眼球足夠多。越多人用你的開源軟體，就越容易發現潛在的BUG。好像有項調查是說商業軟體的用戶越多，維護的期限就越長，因為越容易發現BUG。Linux也是這樣發展起來的。

因為那些認為閉源發現缺陷更多的人沒告訴你他們的觀點。

『在開源項目中，所有人都能夠直接閱讀源代碼，因此開源項目中的缺陷更容易被發現。』——這是相當簡單直觀無缺陷的說法。

可是~人家願不願意看源代碼，發現缺陷之後報不報告，報告之後開發者修不修復，就很看人品了。你們知道哪個環節不給力了吧，所以請黑對地方。

公，生明

開源軟體項目如果質量不高技術不過硬，就不會根本有人有信心去用，也不會有人加盟。

所以，雖然GitHubt上大把的垃圾，但是大家耳熟能詳的開源軟體其實都是軟體質量的佼佼者。

這就造成了「開源質量高」的錯覺，得到了「開源有助質量」的錯誤因果結論。

不過，極受歡迎的開源軟體，確實能達到比極佳的商業軟體更高的質量。正因如此，安全相關的庫一定要開源。只有這樣才能凝結多個彼此競爭的機構和領域專家共同的心血（Heart bleed毫無壓力）。

事實上有大型團隊開發的開源項目，為了讓新成員容易融入，通常會有規範的代碼和完善的文檔……不是閉源項目沒有，只是你不一定能取到，只好黑盒。

前提是該開源項目能獲得足夠的關注。不管怎麼樣，開出去，要先過自己（或團隊）的心理關。

因為每個人容易忽略的缺陷問題很可能不一樣，所以可以在大量的程序員在對開源程序的使用過程中，通過不斷地檢錯、糾錯，打補丁、修正，來彌補這些缺陷。

再有，開源程序因為其代碼的公開性，可以大大減少後門存在的可能性。

當然使用的人越多

別人都來給你找問題當然有助於你

懶。開源的好歹看起來算是適者生存經過考驗的。

－－－－－－－－－－－－－－－－－

保險，可以跟代碼查錯或針對需求做修改（修改的成本一般比開發小）

足夠多的眼睛，就能發現所有的bug