维基百科

开源软件

源代码以开放源代码授权条款提供的软件
提示：此条目的主题不是自由软件或看源软件。

开源软件（英语：open source software，缩写：OSS）又称开放源代码软件，是源代码可以任意获取的计算机软件，这种软件的版权持有人在软件协议的规定下保留一部分权利并允许用户学习、修改以及以任何目的向任何人分发该软件。开源协议通常符合开放原始码的定义的要求。一些开源软件发布到公有领域。开源软件常公开和合作开发。开源软件是开放源代码开发的最常见例子，也经常与用户生成内容比较[1]。开源软件的英文“open source software”一词出自自由软件的营销活动[2]。

开放源代码促进会（OSI）徽标

开源软件同时也是一种软体散布模式。一般软体仅可取得已编译的二进位可执行档（exe），通常只有软体作者或著作权所有者等拥有程式原始码。

有些软体的作者只将原始码公开，却不符合“开放原始码”的定义及条件，因为作者可能设定公开原始码的条件限制，诸如限制可阅读原始码的对象、限制衍生产品等，此称之为公开源代码的免费软件（Freeware，例如知名网络论坛软体Discuz!），因此公开原始码的软体并不一定可称为开放原始码软体。

历史

编辑

1997年，埃里克·雷蒙出版其著作《大教堂和市集》，探讨黑客社群与自由软体原则。1998年初，该论文受到极大的关注，为促成网景通讯公司将其受欢迎的网际网路套装软体《网景通讯家》释放成为自由软体的因素之一。这些程式码即为今日大家熟悉的Mozilla Firefox与Thunderbird。

网景的行动激起雷蒙及其伙伴深入研究如何将自由软体基金会的自由软体概念及优点带入商业软体产业。他们查觉基金会的社会活动不如网景等公司的行动来得吸引人，因而试图重新包装自由软体运动，以强调分享与协作软体原始码的潜在商机。他们选用的新名称为“开放原始码”（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] 这些项目通常存储在像Launchpad、GitHub、GitLab和SourceForge这样的仓库中，这些仓库是托管并发布在源代码托管设施上的。[17]

开源项目通常组织松散，"很少有形式化的流程建模或支持"，但通常使用问题跟踪器等工具来组织开源软件开发。[14] 常用的bugtracker包括Bugzilla和Redmine。

像mailing lists和IRC这样的工具提供了协调开发人员之间的手段。[14] 集中式代码托管站点还具有允许开发人员进行沟通的社交功能。[17]

组织

编辑

一些参与开源软件开发的“知名组织”包括Apache Software Foundation，他们是Apache网络服务器的创建者；Linux Foundation，这是一个非营利组织，截止到2012年，由Linux操作系统的创造者Linus Torvalds雇佣，该操作系统的核心是Linux kernel；Eclipse 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操作系统。

严格地说来，开放源代码软件与自由软件是两个不同的概念，只要符合开源软件定义的软件就能称为开放源代码软件（开源软件）。自由软件是一个比开源软件更严格的概念，因此所有自由软件都是开放源代码的，但不是所有的开源软件都能称为“自由”。但在现实上，绝大多数开源软件也都符合自由软件的定义。比如，遵守GPL和BSD许可的软件都是开放的并且是自由的。

“开放源代码软件运动”是一个主要由程序工程师及其它电脑用户参与的声势浩大的运动。它是自由软件运动的一个分支，但两者的差别并不明显。一般而言，自由软件运动是基于政治及哲学思想（有时称为所谓黑客文化）的理想主义运动，而开放源代码运动则主要注重程序本身的质量提升。

漏洞

编辑

虽然开放原始码的堡垒看似严谨，但其实大部份的程式开发员都弄不清各种许可证之间的差别，导致成为了小部份别有用心人士所利用的对象，较著名的例子有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) ]

外部链接

编辑

参见

编辑
检索自“https://zh.wikipedia.org/w/index.php?title=开源软件&oldid=85138864”