Matrix 首页推荐
Matrix 是少数派的写作社区,我们主张分享真实的产品体验,有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章,展示来自用户的最真实的体验和观点。
文章代表作者个人观点,少数派仅对标题和排版略作修改。
作为开源软件与自由软件的爱好者,私以为,开源最大的优势,在于能集中世界各地开发者的力量,使软硬件产品生生不息。
而这样的生命力,其实可以不仅局限于开源领域。
当下,各种软硬件产品的更新换代加速,可供企业与个人选择的新产品越来越多。然而,也有太多仍然优秀、仍然能创造价值的私有(proprietary)软硬件产品,却因开发商、开发团队停止维护乃至解散,而逐步地、被迫地沦为「废铜烂铁」,造成的损失只能由客户承担,造成的资源浪费不可估量。
这无不令人遗憾,至少我在关注相关的消息时,都免不了叹息许久。
我想,倘若那些厂商能够在「停服」与解散之际,选择将相关产品开源,让愿意继续使用的受众来维护,那么这些产品就能重获新生,客户们付出的真金白银不会永远地成为「沉没成本」。
对于个人开发者来说,开发开源软件是「用爱发电」。受限于精力与财力,有太多的软件开发者早已停止维护,即使他们的项目很优秀。不过,这并不代表绝望,因为只要他们的源代码还可以访问,其他的开发者就能下载源代码继续开发,为我所用。
同样的,有太多的免费软件(Freeware)与商业软件,依然优秀,依然能再战。但是,其厂商(在本文中用于统称开发商、开发团队及个人开发者)早已不再开发,并且他们也没有推出足以替代的产品。甚至,原有的厂商解散,彻底成为历史,原本优秀的产品就此彻底沦为「孤儿」1。
有两款优秀软件,就是因为被厂商「抛弃」,成为我心中的遗憾。

第一, EDIROL HQ Orchestral。
它是由 Roland 推出的管弦综合软音源插件,涵盖了管弦乐团的所有乐器,不到 100MB 的体积就能实现高质量的管弦音色。相比动辄数十 GB 的采样音源,EDIROL HQ Orchestral 完美兼顾了体积和音质,对硬件条件有限的制作人来说就是福音。
遗憾的是,尽管 Roland 公司依然是音乐技术界翘楚,但早在 2004 年就停止了 EDIROL HQ Orchestral 的维护,甚至连官方网站都早已不再提供下载。Roland 至今都没有推出该产品的后继者。
第二,我个人觉得最遗憾的,就是云端软件平台。
这是一款基于虚拟化技术开发的软件运行环境,可以允许你在不更改系统、保持系统干净的前提下,安装你想要的应用软件。它还配套了一个应用商店,收录了各类常用软件。在 Windows XP 与 Windows 7 的时代,我就受益于它。
然而,云端软件平台早已于 2014 年 4 月 17 日宣布停止服务,它对 Windows 的支持也定格在了 Windows 82。由于开发团队解散,无人接手维护,现在它已经彻底埋没在浩瀚的时间之河里。目前唯一的替代是 Sandboxie-Plus,但它在运行日用软件时,难以望云端软件平台之项背。3
每次回顾这两款软件时,我都在想,如果云端团队与 Roland 在放弃各自产品之际,选择将它们开源,或许它们的传奇仍能继续。
像这样的优秀业务软件,如果就放着曾经闪耀的它们掩埋于岁月的尘埃中,拙认为这就是软件业的重大损失。
上面这两款软件面向个人用户,停止开发之后,用户其实还有选择权。
但如果一款软件已经拥有了基础设施级别的地位,让使用者离不开——尤其是企业客户,那么停止开发维护后,给使用者带来的影响,远远不是「你就换个软件啊,有那么麻烦吗?」这句轻描淡写的「解决方案」可以带过。
使用者的业务、资料等关键要素,会高度依赖这些已经停止服务的基础设施。业务量和数据量在常年积累下,已经越来越离不开这些软件设施,带来极大的迁移成本。
这样的场景下,往往「牵一发而动全身」,不能擅自更改,也不能轻易迁移到其他平台。尤其是在该服务拥有诸多客户,或面向大众服务的情况下更是如此,例如银行、铁路、门户网站4等。稍微「动一下」,也许就可能导致宕机、资料损坏等危害,造成的损失有时难以估量。
迁移也不失为一个路径。但很多时候,迁移工作往往涉及到高昂的人力、物力,最终的成本还是要使用者承担。这样的成本包括但不限于:
并不是所有的企业能投入足够的资源进行迁移。对于财力、实力有限的中小企业,它们仍然可能要继续使用已经停止服务的软件,即使软件厂商可能已经成为历史。
因此,若这些已经堪比基础设施、让使用者离不开的软件,其厂商选择停止服务甚至解散,但不提供后续解决方案,且迁移成本高的,那么笔者认为,这或有影响客户利益之虞。
提示:
有些企业业务软件是由厂商量身定制,企业可以让厂商提供源代码,因此即使厂商停止服务,也可以由其他技术人员接手维护,相对而言不会让使用产品的企业过于担忧。
对于一款不开源的软件产品,若厂商执意停止开发、决定解散,不是简单一个决策就了事,而是选择开源,那么就能给自己的产品重生的机会。
将已经停止维护的软件开源,并不意味着开发团队即使解散还要承担维护义务。这个过程,是把开发的权利交给社区、交给使用者,转由使用者自己负责。
很多停服的项目在开源后,会有各路开发者自发接手完善,在原有代码库的基础上继续进行功能完善、Bug 修复等常规开发工作,推出新版本,使这些项目获得新生。即使项目过于小众,无人接手,你也可以 fork 一份源代码,自己动手编译、开发、维护。
对于面向企业的基础设施业务软件,厂商在「抛弃」之前选择开源,就可以让依赖于该项目的使用者安心:
幸运的是,一些开发团队已经认识到了开源的力量,在停止开发(或即将停止开发)之时,公开了项目源代码,由社群的力量延续软件的生机。其中一些具有远见卓识的人士,还通过成立非营利性质的基金会(例如 Mozilla 基金会),为项目的发展提供坚强后盾。


通过我的论述和举例,我想告诉「停服」软件的开发团队:其实,完全不必对开源有顾虑。
开源与否,仍是厂商自己的选择,应当得到尊重。只是,拙认为,与其把停止开发的产品源码放在自家的仓库里「吃灰」,造成无谓的浪费,让团队长年的努力付诸东流,白白地埋没于尘土之中,不如以社区和技术达人之力,给你的产品带来更多可能。
开源,或许是更好的归宿。
相关服务停止支持的风险,对于硬件的持有者来说或许会造成更大的冲击。
使用者花了真金白银购买的各类硬件设备,小到智能硬件,大到工厂机器,也面临着因厂商停止支持甚至解散而带来的风险。这是因为,相当多的设备,必须要与软件配套使用;而智能硬件甚至常常离不开厂商搭建的互联网服务。
倘若这些配套软件停止支持,恐怕使用者手上的硬件,即便工况再棒,也只能沦为「电子垃圾」——还是被迫的。
普通消费者可能会买到那些完全依赖 app 控制的智能硬件,简单举几个品类的设备:
恕我直言,使用这样的智能硬件是有风险的。当厂商仍正常提供服务时,你感觉不到风险的存在,觉得仍然可以放心购买。然而,假设某一天:
若厂商没有推出解决方案,也没有选择开源,那么,恐怕你的设备就要被迫沦为「完好的破铜烂铁」。你只能眼睁睁地看着这些设备成为「板砖」,即使它们仍能正常工作,本来还不该成为「电子垃圾」。
退一步讲,即使基本功能仍然能使用,但由于缺少 app 与配套服务,其使用价值也大打折扣。最终,受影响的还是消费者的利益。
对于停止服务的硬件,消费者可以「用脚投票」选择替代产品。
然而,如果产品替代的成本过高,甚至是一对一量身定制而没有任何替代品的呢?在这样的情况下,恐怕厂商不能轻易地选择停止服务了,否则造成的后果将难以用金钱衡量。
我们熟悉的一个例子就是智能汽车。
智能汽车的核心特色就是联网的智能控制功能,比如智能驾驶、使用手机 app 作为车钥匙、远程控制车辆等,以及使用车机上的各种便捷功能。更有甚者,车上空调这样的基本功能都给车机「接管」了。可以说,车辆几乎是「跑在软件上」。
传统燃油车时代,汽车的控制以机械部件、行车电脑等为主,即使是行车电脑这样偏智能化的部件,也无需依赖厂商的在线服务。然而,智能汽车在交付之后,其后续服务就全然离不开厂商的支持了,尤其是依赖互联网的智能服务。这就意味着,若厂家选择破产,手机 app 将无法使用,车机也将变砖,形象地说,就是「智能变智障」。
威马汽车就是这么一个典型案例,厂商一度宣布申请破产后,车机除导航外其余功能无法使用,手机 app 无法连接服务器,曾经意气风发的智能汽车沦为「普通的四轮电动汽车」。10而其他那些处在经营危机中的厂商,正在无形中把消费者置于困境的阴影中。
另一个例子是一些老式的、电脑控制的生产设备。
仍然有不计其数的 2000 年代,甚至 90 年代的设备于工厂里服役。硬件上,它们工况良好,老当益壮;软件上,由于诞生年代「久远」,用 MS-DOS、Windows 95 等古董系统跑配套软件是常态。经营者们出于节约成本、充分利用资源等考虑,不会轻易更换生产设备。
然而,一旦制造商停止老设备的支持,甚至直接破产,导致设备配套的软件就会失去维护。由于开发年代较早,这些软件无法在新平台上运行。随着能运行这些旧软件的计算机平台存量逐渐减少,且本无质保,一旦计算机发生故障,软件无法迁移到新平台,自然会影响工厂的生产经营。
这就意味着,一旦软件「趴窝」,即使设备的硬件质量过硬,经过精心保养仍然像新设备一样工况良好,也不得不沦为「电子垃圾」。哪怕是被迫更换,于工厂、于环境而言无疑都是巨大的浪费。
更何况,如果设备是为工厂独家定制,几乎找不到替代品,那制造商「停服」、软件「罢工」给工厂带来的损失可是会翻倍的。
答案是可以的,只是要具体问题具体分析。
考量开源是否可以拯救「被迫」变砖的硬件,需要综合考虑硬件产品的用途、开发过程、生命周期等因素,往往不同品类、不同领域的硬件,这些因素千差万别。因此,不能以要求软件开源的标准去要求所有硬件厂商做到开源,而是要量体裁衣。
关乎使用者健康与福祉的产品,离不开厂商的持续服务跟进,才能真正实现设备诞生的初衷,造福于人。这一类产品,包括「赛博格」11、大型医疗器械等。
对于这样的产品,或许可以给厂商赋予一定的「开源义务」。当厂商存在无法提供技术支持的风险,甚至已经出现破产等情形,使技术支持成为空头支票,那么相关机构就可以要求这些厂商开源相关技术,包括配套软件。
需要注意的是,这类关乎福祉的产品,往往凝结着科研工作者的劳动力,以及海量的投资。为了保护厂商的利益,使厂商免于顾虑,「开源义务」需要有前提,包括但不限于:
对于上文提到的智能汽车、工厂设备等大宗、高技术含量的设备,消费者与企业客户要想更换它们,势必要付出巨大的成本,同时造成各种不必要的资源浪费——把本来可以完好使用的硬件变成「废铜烂铁」。
因此,拙认为,也可以类推适用上一节「关乎使用者福祉的产品」中的策略,引入「开源义务」,让使用者基于释出的配套软件源代码继续维护,以保证设备的使用价值。对客户来说,这是为客户的利益负责,客户当年购车购设备付出的价值不能付诸东流。
另一方面,这也是在践行绿色发展理念,让本能继续发挥价值的大宗产品继续为我们所用,何尝不是为环境负责、为资源负责。
面向普通消费者的产品,可替代的选择更为丰富,且替代成本远没有那么高昂。比如,A 厂商的智能温度计停服了,就可以选择 B 厂商的产品;C 厂商的智能后备电源配套小程序下架了,还可以换成传统的、带有通信功能的 UPS……
由于是消费产品,对于厂商的「开源义务」不必像前两类产品那么苛刻,更多还是以倡导为主。倡导非强制,本身却是不容小觑的力量。无论是消费者,还是厂商的工作人员,或许自己也不愿意看到付出真金白银买的产品,因为停服而吃灰,在家里占地方,还难以出二手12。
倘若设备配套软件开源,技术爱好者们就可以发掘设备的新用途,让设备重获新生。这何尝不是给设备第二次生命。
不妨大胆设想一下,若厂商在停服之际选择开源配套软件,可以带来哪些改变。
或许厂商会对开源有顾虑,担心这会加重负担,或者影响其利益。
对此,我想再次强调,将已经停止维护的配套软件开源,并不意味着开发团队即使解散还要承担维护义务。选择开源,是把开发和维护的责任交给社区、交给使用者,转由使用者自己负责。厂商自己只需要为仍在服务期内的产品提供技术支持即可。
厂商也有可能会担心配套软件涉及到专利和商业秘密等因素,不愿意开源。对于适应新平台等场景,其实厂商本身也不需要顾虑。用户关心的是让软件能够正常控制硬件,比如让旧的工控软件能正常在 Windows 11、Linux 6.12 等新平台下运行。配套软件更多是对硬件进行操作,相当于调用硬件的 API,而凝结专利与商业秘密的硬件本体仍然是对用户不可见的黑盒,在此情景下,开源未尝不可。14
即使选择破产,还没有其他厂商接手技术,厂商也仍不选择开源(或用其他方式公开技术),宁愿带着自己的配套软件远走高飞,把源代码锁在自己的仓库里永不见天日。这个选择,真的好吗?
——恐怕不见得。
每年不知有多少各行各业的软件,因为开发团队的放弃而沦为「孤儿」。原本它们还有更多发展空间,却因开发团队不选择开源,而只能永远定格在最后一个版本,丧失了前进的机会。
对于硬件,尤其是工厂机器等大宗硬件,更是会因厂商的停止服务而沦为「废铜烂铁」「电子垃圾」。由于厂商乃至破产也不选择开源配套软件,即使这些硬件还有良好的工况、卓越的的性能、可观的价值,都只有变为「垃圾」的宿命——还是被迫的。
笔者作为深受开源文化影响的开发者,写下这篇文章,就是想倡导各路开发者和厂商,将开源作为一种延续产品价值的方式。毕竟,那些软硬件,本来还可以继续为我们的生活创造价值,何必要让它们早早终止?不如选择开源,吸引有识之士前来接续开发,实现资源的充分利用,那么这些产品就能告诉大家,新生的力量有多蓬勃、伟大。
(题图来源:豆包 AI 生成)
> 关注 少数派公众号,解锁全新阅读体验 📰
> 实用、好用的 正版软件,少数派为你呈现 🚀
© 本文著作权归作者所有,并授权少数派独家使用,未经少数派许可,不得转载使用。