看任何事情都具有两面性，开源有开源的劣势，闭源也有闭源的优势，虽然我喜欢并且提倡使用开源软件，但开源软件并不是万能的，在特定的场景下还是需要闭源来支撑。咱先说闭源。气象部门的软件开发大多采用项目制外包，承接公司一般根据需求进行定制化开发。虽然大多数项目合同要求公司提交源代码及说明文档，但有几个气象单位建立了自己的代码库和文档库呢？一个项目一个源码包，闲置在电脑的某个角落再也不碰了，升级运维呢就是谁开发谁管，满足项目要求了就不再管优化升级的事儿了。这就导致软件系统没有生命力、升级优化跟不上节奏、重复开发重复建设频繁等诸多问题的出现。当然也有些现实问题摆在面前，有些气象部门根本就没有信息系统建设部门，也缺少信息系统开发的人员来管理本单位的信息系统开发和建设，常常是派一个学气象专业的人盯着项目、和开发公司对接，只能做到需求的解释传达，很难做到本单位气象软件系统建设的长远规划和规范实施，更别说去阅读和管理开发公司的程序源码了。问题和困难都有，但并不是不可解决的，“借他山之石，逐己身之玉”。作为气象部门，寻找到一家靠谱的可长期合作的开发公司是多么的重要。气象业务系统真正的价值在于应用，在于快速响应业务变化，在于有旺盛的生命力，而这些就需要标准化、规范化、可复用、高性能的开发模式做支撑。软件的核心在于程序源码，我们可以不去开发源码，但不能不去管理源码、应用源码。靠谱的乙方合作公司加上有软件工程建设思维的气象甲方，联合打造一套只为自己气象业务应用的闭源仓库、文档仓库，于公于私都将是一件提升业务核心竞争力的事情。
上面说的闭源和接下来说的开源是相对的，因为目前没有几个软件公司做到绝对的闭源，在项目实施过程中很多通用组件、第三方插件都是采用开源软件。就像我开头说的那些开源软件，系统的日志监控、消息订阅、数据库、配置中心都将采用当前比较成熟并且先进的开源软件。源码托管在企业授权的Github上，文档要按规范生成并上传到项目管理系统，遵循严格的代码规范、安全规范、文档规范以及项目管理规范，其目的就是要创建一个可复用、可管理、可迭代升级的源码仓库，为气象业务系统的未来发展打好基础、铺好路。开源最大的好处就是技术的灵活性和可扩展性，但在性能和稳定性方面表现的比较复杂。从我的实际工作经历来看，开源技术的先进性有目共睹，但要用好开源软件的确还有很长的路要走。先进、灵活是开源的特点，可技术门槛也很高，有一些公司只是听说过该技术，缺少实施经验，因此在部署应用上就存在很大的困难。一般使用开源软件我们都是直接下载下来参照说明文档去部署，但一些特定场景下并不适用，这时候就需要开发者从源码角度去做修改了。比如大名鼎鼎的Kafka，它采用非常小众的Scala语言开发，真的遇到问题进行调试的时候你首先要先读懂Scala语言，读懂晦涩难懂的英文文档，并且能够设置好Kafka的运行环境。再回到我们气象软件的开源话题上。Github上公开了很多气象专业技术的开源软件，有可视化、三维建模、气象算法等，是我们学习和使用的绝佳选择，也让更多的气象开发者减少重复造轮子的时间，可大多都是国外开发者贡献，国内的很少。近期国家气象中心的刘凑华、代刊、韦青等研发小组也开源了预报检验库meteva，是专门支持python进行预报检验和气象行业常见的计算算法库，非常实用，但类似的开源软件还是太少了，希望越来越多的气象开发者加入开源社区，共同发展属于中国气象的开源生态圈。开源背后比拼的是应用场景的垄断、技术的垄断和人才的垄断，并且只有高速的迭代升级才能让真正的气象软件开发技术利于不败之地。
