Matrix 首页推荐 

Matrix 是少数派的写作社区,我们主张分享真实的产品体验,有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章,展示来自用户的最真实的体验和观点。 

文章代表作者个人观点,少数派仅对标题和排版略作修改。


作为开源软件与自由软件的爱好者,私以为,开源最大的优势,在于能集中世界各地开发者的力量,使软硬件产品生生不息。

而这样的生命力,其实可以不仅局限于开源领域。

当下,各种软硬件产品的更新换代加速,可供企业与个人选择的新产品越来越多。然而,也有太多仍然优秀、仍然能创造价值的私有(proprietary)软硬件产品,却因开发商、开发团队停止维护乃至解散,而逐步地、被迫地沦为「废铜烂铁」,造成的损失只能由客户承担,造成的资源浪费不可估量。

这无不令人遗憾,至少我在关注相关的消息时,都免不了叹息许久。

我想,倘若那些厂商能够在「停服」与解散之际,选择将相关产品开源,让愿意继续使用的受众来维护,那么这些产品就能重获新生,客户们付出的真金白银不会永远地成为「沉没成本」。

若停止维护的软件能开源:或许是更好的选择

对于个人开发者来说,开发开源软件是「用爱发电」。受限于精力与财力,有太多的软件开发者早已停止维护,即使他们的项目很优秀。不过,这并不代表绝望,因为只要他们的源代码还可以访问,其他的开发者就能下载源代码继续开发,为我所用。

同样的,有太多的免费软件(Freeware)与商业软件,依然优秀,依然能再战。但是,其厂商(在本文中用于统称开发商、开发团队及个人开发者)早已不再开发,并且他们也没有推出足以替代的产品。甚至,原有的厂商解散,彻底成为历史,原本优秀的产品就此彻底沦为「孤儿」1

那些让我遗憾的优秀软件

有两款优秀软件,就是因为被厂商「抛弃」,成为我心中的遗憾。

EDIROL Orchestral,功能强大而小巧的管弦音源,已停止支持近20年。

第一, 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等。稍微「动一下」,也许就可能导致宕机、资料损坏等危害,造成的损失有时难以估量。

迁移也不失为一个路径。但很多时候,迁移工作往往涉及到高昂的人力、物力,最终的成本还是要使用者承担。这样的成本包括但不限于:

  • 转换数据的成本
    将数以百千万的业务数据从老平台迁移到新平台,其成本可想而知。
    如果目标平台提供了自动化工具,尚且还可以帮助企业缓解一些压力;但如果企业自身使用的专有软件与旧平台高度绑定,那么企业就不得不付出额外的成本。
  • 重新编写业务逻辑
    例如,有的企业使用 Visual FoxPro5 开发数据库。若要迁移,可能要将海量数据迁移到 SQL Server、MySQL 等平台,还要专门为新的数据库平台重新编写业务逻辑6
  • 重写软件
    例如,有些业务软件至今仍使用 Visual Basic 6.0(VB6)开发,且仍在使用中。开源而强大的一款照片处理工具 PhotoDemon,就是用 VB6 编写。
    然而,VB6 是一门与运行环境高度绑定的编程语言7,可不是简单的业务软件。如果要用其他编程语言重新开发,那就要彻底推倒重写,需要耗费的成本可想而知。
  • 人员的培训
    迁移到新平台,意味着工作人员要掌握与此前截然不同的业务技术,企业还需要花费额外精力来组织培训,使工作人员适应。

并不是所有的企业能投入足够的资源进行迁移。对于财力、实力有限的中小企业,它们仍然可能要继续使用已经停止服务的软件,即使软件厂商可能已经成为历史。

因此,若这些已经堪比基础设施、让使用者离不开的软件,其厂商选择停止服务甚至解散,但不提供后续解决方案,且迁移成本高的,那么笔者认为,这或有影响客户利益之虞。

提示:
有些企业业务软件是由厂商量身定制,企业可以让厂商提供源代码,因此即使厂商停止服务,也可以由其他技术人员接手维护,相对而言不会让使用产品的企业过于担忧。

开源如何起到拯救的作用

对于一款不开源的软件产品,若厂商执意停止开发、决定解散,不是简单一个决策就了事,而是选择开源,那么就能给自己的产品重生的机会。

将已经停止维护的软件开源,并不意味着开发团队即使解散还要承担维护义务。这个过程,是把开发的权利交给社区、交给使用者,转由使用者自己负责。

很多停服的项目在开源后,会有各路开发者自发接手完善,在原有代码库的基础上继续进行功能完善、Bug 修复等常规开发工作,推出新版本,使这些项目获得新生。即使项目过于小众,无人接手,你也可以 fork 一份源代码,自己动手编译、开发、维护。

对于面向企业的基础设施业务软件,厂商在「抛弃」之前选择开源,就可以让依赖于该项目的使用者安心:

  • 拥有技术团队的使用者可以自行维护、定制相关软件,满足自己需求,或持续开发并将修改反馈给社区;
  • 而技术实力不足以修改软件的那些使用者,则依然可以受益于开源,因为他们不再受制于厂商支持缺位的无助感——源代码在手,你有更多寻求技术支持的可能性8

那些让我欣喜的优秀软件

幸运的是,一些开发团队已经认识到了开源的力量,在停止开发(或即将停止开发)之时,公开了项目源代码,由社群的力量延续软件的生机。其中一些具有远见卓识的人士,还通过成立非营利性质的基金会(例如 Mozilla 基金会),为项目的发展提供坚强后盾。

Firefox 就是在网景浏览器源代码的基础之上开发的,可谓给网景浏览器带来新生。(图片来源:Mozilla)
  • 最成功的例子或许就是网景浏览器(Netscape Navigator)。
    在上世纪 90 年代,网景浏览器拥有翘楚地位,具备卓越的特性和大量的用户,但一度陷入与微软 IE 的「浏览器大战」,不敌 IE 的垄断地位。在危机之际(1998 年 2 月),网景公司公开了浏览器的源代码,成立了 Mozilla 社群与基金会。
    Mozilla 在网景浏览器源码库的基础上,开发了后继者 Firefox 浏览器,是主流的浏览器之一。即使后来网景公司被 AOL 收购,网景浏览器开发停滞,Firefox 也依然延续着网景的血脉,直至今日。
  • 其次是 Sandboxie。
    Sandboxie 是一款沙盒工具,通过虚拟化技术,将应用程序与真实系统环境隔离起来,这样就可以放心地在沙盒中运行风险软件,不必担心系统受到损害。它是一款商业软件,最早由 Ronen Tzur 开发于2004年,最终被 Sophos 收购。
    2019 年,Sophos 宣布停止 Sandboxie 的开发,将其转为自由软件(Free Software,采用 GPL 许可),并关闭官方网站。随后,Xanasoft 的开发者 David Xanatos 接手开发,在原有代码库的基础上持续演进,并推出了升级版本 Sandboxie-Plus,至今仍在持续开发中9
Blender 的前身是专有软件。其前身停止开发后,就是因为转为开源,得以重获新生。(图片来源:MediaWiki)
  • 另外,还有知名的 3D 建模软件 Blender。
    Blender 最早由 NeoGeo 公司开发,免费但不开源。该公司于 1998 年解散,随后由 Ton Roosendaal 创办的 NaN 公司接手开发,并转为共享软件,结果 NaN 公司于 2002 年破产,开发工作停滞。
    好在,明智的 Ton Roosendaal 选择将 Blender 开源,牵头创办 Blender 基金会,以社区方式延续开发工作,这才使得 Blender 持续进步,成为首屈一指的开源免费建模软件,其强大程度足以与商业竞品(如 3D Max、Maya)一决高下。

通过我的论述和举例,我想告诉「停服」软件的开发团队:其实,完全不必对开源有顾虑。

开源与否,仍是厂商自己的选择,应当得到尊重。只是,拙认为,与其把停止开发的产品源码放在自家的仓库里「吃灰」,造成无谓的浪费,让团队长年的努力付诸东流,白白地埋没于尘土之中,不如以社区和技术达人之力,给你的产品带来更多可能。

开源,或许是更好的归宿。

对于硬件:开源其配套软件,或许是保护使用者利益的必由之路

相关服务停止支持的风险,对于硬件的持有者来说或许会造成更大的冲击。

使用者花了真金白银购买的各类硬件设备,小到智能硬件,大到工厂机器,也面临着因厂商停止支持甚至解散而带来的风险。这是因为,相当多的设备,必须要与软件配套使用;而智能硬件甚至常常离不开厂商搭建的互联网服务。

倘若这些配套软件停止支持,恐怕使用者手上的硬件,即便工况再棒,也只能沦为「电子垃圾」——还是被迫的

潜藏在消费智能硬件中的「风险」

普通消费者可能会买到那些完全依赖 app 控制的智能硬件,简单举几个品类的设备:

  • 智能温湿度计
    屏幕上显示气温、湿度、时间,连接 app 则可以统计气温走势、自定义表盘布局等。
  • 可映射按键的计算机键盘、MIDI 键盘等输入设备
    必须使用专用的应用程序来配置。
  • 便携打印机
    支持使用蓝牙或 WiFi 推送文件打印。但它不能直接 USB 连接电脑,而是必须使用手机 app 激活,然后通过 app 操控打印机联网打印。打印的文件可能需要经由厂商的服务器转换。
  • 智能后备电源
    支持远程控制,且内置屏幕可以显示工作状态。但用户若想要调节后备电压输出、空闲时休眠、熄屏时间等参数,则需要使用配套的微信小程序,还须登录微信账号绑定设备才能配置。
  • 小品牌的智能手机云台
    自身不提供控制面板,需要使用配套的 app 来操作,包括运动参数、拍摄等功能。
  • 智能乐器、智能音响
    面板上只有简单的控制器,调节最基本的音量等参数。而效果器、均衡器等高级特性则有赖于专门的手机 app,甚至还必须先绑定账号并与设备配对。

恕我直言,使用这样的智能硬件是有风险的。当厂商仍正常提供服务时,你感觉不到风险的存在,觉得仍然可以放心购买。然而,假设某一天:

  • 厂商停止了对老产品的技术支持,不再维护 app 与微信小程序,现有 app 不再兼容新版系统;
  • 厂商直接下架了 app 或微信小程序;
  • 厂商直接停止了配套的互联网服务,或者升级配套服务却不再兼容老产品。

若厂商没有推出解决方案,也没有选择开源,那么,恐怕你的设备就要被迫沦为「完好的破铜烂铁」。你只能眼睁睁地看着这些设备成为「板砖」,即使它们仍能正常工作,本来还不该成为「电子垃圾」。

退一步讲,即使基本功能仍然能使用,但由于缺少 app 与配套服务,其使用价值也大打折扣。最终,受影响的还是消费者的利益。

大宗商品或生产资料:停服不开源,后患无穷

对于停止服务的硬件,消费者可以「用脚投票」选择替代产品。

然而,如果产品替代的成本过高,甚至是一对一量身定制而没有任何替代品的呢?在这样的情况下,恐怕厂商不能轻易地选择停止服务了,否则造成的后果将难以用金钱衡量。

例子之一:智能汽车

我们熟悉的一个例子就是智能汽车。

智能汽车的核心特色就是联网的智能控制功能,比如智能驾驶、使用手机 app 作为车钥匙、远程控制车辆等,以及使用车机上的各种便捷功能。更有甚者,车上空调这样的基本功能都给车机「接管」了。可以说,车辆几乎是「跑在软件上」。

传统燃油车时代,汽车的控制以机械部件、行车电脑等为主,即使是行车电脑这样偏智能化的部件,也无需依赖厂商的在线服务。然而,智能汽车在交付之后,其后续服务就全然离不开厂商的支持了,尤其是依赖互联网的智能服务。这就意味着,若厂家选择破产,手机 app 将无法使用,车机也将变砖,形象地说,就是「智能变智障」

威马汽车就是这么一个典型案例,厂商一度宣布申请破产后,车机除导航外其余功能无法使用,手机 app 无法连接服务器,曾经意气风发的智能汽车沦为「普通的四轮电动汽车」。10而其他那些处在经营危机中的厂商,正在无形中把消费者置于困境的阴影中。

例子之二:老式生产设备

另一个例子是一些老式的、电脑控制的生产设备。

仍然有不计其数的 2000 年代,甚至 90 年代的设备于工厂里服役。硬件上,它们工况良好,老当益壮;软件上,由于诞生年代「久远」,用 MS-DOS、Windows 95 等古董系统跑配套软件是常态。经营者们出于节约成本、充分利用资源等考虑,不会轻易更换生产设备。

然而,一旦制造商停止老设备的支持,甚至直接破产,导致设备配套的软件就会失去维护。由于开发年代较早,这些软件无法在新平台上运行。随着能运行这些旧软件的计算机平台存量逐渐减少,且本无质保,一旦计算机发生故障,软件无法迁移到新平台,自然会影响工厂的生产经营。

这就意味着,一旦软件「趴窝」,即使设备的硬件质量过硬,经过精心保养仍然像新设备一样工况良好,也不得不沦为「电子垃圾」。哪怕是被迫更换,于工厂、于环境而言无疑都是巨大的浪费。

更何况,如果设备是为工厂独家定制,几乎找不到替代品,那制造商「停服」、软件「罢工」给工厂带来的损失可是会翻倍的。

那么,开源是否能够解决上面的困局?

答案是可以的,只是要具体问题具体分析。

考量开源是否可以拯救「被迫」变砖的硬件,需要综合考虑硬件产品的用途、开发过程、生命周期等因素,往往不同品类、不同领域的硬件,这些因素千差万别。因此,不能以要求软件开源的标准去要求所有硬件厂商做到开源,而是要量体裁衣

第一类:关乎使用者福祉的产品

关乎使用者健康与福祉的产品,离不开厂商的持续服务跟进,才能真正实现设备诞生的初衷,造福于人。这一类产品,包括「赛博格」11、大型医疗器械等。

对于这样的产品,或许可以给厂商赋予一定的「开源义务」。当厂商存在无法提供技术支持的风险,甚至已经出现破产等情形,使技术支持成为空头支票,那么相关机构就可以要求这些厂商开源相关技术,包括配套软件。

需要注意的是,这类关乎福祉的产品,往往凝结着科研工作者的劳动力,以及海量的投资。为了保护厂商的利益,使厂商免于顾虑,「开源义务」需要有前提,包括但不限于:

  • 厂商出现无法继续提供技术支持的风险,例如经营不善、财务危机;
  • 厂商未能推出更新换代的产品且现有产品仍有可观用户
  • 没有其他厂商接手维护、继续提供支持

第二类:智能汽车、工厂机器等大宗设备

对于上文提到的智能汽车、工厂设备等大宗、高技术含量的设备,消费者与企业客户要想更换它们,势必要付出巨大的成本,同时造成各种不必要的资源浪费——把本来可以完好使用的硬件变成「废铜烂铁」。

因此,拙认为,也可以类推适用上一节「关乎使用者福祉的产品」中的策略,引入「开源义务」,让使用者基于释出的配套软件源代码继续维护,以保证设备的使用价值。对客户来说,这是为客户的利益负责,客户当年购车购设备付出的价值不能付诸东流。

另一方面,这也是在践行绿色发展理念,让本能继续发挥价值的大宗产品继续为我们所用,何尝不是为环境负责、为资源负责。

第三类:消费产品

面向普通消费者的产品,可替代的选择更为丰富,且替代成本远没有那么高昂。比如,A 厂商的智能温度计停服了,就可以选择 B 厂商的产品;C 厂商的智能后备电源配套小程序下架了,还可以换成传统的、带有通信功能的 UPS……

由于是消费产品,对于厂商的「开源义务」不必像前两类产品那么苛刻,更多还是以倡导为主。倡导非强制,本身却是不容小觑的力量。无论是消费者,还是厂商的工作人员,或许自己也不愿意看到付出真金白银买的产品,因为停服而吃灰,在家里占地方,还难以出二手12

倘若设备配套软件开源,技术爱好者们就可以发掘设备的新用途,让设备重获新生。这何尝不是给设备第二次生命。

要是有如果……

不妨大胆设想一下,若厂商在停服之际选择开源配套软件,可以带来哪些改变。

  • 智能汽车厂商
    若厂商在经营难以为继之余,选择将车机服务开源,那么具有技术能力的车主就能自己部署相关服务,延续自家车辆的服务。
    一些有担当的车友也可以组建面向车友的开源社区(open-source community),以类似于 Mastodon 等分布式平台的方式,为车主提供由社群支持的服务。
  • 研发工厂机器的厂商
    若厂商在停止服务或破产之余,公开其设备配套软件的源代码,那么有技术能力的客户就可以进一步开发。
    例如,研读源代码,了解 1995 年代旧平台工控软件的操作原理,并将软件移植到 Windows 11 LTSC 平台上,从而延续设备的使用。又或者修复原有工控软件的 bug、进一步优化性能,更好发挥硬件的功效。
  • 智能硬件研发厂商
    若厂商在放弃旧有产品线或破产之际,同样选择开源配套软件,那么用户就可以有机会继续使用现有产品。
    依赖互联网的硬件,可由用户自行部署服务端,借助内网穿透等技术延续设备生命;设备底层驱动和固件开源,则可由用户自行开发或适配新固件,发掘出各种玩法;等等。
    一个可参考的例子是 HTC HD2,虽然并不是厂家主动释出底层驱动源码13,但正是得益于这些底层代码,才让这款手机得以适配 Android 2.3~9.0、MeeGo、Ubuntu 甚至 iOS 等多个版本的系统,成为一代传奇机皇。

厂商或许会有顾虑,但顾虑是可以化解的

或许厂商会对开源有顾虑,担心这会加重负担,或者影响其利益。

对此,我想再次强调,将已经停止维护的配套软件开源,并不意味着开发团队即使解散还要承担维护义务。选择开源,是把开发和维护的责任交给社区、交给使用者,转由使用者自己负责。厂商自己只需要为仍在服务期内的产品提供技术支持即可。

厂商也有可能会担心配套软件涉及到专利和商业秘密等因素,不愿意开源。对于适应新平台等场景,其实厂商本身也不需要顾虑。用户关心的是让软件能够正常控制硬件,比如让旧的工控软件能正常在 Windows 11、Linux 6.12 等新平台下运行。配套软件更多是对硬件进行操作,相当于调用硬件的 API,而凝结专利与商业秘密的硬件本体仍然是对用户不可见的黑盒,在此情景下,开源未尝不可。14

即使选择破产,还没有其他厂商接手技术,厂商也仍不选择开源(或用其他方式公开技术),宁愿带着自己的配套软件远走高飞,把源代码锁在自己的仓库里永不见天日。这个选择,真的好吗?

——恐怕不见得。

写在最后

每年不知有多少各行各业的软件,因为开发团队的放弃而沦为「孤儿」。原本它们还有更多发展空间,却因开发团队不选择开源,而只能永远定格在最后一个版本,丧失了前进的机会。

对于硬件,尤其是工厂机器等大宗硬件,更是会因厂商的停止服务而沦为「废铜烂铁」「电子垃圾」。由于厂商乃至破产也不选择开源配套软件,即使这些硬件还有良好的工况、卓越的的性能、可观的价值,都只有变为「垃圾」的宿命——还是被迫的。

笔者作为深受开源文化影响的开发者,写下这篇文章,就是想倡导各路开发者和厂商,将开源作为一种延续产品价值的方式。毕竟,那些软硬件,本来还可以继续为我们的生活创造价值,何必要让它们早早终止?不如选择开源,吸引有识之士前来接续开发,实现资源的充分利用,那么这些产品就能告诉大家,新生的力量有多蓬勃、伟大。

(题图来源:豆包 AI 生成)

> 关注 少数派公众号,解锁全新阅读体验 📰

> 实用、好用的 正版软件,少数派为你呈现 🚀