开源产品四项原则（以及 10 张幻灯片）| Opensource.com

图片来源：

Opensource.com

当使用开源软件构建产品时，需要理解四个原则。产品团队（工程、产品管理、市场营销）需要理解这些原则，以便最好地参与到开源项目社区中，并同时向其客户交付产品和服务。这四个原则是关于开源产品领域所有其他讨论的起点。

原则 #1：你总是获得的比付出的多

随着时间的推移，对技术的投资遵循正态分布。将对开源项目的投资视为堆叠条形图，其中公司和个人的贡献加在一起，取代了单个公司的投资。因此，在开源项目中，收集到的投资看起来与单个公司在开发封闭专有软件产品时的投资看起来相同。个人和公司贡献是为了满足他们自己的自私需求。这是一个完美的非对称关系，贡献者放弃了一些相对价值较小的东西（他们的贡献），却获得了实质性的回报（一整套可用的软件）。可以看看 Openstack 或 Linux 内核，以最清晰地看到这种活动。与其将其视为放弃 IP，不如将其正确地视为获得所有剩余的 IP。

代码行数和 COCOMO 计算来自 Openhub.net 的存储库抓取。我完全理解代码行数有多么的不可靠。我理解对 COCOMO 准确性的担忧，但即使它们不是完美的模型，也是具有代表性的模型，并且它们适当地显示了趋势。

原则 #2：不要将项目与产品混淆

这一点有时很难理解。首先，我们需要假设我们谈论的是一个运行良好、成功的开源项目。（更多内容见原则 #3 和 #4。）一个项目是可安装、可运行并解决有趣问题的可工作软件的集合。它是软件开发人员（即提交者）和希望更大的用户和贡献者集合之间在代码中的协作和对话。产品是为客户解决问题以赚钱的东西。

项目不是产品。 虽然许多优秀的软件可以来自运行良好的开源项目，从而减轻工程方面的一些工作（参见原则 #1），但要将其转化为为客户解决问题的产品，仍然需要做大量的工作。Linux 内核是一个项目。Fedora 是一个发行版项目。RHEL 是一个产品。“但是 Ubuntu 呢？”你可能会问。这是商业模式的一种变体。Ubuntu 是一个发行版项目。长期支持 (LTS) 版本是 Canonical 多个产品的基础。

产品满足客户对物有所值的期望。它们开箱即用、运行，并附带保修和赔偿、服务（支持、升级、培训、咨询）和文档。产品可以是围绕项目构建的服务或硬件。产品的种类繁多，就像客户希望花钱解决的市场问题一样。虽然好的项目满足了前两个条件（安装、运行），但它们并没有以相同的方式关注客户。项目解决的问题也比客户希望解决的问题狭窄得多。

不要对涉及哪些开源许可证以及它们是否“对商业友好”感到困惑。不同的供应商围绕不同的许可证使用不同的策略。围绕每个主要的 OSI 批准的许可证都有成功案例和失败案例。与业务执行相比，许可证是无关紧要的。

原则 #3：不要将社区与客户混淆

这条原则与原则 #2 紧密相连，如果说有什么不同的话，那就是更难理解。如果原则 #2 是关于工程和商业模式，那么原则 #3 就是关于信息传递和销售。社区和客户生活在不同的价值空间中。社区有时间，但没有钱。客户有钱，但没有时间。也许更好的说法是，客户花钱是为了加快解决方案并消除风险，而社区（社区中的个人）没有钱。

传统上，工程部门将产品输入管道，市场营销部门传递信息，销售部门将合格的潜在客户拉入封闭交易。一个简单的执行问题。许多使用开源的公司认为项目社区是此管道的一部分，当他们在社区论坛中找到客户时，他们更相信这一点。他们甚至可能认为社区项目是先试后买。所有这些都是错误的。

公司（产品管理、工程、市场营销）与其相关社区进行的对话以及与付费客户进行的对话是不同的对话。每次对话都有特定的工具和参与规则。成功的公司了解如何进行这些对话。有成熟的工具用于构建和筛选管道。同样有成熟的工具和规则用于发展成功的社区（原则 #4）。每个工具链和对话都有不同的指标需要捕获和考虑。

公司社区和客户之间存在互动。社区成员是项目的布道者（因此，以周到的方式将其与公司品牌联系起来是有价值的）。社区成员在潜在客户重新加入产品管道之前，在项目社区中提供支持和专业知识，这些潜在客户是自我筛选的。社区还通过成为专业知识和投入时间的汇集地，为最终产品解决方案提供惯性。挑战在于保持社区和客户之间的清晰分离，以便您可以快速轻松地识别您面前的人所扮演的角色，并适当地引导他们。信息中绝不能有混淆（无论是故意的还是无意的）。

例如，产品是为客户准备的。如果您有试用版，如先试后买，那么“买”字就在那里，所以，客户对话。如果您有社区版，那么请建立一个社区（原则 #4），否则您只是在开源许可下发布软件，而没有获得开源社区的任何好处。这些是不同的事情，这引出了我们最后的原则。

原则 #4：成功的开源项目社区遵循众所周知的模式和实践

所有成功的开源社区项目都遵循相同的模式和实践。项目开始于围绕少量核心开发人员的代码对话。需要构建三个入口。首先，推动使用并扩大用户群，因为这将导致开发人员找到您的项目。（你需要白嫖者！这意味着你做对了。）该软件必须易于安装和运行。用户会告诉你他们需要什么，即你会收到错误报告和功能请求，以换取你做对了这一点。更重要的是，开发人员会找到你。

其次，让构建已知、经过测试状态的软件变得非常容易。这将允许开发人员根据自己的需要进行自我选择和实验。假设聪明的开发人员会弄清楚是在浪费开发人员的周期。他们不会。没有人愿意在你的懒惰和缺乏纪律上浪费时间。他们会沮丧和厌恶地离开。让他们回来将非常困难，甚至不可能。做好这一点，你将获得下一组更难的错误报告和可能的建议修复。

第三也是最后，告诉开发人员如何以及在哪里贡献，并使其易于做到。感谢他们的贡献。如果要鼓励代码以外的其他内容，请清楚地设置这些贡献渠道并使其易于使用。定期说“谢谢”。尽可能奖励人们，尤其是当您是一家公司时。

建立社区是艰苦的工作。它不是免费的。然而，它确实带来了价值，包括来自用户和开发人员的贡献，以及技术的粘性。

该领域的最后一组实践是围绕理解基金会和开源软件的作用。基金会组织和澄清 IP 管理制度。基金会可以做很多其他事情，但如果他们没有把这个核心事情做好，那么他们对项目社区的增长潜力来说就是失败的。澄清中立的 IP 所有权允许来自参与者和贡献者的专门投资增长整个生态系统，即试图为客户解决问题的公司。

基金会创造了中立的空间，公司可以在其中平等地参与。一家从他们没有启动和拥有的开源项目（例如 SUSE 和 Linux、HP 和 Openstack 等）构建产品的公司需要清楚地了解他们的贡献是如何处理的，并且他们不仅仅是在构建别人的产品。同样，一家启动了一个开源项目并希望推动围绕它构建的生态系统的采用和增长的公司，最好将项目软件 IP 贡献给一个单独的非营利基金会（或在适当的情况下创建一个），例如 Google 目前对 Kubernetes 所做的那样，或者 Pivotal 对 Cloud Foundry 所做的那样。这最终是第四个需要做对的入口。