开源真的很火。近几年成功的IT项目如TensorFlow、RocketMQ、TDEngine等都是开源项目，这种热度已经出了圈。随着RISC-V这种准开源芯片的出现，成为各方热议的话题。但是，如果仔细观察开源的火爆，其实背后有很多隐忧。由于开源只是一种松散开放的合作方式，这种合作方式往往能给人们带来意想不到的高价值产出。但由于目前主流的开源协议往往无法对后续的价值分配做出严格的规定，这就导致了“大厂开源羞墙”、“开发者上门要代码”等闹剧的频繁发生。但是，这些小纠纷和开源巨大的利益蛋糕相比，都是小场面。目前开源的三大战役分别是Dockers vs k8s、红帽Linux vs Cent OS、Amazon vs Elastic，其中Docker的发展轨迹最为典型，值得我们思考。
Dockers Desktop收费如饮鸩止渴，加快与k8s的分手历程
最近Docker公司更新了产品的订阅策略，最显著的变化是Docker桌面条款的修改。Docker Desktop对于小型企业、个人、教育和非商业开源项目仍然是免费的，这些项目同时满足少于250名员工和年收入少于1000万美元的需求。但是大中型企业需要付费，每个用户每月5美元起。
虽然收费条款有5个月的宽限期，但是对于不断商业化的Docker来说，Podman UI、lima等开源替代产品都是不错的选择。最尴尬的是，为什么开源领域的好学生Docker会有这么大的改变。
Docker-曾经的屠龙少年
天下武功快，牢不可破，云计算江湖也是如此，从虚拟机到容器再到无服务器。十年前，OpenStack的发布让云计算正式进入虚拟机的IaaS时代。凭借其开源和开放的特性，OpenStack大大降低了创建私有云的门槛。理论上，任何掌握OpenStack开发能力的企业都可以自行创建和提供云计算服务。
当时云计算本质上是基于虚拟机的。OpenStack可以将一些功能强大的物理服务器拆分成几个虚拟机供用户使用，但是虚拟机还是太重了。即使是动态集群，新部署虚拟机的时间也是以分钟计的。但互联网上的机会往往稍纵即逝，分钟级的等待是用户无法忍受的。所以，纤薄的虚拟机，也就是容器，开始进入大家的视野。
一般来说，容器就是基础设施疯狂版的云平台。虽然传统的基础设施技术更加安全稳定，但是从零开始修路、盖房子、装修的时间太长，集装箱本质上是最低运行环境的镜像。只要给它一些阳光，它就能野蛮生长，而且用后拆卸也很方便。是云时代应对流量冲击的神器。目前，Docker几乎已经成为集装箱的代名词。每个网民都接受过Docker提供的服务，IT人在日常工作中肯定接触过Docker。Docker作为容器技术的鼻祖，以一个幼稚的小鲸鱼形象出现，刚刚登台，就斩首了Vmware旗下的Paas平台Cloud Foundry。
2013年开始，云计算的PaaS大幕拉开。PaaS时代，云计算的最小单位从虚拟机变成了容器。最早流行的PaaS平台是Vmware创办的CloudFoundry。2012年，帕特基辛格正式接手Vmware后，开始在PaaS发力。Cloud Foundry是基辛格自己打造的拳头产品，通过应用来管理。开发者只需一个简单的命令，就可以将整个项目打包上传到Cloud foundry。在Cloud Foundry主机集群中，他们可以找到满足用户需求的起重机，通过容器化技术解压运行用户的项目包，快速对外提供服务。历史总是如此对称的美，真令人惊奇。Cloud Foundry被docker击败后，基辛格重返英特尔推出了第一款拳头产品Xeon III Ice Lake，该产品有一个专门针对Docker的附加型号——8352v。这种模式对高密度容器的调配有奇效。这段往事的读者可以参考之前的文章《溢价5倍欲将Sifive收入麾下，英特尔的绝地反击战》和《超异构时代“炼金术”，开发者表示“惊艳”》。这里就不赘述了。
除了基本的容器功能，Cloud Foundry还提供应用分发、监控、标准化灾难恢复系统等服务。Cloud Foundry将程序员从繁重的运维任务中解放出来，让开发者无需关心运行平台的资源使用情况。但是Cl
oud Foundry并没有把工作做到极致， 其打包功能一直为外界所诟病。开发者甚至要为每个应用版本应用打一个包，其带来的调试成本之高令人咋舌，甚至有人抱怨在Cloud Foundry所花费的调试时间远远高于开发一款新的应用。
Build once，Run anywhere这句响亮的口号就是Docker打败Cloud Foundry的最大秘决， Docker与Cloud Foundry相比其底层技术都是namespace和cgroups，但是Docker很好的考虑了应用打包的一致性与复用性问题，并提出了镜像这种创新式的解决方案，完全可以做到三分钟部署一个Nginx集群的效果，正是这种对程序员的友好特性，让Docker成功取代Cloud Foundry成为当之无愧的C位。
痛失标准话语权，Docker埋下隐忧
Docker成为C位后，巨头们也看到了容器方面的商机，CoreOS推出了Rocket容器，Google也推出了lmctfy容器，但是面对简洁易用的Docker，即便是开源界无往不利的Google也败下阵来，推出不久之后lmctfy容器项目就被关停，
幸福来得太快也让Docker有点飘了，在得到大笔融资之后Docker公司开始了疯狂的买买买，不过Docker之前一直是靠开源社区的力量发展壮大的，靠收购打造出的容器三件套：DockerCompose、Docker Swarm以及DockerMachine明显有点水土不服。不过这倒是影响不大，在有了容器三件套之后Docker正式把公司的名字由原来的dotCloud改名为Docker，并且将Docker注册成了商标全面开启商业化之路。
这一系列的动作基本宣告了之前的开源少年已经开始了商业化的转身，这也就意味着，未来云厂商要容器就要向Docker公司支付授权费用，这一系列的动作让容器领域的众多玩家对于Docker产生了警惕，过旧暴露的商业化意图，让云厂商们感到自身利益受到威胁，Docker没落的种子就此埋下。
2015年，Docker在同行巨大的压力下，他们牵头成立了OCI（Open Container Initiative）基金会，并将自己的容器运行时LibContainer改名为RunC捐赠给OCI，由OCI与容器各方共同制定容器和镜像的标准和规范。但是当时的Docker基本没怎么把OCI放在眼里，而且凭借自身的用户优势对于对于标准的制定也是漠不关心。现在回顾起来放弃标准制订的话语权，也是后来K8S有勇气和Docker说再见的主要原因，虽然OCI在Docker的缺位下发展缓慢，但接下来出场的CNCF（Cloud Native Computing Foundation）基金会却是个真正的狠角色，随着CNCF的出现，Kubernetes也就是K8S终于登场了。
君以此始，必以此终，Docker终失C位
K8S是Google在2014开源的一款容器编排项目，一开始K8S只算是一个Google一个人参与的独角戏，但CNCF带来的社区力量改变了这一切，由于这个时候Docker已经在商业化的道路上一去不返了，不久以后K8S社区就开始和Docker分庭抗礼了，而且逐渐有后来者居上的趋势，基于K8S的微服务等新兴技术框架迅速流行开来，最终使得以K8S为代表的容器编排平台成为了云原生时代的C位。面对CNCF的迅速发展壮大，Docker不得已将自己的Containerd捐赠给了CNCF，并且在2017年10月在Docker企业版中默认内置K8S平台。
如果说Docker打败Cloud Foundry依靠的是简洁、简单的微创新，那么K8S对于Docker就是降维打击了，Docker Swarm编排工作只是站在容器视角处理问题，而站在K8S的角度上，容器只是一个运行时的环境，Pod和Service才是K8S编排建模中所考虑的重点，只要符合标准的容器运行时都可以做为Pod进行编排，也就是说K8S对于所有容器一视同仁，用户是否用Docker根本无所谓。在取得优势身位以后，K8S果断开始了去Docker化的动作，在去年年底，CNCF官宣在K8S的1.20版本中Docker能够正常使用，但是会有警告提示，而1.22版本以后，则移除Docker的支持。这其中最大的影响那些用到Docker API的应用都将不能在K8S平台上运行了。
正如刚刚所说Docker在如日中天的时候对于运行时的标准漠不关心，这也使得很多Docker的增强功能是由Docker Shim组件提供的专属API来完成的，但是Docker Shim并不属于标准的容器运行时，这也就意味着K8S甩掉Docker时根本没有什么太大的负担，而且Docker目前在商业化道路上与CNCF社区渐行渐远，K8S目前作为云原生时代的C位，完全没必要为企业版的Docker去背书。
目前DockerDesktop企业版收费的做法并不是一个明智之举，以目前Docker的江湖地位，各种开源替代产品比比皆是，商业化的动作只会加快他们与开源社区的分手历程。不过拿了人的总是手短，接受融资就要受制于资本，Docker的历程在开源界也算典型，比如Red Hat在被IBM收购以后就停掉了免费版的Cent OS项目，如何平衡免费、开放的理念与商业化利益之间的关系，是整个IT界都需要仔细考虑的问题。
<
