跳至內容

開源軟體

本頁使用了標題或全文手工轉換
維基百科,自由的百科全書
開放原始碼促進會(OSI)徽標

開源軟體(英語:open source software縮寫OSS)又稱開放原始碼軟體,是原始碼可以任意取用的電腦軟體,這種軟體的著作權持有人在軟體協定的規定下保留一部分權利並允許使用者學習、修改以及以任何目的向任何人分發該軟體。開源協定通常符合開放原始碼的定義的要求。一些開源軟體釋出到公有領域。開源軟體常公開和合作開發。開源軟體是開放原始碼開發的最常見例子,也經常與使用者創作內容比較[1]。開源軟體的英文「open source software」一詞出自自由軟體的行銷活動[2]

開源軟體同時也是一種軟體散佈模式。一般軟體僅可取得已編譯的二進位可執行檔(exe),通常只有軟體作者或著作權所有者等擁有程式原始碼。

有些軟體的作者只將原始碼公開,卻不符合「開放原始碼」的定義及條件,因為作者可能設定公開原始碼的條件限制,諸如限制可閱讀原始碼的對象、限制衍生產品等,此稱之為公開原始碼的免費軟體(Freeware,例如知名網路論壇軟體Discuz!),因此公開原始碼的軟體並不一定可稱為開放原始碼軟體。

歷史

[編輯]

1997年,埃里克·雷蒙出版其著作《大教堂和市集》,探討駭客社群與自由軟體原則。1998年初,該論文受到極大的關注,為促成網景通訊公司將其受歡迎的網際網路套裝軟體《網景通訊家》釋放成為自由軟體的因素之一。這些程式碼即為今日大家熟悉的Mozilla FirefoxThunderbird

網景的行動激起雷蒙及其夥伴深入研究如何將自由軟體基金會的自由軟體概念及優點帶入商業軟體產業。他們查覺基金會的社會活動不如網景等公司的行動來得吸引人,因而試圖重新包裝自由軟體運動,以強調分享與協作軟體原始碼的潛在商機。他們選用的新名稱為「開放原始碼」(open source),很快地布魯斯·佩倫斯、出版家提姆·奧萊理林納斯·托瓦茲及其他人支持新名稱。開放原始碼促進會於1998年2月建立,以推動使用新名稱,並宣揚開放原始碼的原則[3]

開放原始碼的定義

[編輯]

開放原始碼的定義由Bruce Perens(一位Debian創始人)定義如下:

  • 自由再散布(Free Distribution):允許獲得原始碼的人可自由再將此原始碼散佈。
  • 原始碼(Source Code):程式的可執行檔在散佈時,必需以隨附完整原始碼或是可讓人方便的事後取得原始碼。
  • 衍生著作(Derived Works):讓人可依此原始碼修改後,在依照同一授權條款的情形下再散佈。
  • 原創作者程式原始碼的完整性(Integrity of The Author's Source Code):意即修改後的版本,需以不同的版本號碼以與原始的程式碼做分別,保障原始的程式碼完整性。
  • 不得對任何人或團體有差別待遇(No Discrimination Against Persons or Groups):開放原始碼軟體不得因性別、團體、國家、族群等設定限制,但若是因為法律規定的情形則為例外(如:美國政府限制高加密軟體的出口)。
  • 對程式在任何領域內的利用不得有差別待遇(No Discrimination Against Fields of Endeavor):意即不得限制商業使用。
  • 散布授權條款(Distribution of License):若軟體再散佈,必需以同一條款散佈之。
  • 授權條款不得專屬於特定產品(License Must Not Be Specific to a Product):若多個程式組合成一套軟體,則當某一開放原始碼的程式單獨散佈時,也必需要符合開放原始碼的條件。
  • 授權條款不得限制其他軟體(License Must Not Restrict Other Software):當某一開放原始碼軟體與其他非開放原始碼軟體一起散佈時(例如放在同一光碟片),不得限制其他軟體的授權條件也要遵照開放原始碼的授權。
  • 授權條款必須技術中立(License Must Be Technology-Neutral):意即授權條款不得限制為電子格式才有效,若是紙本的授權條款也應視為有效。

儘管一開始接受[4]自由軟體基金會理查·斯托曼現在斷然反對將「開源軟體」與「自由軟體」混為一談。雖然在法律上並未明確區分自由軟體與開源軟體,但斯托曼認為不宜濫用[5]

開源軟體開發

[編輯]

開發模型

[編輯]

在他1997年的文章大教堂與集市中,[6]開源倡導者Eric S. Raymond提出了一種被稱為"集市"模型的開發OSS的模型。Raymond 將傳統方法開發軟體與建造大教堂相類比,"由個別巫師或小團隊的法師精心製作"。[6]他建議所有軟體都應該使用集市風格開發,他將其描述為"各種不同議程和方法的大雜燴集市"。[6]

然而,在傳統的開發模型中,他稱之為"大教堂"模型,開發是以中心化的方式進行的。角色是明確定義的,角色包括負責設計的人(建築師)、負責專案管理的人以及負責實施的人。傳統的軟體工程遵循大教堂模型。

然而,集市模型是不同的。在這個模型中,角色並沒有明確定義。Gregorio Robles[7] 提出,使用集市模型開發的軟體應該表現出以下模式:

使用者應被視為共同開發者

[編輯]

使用者被視為共同開發者,因此他們應該可以訪問軟體的原始碼。此外,鼓勵使用者提交對軟體的添加、代碼修復、漏洞報告、文件等。擁有更多的共同開發者增加了軟體演化的速度。林納斯之法則說:"只要眼睛足夠多,所有的錯誤都是淺顯的。"這意味著如果有很多使用者檢視原始碼,他們最終會找到所有的錯誤並提出如何修復它們的建議。請注意,一些使用者具有進階的編程技能,此外,每個使用者的電腦提供了額外的測試環境。這個新的測試環境提供了尋找和修復新錯誤的能力。

早期釋出

[編輯]

軟體的第一個版本應該儘早釋出,以增加儘早找到共同開發者的機會。

頻繁整合

[編輯]

代碼更改應儘可能經常地整合(合併到共享的代碼庫中),以避免在專案生命周期末期修復大量錯誤的開銷。一些開源專案有每晚構建,自動進行整合

多個版本

[編輯]

應該有至少兩個版本的軟體。應該有一個具有更多功能但更不穩定的版本和一個具有更少功能但更穩定的版本。有問題的版本(也稱為開發版本)是為希望立即使用最新功能並願意接受尚未經過充分測試的代碼風險的使用者準備的。使用者然後可以充當共同開發者,報告錯誤並提供錯誤修復。

高度模組化

[編輯]

軟體的一般結構應該是模組化的,允許獨立組件的並列開發。

動態決策結構

[編輯]

需要一個決策結構,無論是正式的還是非正式的,根據不斷變化的使用者需求和其他因素進行戰略決策。與極限編程進行比較。

然而,資料表明,OSS 並不像集市模型所暗示的那麼民主。對 31,999 位開發者編寫的五十億位元組的自由/開原始碼進行的分析顯示,74% 的代碼是由最活躍的 10% 的作者編寫的。一個專案中參與的作者平均有 5.1 人,中位數為 2 人。

優勢

[編輯]

開源軟體通常比專有軟體更容易取得,這通常會增加其使用率。此外,標準的開源實現的可用性可以增加對該標準的採用。[8] 它還有助於建立開發者的忠誠度,因為開發者感到有權力並對最終產品有一種所有權感。[9]

此外,OSS 需要更低的市場行銷和後勤服務成本。這是一種宣傳公司形象,包括其商業產品的好工具。[10] OSS 開發方法有助於快速、廉價地生產可靠的高品質軟體。[11]

開源開發提供了加速創新和創新和社會價值創造的潛力。例如,在法國,一項政策鼓勵政府支援自由開源軟體,導致每年近 60 萬次 OSS 貢獻,通過增加開源軟體的數量和品質來生成社會價值。這一政策還導致了科技初創公司的增加約 18%,以及IT部門就業人數的增加約 14%。[12]

據說它更可靠,因為通常有數千名獨立程式設計師測試和修復軟體的錯誤。開源不依賴於最初建立它的公司或作者,即使公司失敗,代碼仍然存在並由其使用者開發。此外,它使用對每個人都可訪問的開放標準;因此,它不會出現在專有軟體中可能存在的不相容格式的問題。

它是靈活的,因為模組化系統允許程式設計師構建自訂介面或添加新的功能,並且它是創新的,因為開源程式是許多不同程式設計師合作的產物。不同的觀點、公司目標和個人目標的混合加速了創新。

此外,自由軟體可以根據純技術要求進行開發。它不需要考慮商業壓力,這往往會降低軟體的品質。商業壓力使傳統軟體開發人員更加關注客戶的需求,而不是安全需求,因為這些特性對客戶而言有些看不見。[13]

開發工具

[編輯]

在 OSS 開發中,工具用於支援產品和開發過程的開發。[14]

Concurrent Versions System(CVS)和後來的Subversion(SVN)和Git這樣的版本控制系統是工具的範例,通常本身也是開源的,有助於管理軟體專案的原始碼檔案和對這些檔案的更改。[15][16] 這些專案通常儲存在像LaunchpadGitHubGitLabSourceForge這樣的倉庫中,這些倉庫是代管並發布在原始碼代管設施上的。[17]

開源專案通常組織鬆散,"很少有形式化的流程建模或支援",但通常使用問題跟蹤器等工具來組織開源軟體開發。[14] 常用的bugtracker包括BugzillaRedmine

mailing listsIRC這樣的工具提供了協調開發人員之間的手段。[14] 集中式代碼代管站點還具有允許開發人員進行溝通的社交功能。[17]

組織

[編輯]

一些參與開源軟體開發的「知名組織」包括Apache Software Foundation,他們是Apache網路伺服器的建立者;Linux Foundation,這是一個非營利組織,截止到2012年,由Linux作業系統的創造者Linus Torvalds僱傭,該作業系統的核心是Linux kernelEclipse Foundation,這是Eclipse軟體開發平台的所在地;Debian Project,他們是著名的Debian GNU/Linux發行版的建立者;Mozilla Foundation,這是Firefox網路瀏覽器的所在地;以及OW2,這是一個歐洲社群,致力於開源中介軟體的開發。新組織往往擁有更複雜的治理模型,其成員通常由法律實體成員組成。[18]

開放原始碼軟體研究所英語Open Source Software Institute是一個成員制的非營利組織(501(c)(6)),成立於2001年,旨在促進在美國聯邦、州和地方政府機構內開源軟體解決方案的開發和實施。OSSI的努力重點是在聯邦政府、國防部和國土安全部社群內推廣開源軟體程式和政策的採用。[19]

美國開源組織英語Open Source for America是一個旨在提高美國聯邦政府對開源軟體的好處的認識的團體。他們的目標是鼓勵政府使用開源軟體,參與開源軟體專案,並採用開源社群動態,以增加政府的透明度。[20]

軍事開源軟體工作小組英語Mil-OSS是一個致力於在軍事領域推動開源軟體的使用和建立的團體。[21]

資金

[編輯]

以開源軟體開發為中心的公司採用各種商業模式來解決提供根據定義免費授權的軟體如何賺錢的挑戰。這些商業策略的基礎都是,開源技術的使用者願意購買在專有授權下的附加軟體功能,或者購買其他服務或價值元素,以補充核心業務中的開源軟體。這種附加價值可以包括但不限於,符合企業級要求的功能和正常執行時間保證(通常通過服務級別協定提供)以滿足業務或合規要求,通過尚未在開源版本中提供的功能獲得效能和效率提升,法律保護(例如,免受著作權或專利侵權的賠償),或者與專有軟體應用程式典型的專業支援/培訓/諮詢等專業支援。

開放原始碼與自由軟體

[編輯]

許多人將開放原始碼與自由軟體(Free Software)視為相同,但若以定義條件而言,自由軟體僅是開放原始碼的一種,也就是自由軟體的定義較開放原始碼更為嚴格,並非開放原始碼的軟體就可稱為自由軟體,要視該軟體的授權條件是否合乎自由軟體基金會對自由軟體所下的定義:

自由軟體是在電腦個人或為公共利益,而非私人公司或政府等企圖限制或監視我們工作時,我們在學校公司使用時,我們具有其控制[22]

開放原始碼有時不單指開放原始碼軟體,它同時也是一種軟體開放模式的名稱。使用開放原始碼開放模式的軟體代表就有Linux作業系統

嚴格地說來,開放原始碼軟體與自由軟體是兩個不同的概念,只要符合開源軟體定義的軟體就能稱為開放原始碼軟體(開源軟體)。自由軟體是一個比開源軟體更嚴格的概念,因此所有自由軟體都是開放原始碼的,但不是所有的開源軟體都能稱為「自由」。但在現實上,絕大多數開源軟體也都符合自由軟體的定義。比如,遵守GPLBSD授權的軟體都是開放的並且是自由的。

「開放原始碼軟體運動」是一個主要由程式工程師及其它電腦使用者參與的聲勢浩大的運動。它是自由軟體運動的一個分支,但兩者的差別並不明顯。一般而言,自由軟體運動是基於政治及哲學思想(有時稱為所謂駭客文化)的理想主義運動,而開放原始碼運動則主要注重程式本身的品質提升。

漏洞

[編輯]

雖然開放原始碼的堡壘看似嚴謹,但其實大部份的程式開發員都弄不清各種授權條款之間的差別,導致成為了小部份別有用心人士所利用的對象,較著名的例子有DivX,早期DivX雛形是LGPL自由軟體,由大部份優秀的軟體高手義務開發,但當軟體漸漸成形時,DivX的公司DXN利用LGPL漏洞將DivX閉源,大部分軟體愛好者都感到被出賣,所以著手開發了XviD。雖然XviD在軟體方面明顯比DivX優秀,但市場佔有率卻不如DivX。

授權條款

[編輯]

開源軟體有授權條款(Open Source License),使用者需要遵守授權條款規定。保護開源軟體利益。如:GNU通用公眾授權條款BSD授權條款MIT授權條款等等。使用開源軟體前使用者應該仔細閱讀授權條款。

參考文獻

[編輯]
  1. ^ Verts, William T. Open source software. World Book Online Reference Center. 2008-01-13. (原始內容存檔於2011-01-01). 
  2. ^ Frequently Asked Questions. Open Source Initiative. [2008-09-08]. (原始內容存檔於2006-04-23). 
  3. ^ History of the OSI. Opensource.org. [2015-04-26]. (原始內容存檔於2007-08-08). 
  4. ^ Tiemann, Michael. History of the OSI. Open Source Initiative. [2014-05-13]. (原始內容存檔於2011-11-27). 
  5. ^ Stallman, Richard. Why "Open Source" misses the point of Free Software. Philosophy of the GNU Project. Free Software Foundation. 2007-06-16 [2007-07-23]. (原始內容存檔於2011-08-04). As the advocates of open source draw new users into our community, we free software activists have to work even more to bring the issue of freedom to those new users' attention. We have to say, 'It's free software and it gives you freedom!'—more and louder than ever. Every time you say 'free software' rather than 'open source,' you help our campaign. 
  6. ^ 6.0 6.1 6.2 Raymond, Eric S. The Cathedral and the Bazaar. 2000-09-11 [2004-09-19]. (原始內容存檔於2005年8月26日). 
  7. ^ Robles, Gregorio. Software Engineering Methods for Free Software (PDF). Robert A. Gehring, Bernd Lutterbeck (編). Open Source Yearbook 2004. 柏林: 柏林工業大學. 2004 [2020年2月11日]. (原始內容 (PDF)存檔於2015年11月7日). 
  8. ^ U.S. Department of Defense. Open Source Software FAQs. Chief Information Officer. [2016年7月22日]. (原始內容存檔於2016年8月28日). 
  9. ^ Sharma, Srinarayan; Vijayan Sugumaran; Balaji Rajagopalan. A framework for creating hybrid open source software communities (PDF). 資訊系統期刊. 2002, 12: 7–25 [2008年9月8日]. S2CID 5815589. doi:10.1046/j.1365-2575.2002.00116.x. (原始內容存檔 (PDF)於2008年10月30日). 
  10. ^ Landry, John; Rajiv Gupta. 从开源中获利. Harvard Business Review. 2000年9月. doi:10.1225/F00503. 
  11. ^ Reynolds, Carl; Jeremy Wyatt. Open source, open standards, and medical information systems. Medical Internet Research. 2011年2月, 13 (1): e24. PMC 3221346可免費查閱. PMID 21447469. doi:10.2196/jmir.1521可免費查閱. 
  12. ^ Nagle, Frank. Government science and technology policy, social value, and national competitiveness. 羅切斯特,紐約. 2019年3月3日. S2CID 85509685. SSRN 3355486可免費查閱. doi:10.2139/ssrn.3355486 (英語). 
  13. ^ Payne, Christian. On the security of open source software. Journal of Information Systems. 2002年2月, 12 (1): 61–78. S2CID 8123076. doi:10.1046/j.1365-2575.2002.00118.x. 
  14. ^ 14.0 14.1 14.2 Boldyreff, Cornelia; Lavery, Janet; Nutter, David; Rank, Stephen. Open Source Development Processes and Tools (PDF). Flosshub. [2016年7月22日]. (原始內容 (PDF)存檔於2016年10月7日). 
  15. ^ Stansberry, Glen. 7 Version Control Systems Reviewed - Smashing Magazine. Smashing Magazine. 2008年9月18日 [2016年7月22日]. (原始內容存檔於2015年5月9日). 
  16. ^ Levine, Sheen S.; Prietula, Michael J. software development process. Saigon Technology - 6 Stages for Software Development Procedure You Need to Know. [2022-01-22]. (原始內容存檔於2023-10-03). 
  17. ^ 17.0 17.1 Frantzell, Lennart. GitHub, Launchpad, and BitBucket, how today's distributed version control systems are driving an unprecedented global open source revolution. IBM developerworks. 2016年7月18日 [2016年7月22日]. (原始內容存檔於2016年8月19日). 
  18. ^ François Letellier. Open Source Software: the Role of Nonprofits in Federating Business and Innovation Ecosystems (PDF). flet.netcipia.net. [2023-09-26]. 原始內容存檔於2012-08-06. 
  19. ^ Open Source Software Institute. Home. Open Source Software Institute. [2016年7月22日]. (原始內容存檔於2016年8月13日). 
  20. ^ Hellekson, Gunnar. Home. Open Source for America. [2012年3月25日]. (原始內容存檔於2015年12月1日). 
  21. ^ from EntandoSrl (Entando ). Mil-OSS. [2012年3月25日]. (原始內容存檔於2011年9月3日). 
  22. ^ [The Free Software Foundation (FSF) ]

外部連結

[編輯]

參見

[編輯]