让我们实现开源模型！ 但是……哪个开源？
有了足够的嘴巴，所有条款都是可疑的
对于组织而言，决定复制他人的“模型”以进行软件开发是非常普遍的。 人们倾向于在会议或博客文章上看到他们不合理的成功 ，并开始贴上“ X公司模式”的标签。
让我们实现Spotify模型 ！
让我们实现Netflix模型！
让我们实现Facebook模型！
这是一个秘密： 没有可以简单复制并成功的“模型” 。 每个组织都有一种文化。 这种文化的某些方面允许出现独特而成功的行为模式。 这些模式是高度上下文相关的：如果它对他们有用，并不意味着它们会对您有用。
还有当你试图实现别人的模式没有的，为什么它的工作原理任何理解，这就是所谓的名称天上掉馅饼 。
仅仅因为模型对组织有效，并不意味着它将对您的组织有效。
同样的事情也发生在开源上 。
许多组织依靠开源软件来完成大部分工作，但是几乎没有组织为使用的项目做任何贡献。 我曾与使用开源的人交谈过，甚至不了解代码的来源。 好像它是生活在互联网最黑暗角落中的高级人工智能的副产品。
即使某些开源项目是由一个营利性组织创建的，但其中许多并非如此。 以curl ， Linux或jQuery为例。 这些项目取决于很多没有薪水的人。 但是，软件是内置的，有时比其公司的同类产品具有更好的质量和稳定性。
非组织创建的软件如何成功？
看起来不合理 ，所以...
让我们实现开源模型！
但是，如果您问三个不同的人“开源”是什么意思，那么您很可能会收到三个不同的答复。
这个词正变得非常繁重。
“开源”正在变成“ Github”。
Github使所有人都能使用Git版本控制系统。 您可以创建，编辑和删除文件和文件夹，而无需键入单个git命令。 它专注于为Git存储库添加社交和用户友好的方面，这不是一件坏事。
Github仓库在线位于它们所属的用户名或组织的名称空间下。 叉子是他人名称空间下原始存储库的副本，它直接引用原始存储库。 通过Issues和Pull Requests完成协作。
在Github之前， Sourceforge是最受欢迎的网站，用于托管可公开访问的代码。 与今天的Github（2000万）相比，它的注册用户（208K）很小。
如果您想了解有关2017年Github开源状态的更多信息， Nadia Eghbal可以比我解释得更好 。
术语“开源”基本上与“ Github”相同。
在Github之前，开源是非常不同的。 Linux是一个榜样，人们刚刚开始公开创建大型软件项目。
没有人了解开源。
微软甚至试图说服公众说Mozilla的“开源”不是“美国”。
微软的政治尝试失败了，Mozilla Firefox超过了Internet Explorer，成为当时使用最广泛的浏览器。
1999年， 埃里克·雷蒙德 （ Eric S. Raymond）撰写了一篇名为《 大教堂和集市 》的文章。
文章指出，当代码分发，向公众开放并由许多人做出贡献时，项目将实施“ Bazaar”模型。 相反，当开发集中，对公众不公开且仅由选定的少数人贡献时，项目将实施“大教堂”模型。
大多数软件开发项目都作为“大教堂”进行管理，直到今天仍然如此。 在埃里克·雷蒙德（Eric Raymond）的观察中，Linux之所以成功是因为他们看到了对其他事物的需求。 他们所做的事情与当时其他人进行软件开发的情况相反。
Linux被作为“集市”进行管理。
Linux之所以成功，是因为它被作为“集市”而不是“大教堂”进行管理。
埃里克·雷蒙德（Eric Raymond）可能没有意识到的是，他的观察还见证了一项原则的应用，该原则后来于2001年被添加到《 敏捷宣言》中 ：“响应计划的转变”，也可以翻译成持续集成和持续交付：
[…]提前发布。 经常释放。 并倾听您的客户。 […]
— 埃里克·雷蒙德（Eric Raymond）网站上 “大教堂和集市”文章中的“经常发布，经常发布”一章。
与Github相比，Linux使用（并且仍然使用）邮件列表作为协作的主要方式。 原因可以总结在这篇文章中 ，我引用：
[…]内核开发人员仍在使用电子邮件，因为它比任何其他方法都快。
实际上， Github不能托管开源Linux内核社区 ，至少有两个原因：
- Github使用Pull Request来处理所有事情，包括个人贡献，而Linux Kernel使用Pull Requests（通过邮件列表）将更改转发到整个子系统，或者在不同子项目之间同步代码重构或类似的跨领域更改。
- Linux内核是具有多个存储库的单树。 它无法使用Github模型进行扩展，因为Github不支持同时提交到多个存储库的Pull Request，并且在所有存储库中共享一个讨论流。 Github的讨论仅在单个Pull Request中发生。
Linus Torvalds在树的顶部。 他就是埃里克·雷蒙德（Eric Raymond）所谓的“仁慈独裁者”：
[..]慈善独裁者组织从所有者维护者组织发展而来，因为创始人吸引了捐助者[…]
—《大教堂与集市：偶然的革命者在Linux和开放源码上的沉思》， 第7页。 101
Linux开源模型也很大程度上基于精英管理。 如果您编写的代码不错，并且补丁程序解决了重要问题或添加了重要功能，那么即使没有找到通往主线内核的方式，社区中的某些人也会接受它。
Git已分发。 Github不是。
Linux使用Git支持的分布式开发模型，该模型与Github不兼容。
开源计划于1998年成立 。 他们是创造了“开源”一词并创建了“开源定义”的人 。 它指出：
- 未混淆的源代码应公开可用。
- 许可证不需要支付特许权使用费或其他费用。
- 该许可证必须允许他人修改和衍生作品。
- 不得通过其他任何方式（例如保密协议）阻止该软件。
- 该项目不应歧视个人，团体或工作领域。
- 该软件不应限于特定发行版的一部分。
- 许可证不得限制与开源软件一起分发的其他软件。
[…]只有获得OSI批准的开放源代码许可证许可的软件才应标记为“开放源代码”软件。
— 开源倡议网站 。
有关更多信息，请参见The Open Source Definition的注释版本。
根据“开源倡议”的说法，要被称为“开源”，它必须符合其定义。
许多组织倾向于使用Github，创建名称空间和使用私有存储库。 但是，如果您的代码未打开并允许复制和分发，则它违反了“开源定义”。 因此，它离“开源”很远。
许多组织都有负责维护项目子集的团队，每个项目都有自己的存储库。 但是，一个开源项目往往会开发一个仁慈的独裁者 ，负责处理该项目最受信任的版本。
许多组织开始使用Github，因为有可能将其存储库存储在共享的集中式环境中。 但是，开放源代码项目本质上是分布式的，该分发有助于在社区之间共享源代码知识，并减少由于仁慈独裁者的存在而增加的总线系数 。
许多组织都使用Github Pull Requests作为个人， 成对或暴民为他们的存储库做出贡献的常用方式。 但是，构建Git Pull Requests（不要与Github Pull Request混淆）的目的是为了支持分布式协作环境。 邮件列表用于创建跨许多存储库所有者的讨论流。
在几乎每个组织中，项目经理都需要向业务利益相关者报告进度。 但是，在开源中，使用该软件的开发人员是涉众。 他们还具有技术专长，以了解其工作原理以及对它有什么好处。
在许多组织中，由于需要证明不同的薪资范围和期望是合理的，因此软件开发角色从初级到高级是分开的。 在开放源代码中，开发人员不需要这种歧视。 他们无意上班。 他们出于激情而这样做。 他们想产生影响，而不是收入 。
组织倾向于复制开源的工作方式，但是他们不知道开源是否适用于他们。
尽管有时不清楚“开源”对于不同的人真正意味着什么，但它有一个明确且记录在案的定义。
“开源计划”通过分发软件的许可证来定义“开源”。 除非符合其定义，否则不应将其称为“开源”。
在Github之前，开源是非常不同的。 Linux是榜样，随着时间的推移，Linux被迫扩展以管理其复杂的社区。 如今，他们无法有效使用Github，因为他们的模型不合适。
Github诞生了带有漂亮UI的流行开源概念。 它减少了进入的障碍，并允许任何人无需付出很多努力就可以公开其代码。
要在您的组织中实施“开源模型”，您需要了解它的含义。 这样，您将更加准备去测试他们的一些想法，看看其中哪些可以在您的上下文中起作用。
第一步是查看其中的内容，并了解“开源”为何以这种方式工作。
问题是： 哪个开源 ？
谢谢阅读。 如果您有任何反馈意见，请通过Twitter ， Facebook或Github与我联系。
From: https://hackernoon.com/lets-implement-the-open-source-model-but-which-open-source-a89c82d1b494