当用开源软件来构筑产品时有4种规则来理解。一个产品团队（工程，产品管理，市场）需要去理解这些规则最好去参与一个开源项目社区和交付产品同时服务于客户。

这四个规则是开始于所有关于开源产品空间的讨论的。

规则#1：你总是给予的少，获得的多

超时的投资在一个技术上跟随的是一个正态分布。试想以一个开源项目的投资作为堆积条形图，公司和个人贡献被同时占据，并且替换一个个人公司的投资。那么在一个开源项目集合投资看起来就和作为个人投资开发封闭产权软件产品一样。个人和公司贡献来满足他们的私欲（个人需求）。这是一个完美的不对称关系，投资者放弃了一些相对少的价值，随之得到的是一些实质的回报（一个完整的可用的软件）。一个可以看到 Openstack 或者 Linux Kernel（linux 内核）行为最好的可度量的方法。而不是看着这个作为一个赠送的知识产权，它需要被看起来是获得所有的产权。

代码行数和 COCOMO 计算来自于Openhub.net 爬虫的代码仓库。我可以确切的理解代码行数有多满。我理解对于 COCOMO 精度背后的关注，但是他们是代表模型，如果不是完美的，并且他们表示出了近似的趋势。

规则2: 不要把项目和产品弄混

这一点有时很难理解。首先，我们假设我们讨论的是一个正常运行，成功的开源项目。（更多参见规则3和规则4）一个项目是一个软件集，可以安装运行，解决某个有趣的问题。它是相对较少，拥有写入权限的几个开发人员（如：代码提交者）之间通过代码进行的协作与沟通，希望有大量用户和贡献。产品是解决用户的问题并获得金钱。

项目不是产品。 尽管很多来自开源项目的优秀软件缓解了工程师的工作（见规则1），但仍然有大量的工作要做才能把它转化成产品用来解决用户的问题。Linux 内核是一个项目，Fedora 是一个发行版项目，RHEL 是一个产品，“但 Ubuntu 是什么“，你哭了？它有多种商业模型。Ubuntu 是一个发行版项目，长项目支持版本（LTS）是 Canonical 多个产品的基础。

产品通过满足用户对金钱价值的期待。它们安装于盒子之外，运行并提供保障和赔偿，服务（支持，更新，培训，咨询），文档。产品可以通过服务或硬件的方式把项目打包。产品的就像市场中用户获取金钱的需求一样具有多样性。尽管好的项目解决了前两个盒子（安装和运行），但它们不解决用户关注的其他问题。和用户想解决的问题相比，项目只解决了很窄的一些问题。

不要被开源许可和它们是否“商业友好”搞晕了。不同的提供商针对不同的许可采用不同的策略。每一个 OSI 批准的主要许可都有相关成功或失败的故事。与业务执行相比，许可证是无关的。

规则3：不要把社区和客户搞混

如果有什么难以理解，这个规则会和规则2直接交织在一起。如果规则2是关于工程师和商业模型，那么规则3就是信息和销售。社区和客户存在于不同的价值空间。社区有闲没钱。客户有钱没闲。也许一个更好的说法是：客户拿钱加速解决方案和消除风险，而社区（社区的个人开发者）没有钱。

传统意义上，工程为流水线提供产品，市场提供信息，销售通过封闭交易将有价值的人拉入，在执行上是一件很简单的事。很多公司使用开源项目并认为项目社区也是这条流水线的一部分，在社区论坛找到客户后他们更进一步这样认为。他们可能甚至认为社区项目就是购买前的一种试用。但这是错误的。

与一家公司（产品管理，工程，市场）具有的相关社区的对话和与支付客户的对话是不同的对话方式。每个对话都具有特定的工具和契约规则。成功企业（公司）理解怎样进行这些对话。他们有良好理解的构建工具和具有资格的管道（渠道)。他们有同等良好理解的工具和为开发成功社区（规则#4）的规则。每种工具链和对话有不同的矩阵来捕获和考虑。

有种交互是介于一家公司社区和客户之间的。社区成员们为项目（所以这也是公司品牌的价值的一种周到的表现形式）进行传教（原意是福音传教）。社区成员们，在再次加入产品生产渠道（管道）之前，提供支持和专业技能给那些潜在的在项目社区中能够自我胜任的顾客。

社区也提供一种为了终极的产品解决方案的惯性，通过渐渐的给予专业和时间的投资。这种挑战是保持事物清晰流畅的在社区和顾客之间分离，就好比，你可以又快又方便的认知在你面前的这个正在一边玩同时适度指导他们的人，是什么角色。一定从来没有信息（蓄意或者别的）的混乱发生过。

比如说，产品是给客户使用的。如果你有一个试用版，买之前先试用，那么“买”就在这，所以，需要跟客户沟通。如果你有一个社区版本，然后构建一个社区 (规则 #4)，否则你就只是简单的遵循开源授权协议发布一个软件，而没有从一个开源社区获取任何的好处。这是两个分开的东西，但是可以让我们了解最后一个规则。

规则4：成功的开源社区遵循简单易用的模式和实践

所有成功的开源社区项目都遵从同一种类型的模式和实践。项目开始的时候只是一些核心的开发者在沟通讨论。所以，你需要构建 3 个入口点。第一个是驱动使用和加强用户群，因为这样会促使开发者找到你的项目。 (你需要不请自来的用户！这就意味着你成功了！)软件必须容易安装和运行。用户会告诉你他们想要什么，比如，你收到一个 bug 报告和特性请求，这就是成功的例子。更重要的是，开发者找到了你。

第二，使得构建软件变成已知的，测试过的状态更容易。这允许开发者可以自己选择和实验他们的需求。假定一个聪明的开发者指出抛掉开发周期是不可以的，那么他们就不会这样做。没有人想要浪费他们的时间在你的懒散和缺乏纪律之中。他们将会陷在挫折和厌恶之中。让他们回到正常状态很难，但不是不可能的。正确处理这个问题，你会得到下一组更困难的 bug 报告和建议修正。

最后，告诉开发者怎么去做，在哪里可以贡献和怎样更方便地去做。感谢他们的贡献，如果其他事情超过了代码而感到振奋，设置这些贡献频道可以让他们能更方便。常常说“谢谢”，用尽一切方法，鼓励分支，尤其是当你是一个公司的时候。

建立社区是一项很艰难的工作。但是对自由社区却不是这样。相反，自由社区在从使用者和开发者的贡献中带来价值，同时也带来了对技术的粘着力。

这一领域的最后的实践是要理解基金会在开源软件中所扮演的角色。基金会在IP管理制度上进行组织和分类。基金会可以做很多其它的事，但如果他们不把这个中心事情做好，那么他们在社区成长潜力这个项目上是失败的。将中立的IP所有权分类有助于专门投资增长，这一专门的投资来自于有志于整个生态系统的成长的参与者和贡献者，换句话说公司致力于为用户解决问题。

基金会创造了一个中立的空间，在这空间中公司可以以平等的社会关系参与进来。一个公司从不是由他们发起也并非属于他们的开源项目（比如 SUSE 和 Linux，HP 和 Openstack 等）中做产品需要清晰的理解他们的贡献是怎样被处理的，他们并非简单地在做其他人的产品。同样地，一个公司发起一个开源项目并希望驱动围绕着这一项目的生态系统的采纳和成长，这将很好地贡献于项目的软件IP，这些IP区分非营利性质的基金会（或者在适当时创造一个）如 Google 最近和 Kubernetes 所做的项目，或者 Pivotal 和 Cloud Foundry 所做的项目。这是最终获得权利的四分之一个匝道。

总结

因此情况就是这样。我将这 20 多年来所了解到的有关对开源项目的支持，基金会的参与和产品工程总结为这四条规则，10 张 ppt 和将近 1600 个字。我期望大家能提点问题作点评价。