引言
我们在谈到开源与闭源的时候，通常指的是一个软件本身，其源代码是否开放，但是在特定的软件中（如数据分析类软件），还有另一个问题，就是其是否采用开源的语言来编写应用。
这就带来多种情况，开源软件开源语言，闭源软件闭源语言，等等。
我们举其中两个最典型的例子来对比，那就是开源软件开源语言：Python，以及闭源软件闭源语言SAS。
SASPythonR对比[1]为什么大型金融机构用SAS居多？而互联网公司更倾向于Python？
1. 历史遗留问题
Python虽然早在年就诞生了，但是真正流行起来，并且用于商业应用的生产环境，也就是在近5年时间。
在此之前，金融机构的历史代码，特别是大型金融机构，很多还是用SAS写成的。
为什么不要把老的SAS代码用Python重构呢？
经验老道的开发会告诉你，如果你的代码跑得很好，千万不要重构它。
2. 人才梯队问题
会SAS语言的人才比Python少得多，因为SAS相对来说，应用场景只在数据分析领域（因此也要求具备一定的数学、统计学基础），而Python的应用场景则更广，也没有对于数学等基础学科知识的要求。
下图虽然有些历史了（年发布的文章），但是鉴于美国的整体行业技术栈相较国内也领先几年，并且在同一时间维度横向比较各行业的偏好也是可以作为参考的：
不同行业对于SASRPython的选择倾向[2]
也就是说，极速扩张中的互联网公司不太可能把自己限制在这么小的人才范围上。
3. 稳定性与精度要求问题
从应用场景上看，金融机构一般用于风控过程中的信用评估，或者投资决策、量化模型等，一旦出错，会造成直接且数额相当的损失；
互联网机构，由于牌照的原因，绝大多数应用场景在于智能推荐以及产品运营，而这些是锦上添花的，出现错误并没有那么致命。
因此，对于运行稳定性和计算精度的要求，金融机构会高很多。
Python底层代码包还有很多问题，比如pandas，目前还有3k+openissues：
运气不好碰上一个，只能等开源社区响应了，这肯定比不上商业机构的7X24小时支持。
如果是报错或者导致了很明显的问题，其实倒还好，易于发现，马上修复排查即可。最可怕的，是哪种最终数值上差了一点点，但是完全看不出错误的问题，甚至，开源的包里，不能排除被植入恶意代码的可能。
虽然遇上未解决的bug或者被植入恶意代码的概率很小，但是金融机构天生就是风险厌恶的，容错率很低，通常会选择更加安全的方案。
4. 信用背书问题
商业化运营的公司，信用背书总是强于开源社区的，而强监管的金融行业，尤其需要信用背书。
拿上面提到的稳定性与精度要求问题来说，如果真的出现了此类问题，造成了损失，甚至引起了监管的注意，那么，用开源软件的机构，只能自己承担责任。
5.成本问题
听起来使用SAS的好处更多，可以保证运行的稳定性以及结果的精度，同时还可以提供信用背书，当然，这些都是有成本的，最后就体现在SAS的价格上。
License按年续费，每年的维保还需要单独采购，这是一块不小的成本，并且，一旦采购，就会形成历史代码，就会产生持续的续费，中小金融机构很难下决心，而互联网公司，更希望用这些钱去烧一些用户量和月活回来，获取更多的融资。
Python的成本更多是隐形的，比如线上出了问题造成的潜在损失等等，不过，随着研发队伍的不断成长，这个概率会越来越低。
难道没有折中方案吗？
1. 金融机构自身的折中方案
为了解决以上问题，金融机构通常会在建模过程用Python，生产环境转写为SAS，同时利用一些脚本和工具，将Python脚本转成SAS语言。这样，既可以用得上会Python的人，解决人才梯度的问题，又可以解决稳定性和精度要求以及信用背书的问题。
不过，这个方案依然没有解决较高成本投入问题，SAS的license和维保每年要买，甚至，还要养两套人马，懂Python的自不用说，还需要少量懂SAS的人来维护这套Python转SAS的工具，毕竟，任何一边升级了都可能导致脚本出错，转换环节越多，出错概率越大。
2. SAS的折中方案
SASViya已经开始支持开源语言了，可以更好地解决人才梯队问题。
找不到会SAS的人？没关系，会Python也行，同时还可以由SAS提供环境的稳定性，以及完善的售后运营机制提供支持。
但同样，作为一款数据分析工具，SAS的使用成本较高问题依然存在。
3. 最关键的成本问题和历史遗留问题如何解决？
生产上用SAS确实可以确保稳定性和精度，以及提供信用背书，并且，基于以上两个方案，人才梯队问题也可缓解。
那么，较高的成本问题和上面所提到的历史遗留问题如何解决呢？如果有一个成本比较合适的商业化软件，可以支持SAS代码，是否就可以解决历史遗留问题。
还真有，笔者最近使用了一款叫作WPS（此WPS非彼WPS）的软件可以支持SAS语言，也支持开源语言Python。
这其实就可以解决历史遗留问题，假设某家机构，有很多历史代码是用SAS写的，但是由于某些原因，不想续费了（可能是因为真的很贵），但是又不想把这些历史代码用Python重构（毕竟风险真的很高，万一出岔子谁来承担责任），那就可以用WPS来管理历史代码，万一需要微调，也可以直接在上面实现，风险可控。
WPS最近被另一家软件公司Altair收购了，这个公司应该也是看到了这个场景的价值，既能保证使用SAS语言构建的历史模型平稳运行，又可以更高效地帮助公司向开源+闭源混合语言体系结构过渡，且能以更低的成本，保留和利用闭源软件+闭源语言的最大优势。
参考资料[1]
r-vs-python-vs-sas:
