魏永明:都打着开源协作的名义要共建,却又是山头林立搞内卷

简介: 魏永明:都打着开源协作的名义要共建,却又是山头林立搞内卷
魏永明,清华大学工学学士、硕士,飞漫软件创始人,开源软件杰出贡献人物。1999年发布知 名开源软件 MiniGUI并持续研发至今。出版有《Minicul 剖析》、《Linux 设备驱动程序》(二、三版)等技术著作。2018年11月,发起合壁操作系统开源协作项目。 2020 年8月,领街撰写国内第一部码农体长篇小说《考鼎记》并在线发表。2020年8月,提出并开发全新编程语言HVML。

本文首发自魏永明公众号:考鼎录,以下为文章全文

在《少谈情怀少作秀,多写代码多创新》一文中,鄙人对神化开源的现象做出了批判。今天这篇文章批判神化开源协作的现象。

有人说“开源协作”是一种创新,我很不认同这个看法。

开源协作充其量只能算是个合作模式上的创新,但“充其量”这个词,我都不太愿意用。因为强调模式创新,会带来很多负面作用。就如同前几年的互联网热点,比如共享单车之类的,都是模式创新的产物,但这些模式创新对社会的发展到底是好是坏,目前还没有定论,还有待观察。

另外,很多人听了“开源协作是一种创新”这句话之后的第一反应,是“开源协作能够促进技术上的创新”。但我要强调的是,开源协作并不能促进技术上的创新。

我的观点,用通俗易懂的话来说:开源协作适合守成,而不适合开拓。

接下来跟大家解释一下。

首先,我不是要否定开源协作以及促进开源协作的组织,比如各种开源基金会、开源社区的存在,他们有其存在的价值。

开源协作,就是基于某个开源软件的协作开发机制,本质上和已经存在多年的技术联盟、标准协会一样,是特定圈子里的人讨论一些事情的一个模式而已。要有效地开展开源协作,目前主要使用两种平台。一种就是建立在互联网各种工具之上的虚拟交流平台,比如邮件列表、技术论坛等,可称之为开源社区等。另外一种就是开源软件基金会。

和技术联盟、标准组织类似,开源协作平台,不管是虚拟社区形式还是开源基金会形式,本质上在一项技术进入推广期和成熟期的时候才有存在的价值。这些平台存在的价值,就是一些代表不同利益的人借助这个平台来平衡利益关系,比如两项差不多的技术点,大家争斗一番,哪个该成为标准。换成开源软件,那就是哪个模块或者哪个协议可以放到开源软件当中。

假如我们去分析目前对整个计算机产业起着举足轻重作用的开源软件,你会发现一个规律:这些开源软件往往都是某个商业软件的开源复制品。这些开源软件,要么是个人或者组织开发然后由基金会管理,要么是开源协作组织开发的针对一些已有商业软件的开源替代品。 如 Linux 内核,是商业版 Unix 内核的替代,GNU 的各种工具软件也是商用 Unix 系统的替代,LibreOffice 是 Microsoft Office 的替代,FireFox 是对 Internet Explorer 的替代等等。只有极少数开源软件,尤其是由某个商业公司牵头开发的软件,才算得上是原创性多一些的软件,其中的代表如 Android,以及一些基于双许可证的自由软件,知名的如 MiniGUI、MySQL、MongoDB 等。(如果细究,Android、MySQL 等其实也是商业软件的开源替代品。)这一部分开源软件,很少提及开源协作。比如 Google 之于 Android,Google 要对 Android 有绝对的控制力,而基于双许可证模式的自由软件,则需要保证著作权权属的清晰和独占。可以说,绝大部分开源软件,尤其是开源协作的产物,和技术创新或进步几乎没有太大的关系。而只要是具有原创性的软件,不管是否开源,一定和一两个关键人物或团队有关(如 Linux 内核之 Linus、Rust 语言之 Mozilla 基金会、TypeScript 语言之微软、HVML 语言之魏永明等),可以这么说,开源协作并不是这些原创性工作的原始驱动力。

当然,如 Linux 内核这样应用广泛的开源软件,在几十年的发展过程中,也有诸多创新之处,但总体上只能算作是局部的修修补补,而无法产生根本性的变革。就拿操作系统来讲,带来根本性变化的当属 FushiaOS 和 HybridOS 这类。但一开始,开源协作往往跟它们无缘——对于一项创新的技术,一开始,大部分人的态度只是观望。

总之,是别人先有了创新然后才有了开源的替代,或者先有创新的东西并开源,然后才谈得上开源协作。开源协作对技术创新的主要贡献,是可以加速技术创新的应用。不过这是另外一个话题,我们以后再谈。

至于其中的原因也很简单:创新是一种成本高昂的经济活动,需要长时间的积累和投入;而只有利益才能成为创新的第一驱动力。那种纯粹基于奉献精神的开源理念不足以支撑人们做长期而专注的投入。于是,懒惰的人们只需要复制他人的思想和创意,写几行代码开源出来,然后指望通过互联网放大自己的名誉,进而获得他想要的回报。甚而至于,拿已有的开源软件,换个名字就可以变成自己的。

具体到我们国家,这个问题更严重。

中国人讲求实用主义。 没有几个企业眼光长远,可以为创新做长期的投入。如果大家看不到一项技术的未来,就不可能组建一个平台来搞协作。这是人性。因此,协作只能建立在原创技术得到部分认同的情况之下,在推广期和维护期利用协作平台来发展。另外,参与这类协作平台的主体主要是企业,而企业的首要目的是赚钱。没有钱景就投入,绝大多数中国企业是不会这么做的。就算参与,大部分情况也是做个姿态而已。你看,这么多年我们国家有很多技术联盟,最后不是分崩离析,就是吃吃喝喝,没有太多实质上的产出。

另外,当前我们国家只有一个开源基金会,也就是开放原子开源基金会。华为、阿里、腾讯等,都是这个基金会的发起单位,大家都往这个基金会捐赠各种开源项目。比如操作系统,就有 OpenHarmony、openEular、AnolisOS 等等。其中 openEular 和 AnolisOS 本来就是竞争关系,现在都捐赠给了开放原子基金会。大家想想,基金会有没有能力同时发展这么多操作系统是一回事,单就这两个有竞争关系的操作系统来讲,基金会如何平衡背后金主的利益? 我们看这些捐赠给基金会的操作系统,归根结底还是在已有开源软件技术上攒出来的系统,一开始就没有多少技术上的创新,放到同一个内卷平台上,能产生创新?

而作为像基金会这样的非盈利性组织,极容易成为一个内卷平台或者一个官僚机构。拿全世界最火的 Linux 基金会来讲,这两年募集到了大量的资金,但同时也出现了很多奇奇怪怪的项目。比如 SPDX 规范,全名叫“软件包数据交换规范”,我了解了一下,大概就是规范大家的开源许可证声明和使用的。像这类的项目,在我看来就是吃饱了饭撑着的——给基金会养的一大帮官僚找点事儿做而已。

你看,在没有多少创新基因的开源软件之上,指望通过内卷、平庸、官僚的开源协作平台来搞创新?岂不是有点痴人说梦。

因此,我的观点是,开源协作,并不能促进技术上的创新。技术上的创新,来自于艰苦卓绝的努力,对产品和技术的深刻洞察以及长期持续的投入。将技术创新寄托于开源协作,是错误的。

你,该醒醒了!

PS:此文发表前的最新消息:又一个类似 openEular、AnolisOS 的 OS 叫 OpenCloudOS 的,发布了。嘿嘿……

本文内容为作者授权转载,不代表平台观点。

相关文章
|
网络协议 安全
libev与多线程
libev与多线程
libev与多线程
|
XML Java 数据库连接
idea 从mapper方法直接点进xml文件的解决方法
idea 从mapper方法直接点进xml文件的解决方法
1398 2
|
数据处理 开发者 Python
浅析Python中的异步编程:从asyncio到Tornado
Python的异步编程是提升应用性能的关键。本文从Python的异步编程概念入手,探讨了asyncio库的使用及其在实际开发中的应用,并分析了Tornado框架的异步模型,以及如何将异步思维运用于实际项目中。
|
IDE 数据可视化 TensorFlow
Anaconda和Python是什么关系?
Anaconda和Python是什么关系?
392 8
|
机器学习/深度学习 Python
利用Python实现一个简单的机器学习模型:线性回归详解
利用Python实现一个简单的机器学习模型:线性回归详解
503 2
|
消息中间件 存储 负载均衡
Java多线程基础-9:代码案例之阻塞队列(一)
阻塞队列是一种遵循先进先出原则的线程安全数据结构,它在队列满时会阻塞入队操作,队列空时会阻塞出队操作,常用于多线程间的协作,简化同步代码编写。Java中提供了`BlockingQueue`接口及其实现类,如`ArrayBlockingQueue`和`LinkedBlockingQueue`,用于实现生产者-消费者模型,以实现负载均衡和资源的有效利用,如削峰填谷,降低系统压力。
305 0
|
前端开发
使用CSS实现网格+渐变背景色的Web页面背景
使用CSS实现网格+渐变背景色的Web页面背景
260 0
|
编解码 安全 算法
【蓝牙系列】蓝牙5.4到底更新了什么(1)--- PAwR
蓝牙5.4规范中引入了一种新的逻辑传输“Periodic Advertising with Responses(PAwR)”,它能够支持无连接的双向应用程序数据通信。在这种技术支持下,ESL设备不需要经常性的切换接收模式,因此可以大大延长电池寿命,同时,基于PAwR的数据传输模式,保证数据传输与监听设备的相关性,从而减少能量的浪费,实现ESL设备接收数据并响应至发送器的能力。
1632 0
|
NoSQL 数据可视化 Linux
MongoDB学习笔记(一) 安装配置
MongoDB学习笔记(一) 安装配置
1214 0
|
存储 芯片