有时会遇到一家公司试图将现有产品构建成开源项目。这是一个微妙的问题。这与一家公司拥有以开源许可证发布的项目，并试图同时发布同名产品（例如 Docker、MySQL）的情况不同，但这种情况也存在许多相同的问题。这也不是一家公司利用他们贡献但不控制的开源项目（例如 Red Hat 的 RHEL）来构建产品的情况。这是一家拥有现有产品收入流的公司，试图从该产品创建一个项目。
在一种观点看来，这与围绕成功且良好运营的开源项目建立生态系统的正常演变问题相反。一个早期项目从可工作的代码和一小部分提交者开始，并且还没有企业参与者。如果项目构建良好，使用量就会增长。如果开发人员可以使用和修改它以满足自己的需求，那么贡献就可以回流。这假设项目组织良好、纪律严明且执行良好。然后，在项目的增长和演变过程中，会出现其他公司想要参与的点。该项目已证明自身足够强大，可以发展到新的领域。企业使用意味着产品和服务、客户期望以及投入到项目中的专用资源作为回报。基金会可以解决公司想要解决的知识产权（知识产权）风险缓解问题，当然前提是项目提交者希望以这种方式发展。
Linux 是这种增长的典范，但 Apache 项目也显示出类似的增长（例如 httpd、Hadoop），Perl 社区、Eclipse 和 Drupal 也是如此。
创建开源项目的价值
将产品带入开源世界需要不同的思维方式，尤其因为它是一种更加深思熟虑且不太自然的实践。总的来说，创建开源项目会在软件本身周围创造价值。这超越了参与者磨练硬技能和软技能以及学习新工具和思考问题的方式的价值。
- 随着经验的增长和新想法的贡献，它能够围绕软件进行创新。
- 审查文化已被证明比正式测试更能发现错误（如果社区在这方面得到支持），因此可以提高质量。
- 它允许软件更快地发展到其他领域，而不会受到中央规划或集中投资的瓶颈（即公司就追求哪些市场以实现增长做出艰难的选择）。
- 该软件通过在新环境中使用而得到加强。
- 它与有时间学习的人们一起创建了软件的专业知识和经验，这些人可能没有能力购买解决方案，因此扩大了整个项目生态系统中经验丰富的人员基础。
- 人们学习特定软件的工作原理。
作为一家致力于为客户带来价值的公司，这些都是社区为您的软件带来的积极价值回报。广播开发者网络（例如 MSDN）与围绕开源项目的社区之间存在细微差别，后者可以深入了解代码并具有贡献能力。公司获得的回报是深入的社区参与。（如果您想愤世嫉俗一点，那就是惯性，因为如果社区参与者将时间花在您的社区中，他们就不会探索其他供应商的经验。）
将产品和项目分开
我经常指出，我们需要在思考中将开源项目和产品清楚地区分开来（如果您是产品经理），并且不要混淆社区和客户（如果您在市场营销部门）。让我们尝试几种不同的方法来说明这一点。
当一款软件产品是新产品时，团队仍然处于交付的兴奋之中，并且该产品正在早期客户中证明自己，人们常常会将软件误认为是解决方案本身。这很难避免。交付投入了如此多的精力。但正如西奥多·莱维特所说，“人们不想要四分之一英寸的钻头。他们想要四分之一英寸的孔。” 总的来说，工具能够实现解决方案。它本身并不是解决方案。
同样真实的是，供应商随着时间的推移不断创新，在交付客户想要的解决方案方面变得越来越好。微软今天的魔力并非基于 Windows 操作系统本身的源代码。而是当您考虑需要在 10,000 家 OEM/ODM 和 10,000 家 ISV 之间完成的跨产品测试时，交付可执行捆绑包的能力是少数公司可以匹敌的。然后保证它、支持它、维护它、保护它，并及时满足企业客户的需求。_这_才是客户付费的价值。而不是源代码。
您可以在成功地交付来自他们不直接控制或拥有的开源组件的产品的公司中更清楚地看到这一点
- Red Hat 以二进制、受支持、有保证、维护、安全的产品形式交付 RHEL（Red Hat Enterprise Linux）。在早期，数据中心中的 RHEL 并非关于 Linux，而是关于一种廉价的支持 UNIX 的类产品，该产品在 PC 级服务器上运行，而不是在大型昂贵的 UNIX 系统上运行。Red Hat 知道其价值主张是什么。Sun Microsystems 已不复存在。DEC（Ultrix）也不复存在。AIX HP/UX 的装机量并没有真正增长。
- HortonWorks 和 Cloudera 专注于通过强大的产品和服务解决客户的大数据问题。他们各自的解决方案恰好是使用 Apache 社区中免费提供的软件构建的。
这绝不意味着软件、其源代码及其创建没有巨大的价值。但在许多情况下，这些是更成功的解决客户问题的产品创新的原材料（尽管它们很复杂）。开源软件是木材。在某些情况下，早期的项目具有树木的所有有机结构。
将产品转变为项目
这为试图将现有产品组合中的产品以有意义的方式公开为开源的公司提出了一系列非常有趣的问题。继续使用物理世界的木材示例：想象一下将房屋拆解回组件。木材被切割和塑造成房屋。它不再只是标准化的木材了。而对于通过收购和集成而增长的复杂软件套件来说，情况会变得更糟，这些套件的架构已被隐藏和颠覆，以简化客户体验和 UI 的一致性。
如果要将产品转变为项目，则需要回答两个问题
- 产品软件是否应该发布？如果该软件确实代表了客户的整个价值主张，那么发布它可能不是一个好主意。但如果是这种情况，那么此类产品将始终面临被其他类似的纯软件解决方案以及可能由更有能力交付客户价值的公司赶超的威胁。
- 产品软件是否可以合法发布？许多产品包含第三方许可软件，并且许多此类来自第三方的许可证禁止重新许可或发布。
假设仍然希望将产品转变为开源项目，则需要完成一系列活动，这些活动构建了一系列代表整个过程的步骤。
- 在 OSI 批准的许可证下发布源代码。（开源的最低定义。）
- 发布软件构建环境。这将允许其他开发人员在某些情况下实际构建有用的可执行文件。
- 接受贡献。这是社区证明测试。
- 建立真正的社区。这是全面的社区参与。
（点击放大）
为了使软件可发布，还需要做一些工作
- 产品到项目以及两者固有的分支都需要一致的、强大的源代码管理。
- 需要对源代码进行严格审查，以查找明显的“尴尬之处”（包括政治检查）。
- 需要投资于通信渠道，从最简单的（wiki）到更强大的（完整的社区站点），具体取决于公司致力于构建多少社区。
- 如果项目可以构建，那么支持人员需要简洁的工具来区分来自客户和竞争对手的 Franken 产品，以便他们可以正确回答真正的产品支持需求。
- 需要有简单的工具来支持贡献，并制定明确的贡献所有权政策。
一些最重要的考虑因素与软件无关。当涉及到产品和项目时，公司需要清晰明了的消息传递。我之前说过，您不能将客户与社区混淆，但这在历史上一直是产品营销团队认为社区是要鼓励进入渠道的客户，或者公司沿着“他们需要购买一些东西，因为他们正在免费获得一切”的思路思考。
要理解的第一个信息：价格无需更改。产品价值没有改变。您启用了项目社区。您没有取消对产品交付的投资。客户需要理解这种差异。您的销售团队、营销团队和产品管理团队都需要理解这个现实。欢迎客户采用软件项目并构建和运行他们自己的版本。并支持它。在他们的硬件购买中保证它（测试它）。维护它（希望不是项目极其昂贵的分支）。处理安全漏洞和补丁。所有这些。供应商没有义务支持此类内部 IT 项目。即使他们想提供昂贵的按时间和材料计费的支持，那也是不同的业务，它不能很好地扩展，并且需要周到的客户消息传递。
在消息传递部门，相反的情况同样适用。项目的贡献者同时也是产品的客户，他们需要理解这种关系。在这种情况下，公司的产品管理部门需要在项目社区中努力工作，以确保每个人都理解承诺和价值流。发挥创造力。例如，为对项目的贡献提供年度产品维护费用的补偿积分。一些客户可能总是提供更多，并且所有客户最终都会获得产品的整体价值，但贡献最多的客户会看到最直接的价值，并且可能是从一开始就最受重视的忠诚客户。共同创造价值可以改善关系及其长期可行性。修复的Timing也很重要。客户在项目社区中贡献的修复程序如果也影响了产品，则应具有明确的路径返回到产品中，无论是补丁、小版本还是主要版本。
这种同样谨慎的消息传递也需要贯彻到社区中的合作伙伴关系中。合作伙伴与客户一样，是业务关系，受合同约束，并且通常具有一些明确的价值交换。参与社区的合作伙伴需要像客户一样理解共同创新和共享价值创造的流程。当您将现有产品带入项目社区时，这可能不是一个大问题。正如客户定价不应改变一样，合作伙伴关系的条款仍然受产品本身约束。无需更改任何内容。当合作伙伴开始通过项目提供贡献时，请讨论如何考虑产品空间的变化。可能会有巨大的新机会可以共同探索。最简单地说，产品的质量不断提高。
产品和开源项目不是同一回事。从历史上看，产品是成功的开源项目生态系统的一个方面。公司也围绕严格控制的开源许可项目启动，其中一些非常成功。将产品转变为开源项目的逆向过程是可以实现的。每个人只需要理解信息即可。
评论已关闭。