规则引擎 开源产品_开源的四个规则的产品（和10张幻灯片）

规则引擎 开源产品

使用开源软件构建产品时需要了解四个规则。 产品团队（工程，产品管理，市场营销）需要了解这些规则，才能最好地参与开源项目社区，并同时向其客户提供产品和服务。 这四个规则是关于开源产品空间的所有其他讨论的开始。

规则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：成功的开源项目社区遵循易于理解的模式和实践

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

其次，使将软件构建为已知的，经过测试的状态非常容易。 这将使开发人员可以根据自己的需求进行自我选择和试验。 假设一个聪明的开发人员会弄清楚它正在浪费开发人员的周期。 他们不会。 没有人愿意浪费时间在你的懒惰和缺乏纪律上。 他们会感到沮丧和厌恶。 如果不是不可能的话，让他们回来将非常困难。 正确执行此操作，您将获得下一组更难的错误报告以及可能的建议修复程序。

第三，最后，告诉开发人员如何以及在何处做出贡献并使其易于实现。 感谢他们的贡献。 如果要鼓励除代码以外的其他事情，请明确设置这些贡献渠道并使其变得容易。 经常说“谢谢”。 无论如何，都应该奖励人们，尤其是在公司的时候。

建立社区是一项艰苦的工作。 它不是免费提供的。 但是，它确实带来了用户和开发人员的贡献以及对技术的粘性带来的价值。

在该领域的最后实践集是围绕了解基金会和开源软件的作用。 基金会组织和阐明知识产权管理制度。 基金会可以做很多其他事情，但是如果他们没有正确地完成这一中心任务，那么这对于项目社区的增长潜力来说是失败的。 明确中立的IP所有权可以增加对有兴趣发展整个生态系统的参与者和贡献者（即试图为客户解决问题的公司）进行专用投资的增长。

基金会创造了中立的空间，公司可以在其中平等地参与其中。 一家公司使用他们没有启动并拥有的开源项目来构建产品（例如SUSE和Linux，HP和Openstack等），需要清楚地了解他们的贡献是如何处理的，而不是简单地构建别人的产品。 同样，一家已经启动开源项目并希望推动其周围生态系统的采用和发展的公司，将项目软件IP贡献给一个单独的非营利基金会（或在适当时创建一个基金会）（例如Google目前正在使用Kubernetes，或者Pivotal已使用Cloud Foundry。 最终这是第四个正确的入口。

结论

所以你有它。 我在20多年的开源项目支持，基金会参与和产品工程学中所学到的一切，都归纳为四​​个规则，10张幻灯片和大约1,600字。 我期待提出问题和意见。

翻译自: https://opensource.com/business/15/8/open-source-products-four-rules

规则引擎 开源产品