小A在学期间是一名优秀的软件开发专业的学生，精通编程，在校期间就开发了几款著名的软件。毕业后服务于一家软件公司。一次在客户现场服务时，客户向小A抱怨，当前企业用的一款开源软件缺少了一些企业级功能，满足不了当前业务的需求，由于是开源软件，企业没有与开发者签署雇佣和合作的关系，开发者也受制于时间的原因无法很好的满足客户的需求，客户很头疼，要是有人能帮助实现就好了。小A一听，觉得这是个机会，于是向客户毛遂自荐：“要不让我来实现你所需的功能，你支付我费用吧？”，客户一听，立马拍腿称好，钱不是问题！
小A接下了这笔生意，他是怎么做的呢？
首先客户使用的是开源软件，所以小A很容易的就获取到了其源代码，并且在此基础上实现了客户的需求，根据开源协议，小A实现的代码也要开源，除此之外小A是个开源的忠实信徒，他除了开源自己编写的代码，他还一直秉承“上游优先”的原则，将开发好的代码推送给上游的开源软件。
经过小A的连夜工作，客户满意的拿到了符合需求的软件，小A拿到了客户支付的佣金，同时开源软件合并了小A提交实现新功能的代码，实现了快速迭代，发布数个新的版本，开源软件用户也享受到了你的成果。
这是一个多赢的结果：
- 客户的需求得到满足
- 你的努力有了回报
- 开源软件得到了发展
- 使用开源软件用户享受到了开源软件发展成果
随着小A不断的将实现的代码开源并发送给上游，慢慢的小A积累了名气，使用上游开源软件的一些企业客户找到小A，希望能帮助他们实现需求。小A觉得是时候创业了。
小A开始了创业之路，成立了小A软件公司，专门服务于企业客户，满足客户对开源软件的需求，和提供对应的解决方案。企业客户使用的开源软件众多，小A的业务也不断的扩展，针对不同的产品线去雇佣了对应的开发人员、测试人员和实施人员。
小A的公司经过多年的发展在开源界很有名气，在很多开源软件的贡献量都是数一数二的，小A的公司就像一个桥梁，连接了开源软件和企业客户，可以这样说小A公司的存在是具有价值的，这个价值不仅仅是公司盈利的价值。
随着小A公司的发展，已然成为了业界标杆，小B也是开源的爱好者，因为小A的代码都是开源的，基于开源协议，小B拿到了小A公司开发的软件源代码，保留了署名，但是把软件界面中的小A公司名称替换成了小B出品，熟悉软件打包的同学想必知道了，整套流程非常简单，源代码名称替换，流线水构建，所以小B一个人就打包出了小A公司经过数百个开发者编写的软件，并且小A公司每次发布新的代码，小B都能自动的拉取替换构建，立马就能打包好并发布名称为小Ｂ出品的软件。
小Ｂ凭借着宣传中的“一比一兼容”，“企业级”、“社区”、“开源”，“免费”等字眼立马吸引了新加入开源软件用户。但是基于“一比一兼容”或称为 “Bug 级兼容”的“特性”会不会为上游社区带来新功能呢？
小B打包的软件因为“免费”（毕竟仅仅是打包，不增加和修改软件功能，要是修改了，那就不是1:1兼容了，成本摆在这里）给小A公司带来了影响，很多新客户选择了小B出品的软件。
小A公司面临了困境，承当了开发的成本（公司运营，开发人员薪水），推动了开源软件的发展，但得不到应有的报酬。
看到这里很多同学会有疑问：“开源软件不都免费的吗？”
开源软件可以比喻成一个爱好，例如我喜欢游泳，我可以教朋友游泳不收费，但仅限我有空且乐意的时候，如果比让我在上班的时候出来教你游泳，且要教会各种泳姿，抱歉得付钱，那这就不是爱好了，这是游泳教练的工作。开源作者也是一样的，如果仅凭借代码开源的属性就来提需求让作者无条件去实现，那是相当不可思议的。
小A因为承当不起成本在深夜做了一个决定，解散公司。小A公司解散带来的影响有哪些？
可以根据前面多赢的结果得出：
- 客户的需求无法满足
- 开源软件没有了小A公司的贡献
- 小B出品也没有了可以1:1兼容的对象
当然地球少了小A公司还会转。客户的需求存在，就会冒出第二个小A公司，但是在这一套规则下，小B也可以瞄准第二个小A公司进行1:1 兼容。我想结局可能也是一样吧。
故事到了这里，这是一个多输的局面，小A、小B、包括软件使用的用户其实都没有错，但有没有更好的解决方法？我不知道。
故事还有第二个结局，小A深夜反思，是不是自己的问题，小A公司虽然公开了源代码，但是没有公开制作方法，才导致这种事情发生，如果公开了制作流程，大家都可以学习并生产出自己特色的软件不是更好吗？
于是小A公开了制作软件的配方，就跟厨师做菜一样，原先你只是知道我用的哪些原料，但是你不知道加工的工艺，和添加的调味品，现在当场操作给你看。
小C公司原先做的事情与小B是一致的，但看到小A公布了配方，于是决定不再1:1兼容，而是基于小A的配方再去做调整，加入自己的味道，最终拿加入新元素的产品与小A公司的产品直接竞争。
小A也知道公布配方会造就竞争对手，但对于开源社区有多种不同的可能，不也是有益于开源社区，不是吗？
这个故事还在继续，结局不知道。