Question

在对开源商业模型进行分类之前，我们应该先研究一下闭源有什么好处，闭源真正想保护的是什么？

假如你雇人给你的企业写了一个专业的财会软件，选择闭源不会比开源好到哪里，如果你希望闭源，唯一合理的原因是你想把这个软件卖给别人，或者防止竞争者使用它。

答案很明显，你在保护销售价值，但 95%的软件写出来是供内部使用的，在没有销售价值可言的情形下，从闭源中还能得到什么好处？

需要稍微分析一下的是第二种情况（保护竞争优势），假设你把这个财会软件开源了，它变得很受欢迎，在社区的帮助下它也变得更好了。你的竞争对手也开始使用它，竞争对手没有支付开发成本却获得好处，而且还影响到你的业务，这是不是一个反对开源的理由？

也许是，也许不是。真正应该考虑的问题是：你从分散开发负担中获取的益处是否超过了因（“搭便车”行为导致的）竞争加剧而带来的损失，一些人往往在这个权衡中失算：(a) 忽略了社区开发带来的功能改进。(b) 不把已经支出的开发成本当做沉没成本。根据假设，不管怎样，你都是要付出开发成本的，所以把它归入开放源码（如果你这样认为）的成本是不对的。

另一个经常被提及的担心是，将某些特别的财会功能开源，会不会导致商业机密方案的泄露？其实这不关开源闭源的事，这是糟糕设计带来的问题。财会软件如果编写得当，商业知识是不会在代码中体现的，它应该由一个模型（schema）或描述语言表达，然后由财会引擎执行实现（作为很相近的一个例子，考虑数据模型将业务知识和数据库引擎相分离的做法），这种功能上的分离使你不但可以保护住王冠上的宝石（即你的商业模型），还能从开放引擎中获得最大收益。

还有其他一些理由可以说明闭源完全是不明智的。你也许被一些谬论误导，觉得闭源能使你的商业系统更安全地防范骇客入侵，如果是这样，我建议你立刻和密码工作者做一次彻底的交谈。比起用闭源来保障安全性，真正专业而审慎的人知道什么才是更好的做法，他们已经从惨痛教训中学到太多了。安全性是可靠性的一部分，只有在算法及其实现经过彻底的同行评审之后，才有可能被认为是安全的。