今天小編分享的科技經驗：經歷了那麼多「意難平」的停更軟體、硬體，我為什麼選擇相信開源，歡迎閱讀。
編注：我們會不定期挑選 Matrix 的優質文章，展示來自用戶的最真實的體驗和觀點。 文章代表作者個人觀點，少數派僅對标題和排版略作修改。
作為開源軟體與自由軟體的愛好者，私以為，開源最大的優勢，在于能集中世界各地開發者的力量，使軟硬體產品生生不息。
而這樣的生命力，其實可以不僅局限于開源領網域。
當下，各種軟硬體產品的更新換代加速，可供企業與個人選擇的新產品越來越多。然而，也有太多仍然優秀、仍然能創造價值的私有（proprietary）軟硬體產品，卻因開發商、開發團隊停止維護乃至解散，而逐步地、被迫地淪為「廢銅爛鐵」，造成的損失只能由客戶承擔，造成的資源浪費不可估量。
這無不令人遺憾，至少我在關注相關的消息時，都免不了嘆息許久。
我想，倘若那些廠商能夠在「停服」與解散之際，選擇将相關產品開源，讓願意繼續使用的閱聽人來維護，那麼這些產品就能重獲新生，客戶們付出的真金白銀不會永遠地成為「沉沒成本」。
▍若停止維護的軟體能開源：或許是更好的選擇
對于個人開發者來說，開發開源軟體是「用愛發電」。受限于精力與财力，有太多的軟體開發者早已停止維護，即使他們的項目很優秀。不過，這并不代表絕望，因為只要他們的源代碼還可以訪問，其他的開發者就能下載源代碼繼續開發，為我所用。
同樣的，有太多的免費軟體（Freeware）與商業軟體，依然優秀，依然能再戰。但是，其廠商（在本文中用于統稱開發商、開發團隊及個人開發者）早已不再開發，并且他們也沒有推出足以替代的產品。甚至，原有的廠商解散，徹底成為歷史，原本優秀的產品就此徹底淪為「孤兒」。
那些讓我遺憾的優秀軟體
有兩款優秀軟體，就是因為被廠商「抛棄」，成為我心中的遺憾。
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 8。由于開發團隊解散，無人接手維護，現在它已經徹底埋沒在浩瀚的時間之河裡。目前唯一的替代是 Sandboxie-Plus，但它在運行日用軟體時，難以望雲端軟體平台之項背。
每次回顧這兩款軟體時，我都在想，如果雲端團隊與 Roland 在放棄各自產品之際，選擇将它們開源，或許它們的傳奇仍能繼續。
像這樣的優秀業務軟體，如果就放着曾經閃耀的它們掩埋于歲月的塵埃中，拙認為這就是軟體業的重大損失。
有些場合，可不是簡簡單單停止服務那麼簡單
上面這兩款軟體面向個人用戶，停止開發之後，用戶其實還有選擇權。
但如果一款軟體已經擁有了基礎設施級别的地位，讓使用者離不開——尤其是企業客戶，那麼停止開發維護後，給使用者帶來的影響，遠遠不是「你就換個軟體啊，有那麼麻煩嗎？」這句輕描淡寫的「解決方案」可以帶過。
使用者的業務、資料等關鍵要素，會高度依賴這些已經停止服務的基礎設施。業務量和數據量在常年積累下，已經越來越離不開這些軟體設施，帶來極大的遷移成本。
這樣的場景下，往往「牽一發而動全身」，不能擅自更改，也不能輕易遷移到其他平台。尤其是在該服務擁有諸多客戶，或面向大眾服務的情況下更是如此，例如銀行、鐵路、門戶網站等。稍微「動一下」，也許就可能導致宕機、資料損壞等危害，造成的損失有時難以估量。
遷移也不失為一個路徑。但很多時候，遷移工作往往涉及到高昂的人力、物力，最終的成本還是要使用者承擔。這樣的成本包括但不限于：
轉換數據的成本：将數以百千萬的業務數據從老平台遷移到新平台，其成本可想而知。
如果目标平台提供了自動化工具，尚且還可以幫助企業緩解一些壓力；但如果企業自身使用的專有軟體與舊平台高度綁定，那麼企業就不得不付出額外的成本。
重新編寫業務邏輯：例如，有的企業使用 Visual FoxPro 開發數據庫。若要遷移，可能要将海量數據遷移到 SQL Server、MySQL 等平台，還要專門為新的數據庫平台重新編寫業務邏輯。
重寫軟體：例如，有些業務軟體至今仍使用 Visual Basic 6.0（VB6）開發，且仍在使用中。開源而強大的一款照片處理工具 PhotoDemon，就是用 VB6 編寫。
然而，VB6 是一門與運行環境高度綁定的編程語言，可不是簡單的業務軟體。如果要用其他編程語言重新開發，那就要徹底推倒重寫，需要耗費的成本可想而知。
人員的培訓：遷移到新平台，意味着工作人員要掌握與此前截然不同的業務技術，企業還需要花費額外精力來組織培訓，使工作人員适應。
并不是所有的企業能投入足夠的資源進行遷移。對于财力、實力有限的中小企業，它們仍然可能要繼續使用已經停止服務的軟體，即使軟體廠商可能已經成為歷史。
因此，若這些已經堪比基礎設施、讓使用者離不開的軟體，其廠商選擇停止服務甚至解散，但不提供後續解決方案，且遷移成本高的，那麼筆者認為，這或有影響客戶利益之虞。
提示：
有些企業業務軟體是由廠商量身定制，企業可以讓廠商提供源代碼，因此即使廠商停止服務，也可以由其他技術人員接手維護，相對而言不會讓使用產品的企業過于擔憂。
開源如何起到拯救的作用
對于一款不開源的軟體產品，若廠商執意停止開發、決定解散，不是簡單一個決策就了事，而是選擇開源，那麼就能給自己的產品重生的機會。
将已經停止維護的軟體開源，并不意味着開發團隊即使解散還要承擔維護義務。這個過程，是把開發的權利交給社區、交給使用者，轉由使用者自己負責。
很多停服的項目在開源後，會有各路開發者自發接手完善，在原有代碼庫的基礎上繼續進行功能完善、Bug 修復等常規開發工作，推出新版本，使這些項目獲得新生。即使項目過于小眾，無人接手，你也可以 fork 一份源代碼，自己動手編譯、開發、維護。
對于面向企業的基礎設施業務軟體，廠商在「抛棄」之前選擇開源，就可以讓依賴于該項目的使用者安心：
擁有技術團隊的使用者可以自行維護、定制相關軟體，滿足自己需求，或持續開發并将修改反饋給社區；
而技術實力不足以修改軟體的那些使用者，則依然可以受益于開源，因為他們不再受制于廠商支持缺位的無助感——源代碼在手，你有更多尋求技術支持的可能性。
那些讓我欣喜的優秀軟體
幸運的是，一些開發團隊已經認識到了開源的力量，在停止開發（或即将停止開發）之時，公開了項目源代碼，由社群的力量延續軟體的生機。其中一些具有遠見卓識的人士，還通過成立非營利性質的基金會（例如 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，至今仍在持續開發中。
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 無法連接伺服器，曾經意氣風發的智能汽車淪為「普通的四輪電動汽車」。而其他那些處在經營危機中的廠商，正在無形中把消費者置于困境的陰影中。
例子之二：老式生產設備
另一個例子是一些老式的、電腦控制的生產設備。
仍然有不計其數的 2000 年代，甚至 90 年代的設備于工廠裡服役。硬體上，它們工況良好，老當益壯；軟體上，由于誕生年代「久遠」，用 MS-DOS、Windows 95 等古董系統跑配套軟體是常态。經營者們出于節約成本、充分利用資源等考慮，不會輕易更換生產設備。
然而，一旦制造商停止老設備的支持，甚至直接破產，導致設備配套的軟體就會失去維護。由于開發年代較早，這些軟體無法在新平台上運行。随着能運行這些舊軟體的計算機平台存量逐漸減少，且本無質保，一旦計算機發生故障，軟體無法遷移到新平台，自然會影響工廠的生產經營。
這就意味着，一旦軟體「趴窩」，即使設備的硬體質量過硬，經過精心保養仍然像新設備一樣工況良好，也不得不淪為「電子垃圾」。哪怕是被迫更換，于工廠、于環境而言無疑都是巨大的浪費。
更何況，如果設備是為工廠獨家定制，幾乎找不到替代品，那制造商「停服」、軟體「罷工」給工廠帶來的損失可是會翻倍的。
那麼，開源是否能夠解決上面的困局？
答案是可以的，只是要具體問題具體分析。
考量開源是否可以拯救「被迫」變磚的硬體，需要綜合考慮硬體產品的用途、開發過程、生命周期等因素，往往不同品類、不同領網域的硬體，這些因素千差萬别。因此，不能以要求軟體開源的标準去要求所有硬體廠商做到開源，而是要量體裁衣。
第一類：關乎使用者福祉的產品
關乎使用者健康與福祉的產品，離不開廠商的持續服務跟進，才能真正實現設備誕生的初衷，造福于人。這一類產品，包括「賽博格」、大型醫療器械等。
對于這樣的產品，或許可以給廠商賦予一定的「開源義務」。當廠商存在無法提供技術支持的風險，甚至已經出現破產等情形，使技術支持成為空頭支票，那麼相關機構就可以要求這些廠商開源相關技術，包括配套軟體。
需要注意的是，這類關乎福祉的產品，往往凝結着科研工作者的勞動力，以及海量的投資。為了保護廠商的利益，使廠商免于顧慮，「開源義務」需要有前提，包括但不限于：
廠商出現無法繼續提供技術支持的風險，例如經營不善、财務危機；
廠商未能推出更新換代的產品，且現有產品仍有可觀用戶；
沒有其他廠商接手維護、繼續提供支持。
第二類：智能汽車、工廠機器等大宗設備
對于上文提到的智能汽車、工廠設備等大宗、高技術含量的設備，消費者與企業客戶要想更換它們，勢必要付出巨大的成本，同時造成各種不必要的資源浪費——把本來可以完好使用的硬體變成「廢銅爛鐵」。
因此，拙認為，也可以類推适用上一節「關乎使用者福祉的產品」中的策略，引入「開源義務」，讓使用者基于釋出的配套軟體源代碼繼續維護，以保證設備的使用價值。對客戶來說，這是為客戶的利益負責，客戶當年購車購設備付出的價值不能付諸東流。
另一方面，這也是在踐行綠色發展理念，讓本能繼續發揮價值的大宗產品繼續為我們所用，何嘗不是為環境負責、為資源負責。
第三類：消費產品
面向普通消費者的產品，可替代的選擇更為豐富，且替代成本遠沒有那麼高昂。比如，A 廠商的智能溫度計停服了，就可以選擇 B 廠商的產品；C 廠商的智能備份電源配套小程式下架了，還可以換成傳統的、帶有通信功能的 UPS ……
由于是消費產品，對于廠商的「開源義務」不必像前兩類產品那麼苛刻，更多還是以倡導為主。倡導非強制，本身卻是不容小觑的力量。無論是消費者，還是廠商的工作人員，或許自己也不願意看到付出真金白銀買的產品，因為停服而吃灰，在家裡占地方，還難以出二手。
倘若設備配套軟體開源，技術愛好者們就可以發掘設備的新用途，讓設備重獲新生。這何嘗不是給設備第二次生命。
要是有如果……
不妨大膽設想一下，若廠商在停服之際選擇開源配套軟體，可以帶來哪些改變。
智能汽車廠商：若廠商在經營難以為繼之餘，選擇将車機服務開源，那麼具有技術能力的車主就能自己部署相關服務，延續自家車輛的服務。一些有擔當的車友也可以組建面向車友的開源社區（open-source community），以類似于 Mastodon 等分布式平台的方式，為車主提供由社群支持的服務。
研發工廠機器的廠商：若廠商在停止服務或破產之餘，公開其設備配套軟體的源代碼，那麼有技術能力的客戶就可以進一步開發。例如，研讀源代碼，了解 1995 年代舊平台工控軟體的操作原理，并将軟體移植到 Windows 11 LTSC 平台上，從而延續設備的使用。又或者修復原有工控軟體的 bug、進一步優化性能，更好發揮硬體的功效。
智能硬體研發廠商：若廠商在放棄舊有產品線或破產之際，同樣選擇開源配套軟體，那麼用戶就可以有機會繼續使用現有產品。依賴互聯網的硬體，可由用戶自行部署服務端，借助内網穿透等技術延續設備生命；設備底層驅動和固件開源，則可由用戶自行開發或适配新固件，發掘出各種玩法；等等。
一個可參考的例子是 HTC HD2，雖然并不是廠家主動釋出底層驅動源碼，但正是得益于這些底層代碼，才讓這款手機得以适配 Android 2.3～9.0、MeeGo、Ubuntu 甚至 iOS 等多個版本的系統，成為一代傳奇機皇。
廠商或許會有顧慮，但顧慮是可以化解的
或許廠商會對開源有顧慮，擔心這會加重負擔，或者影響其利益。
對此，我想再次強調，将已經停止維護的配套軟體開源，并不意味着開發團隊即使解散還要承擔維護義務。選擇開源，是把開發和維護的責任交給社區、交給使用者，轉由使用者自己負責。廠商自己只需要為仍在服務期内的產品提供技術支持即可。
廠商也有可能會擔心配套軟體涉及到專利和商業秘密等因素，不願意開源。對于适應新平台等場景，其實廠商本身也不需要顧慮。用戶關心的是讓軟體能夠正常控制硬體，比如讓舊的工控軟體能正常在 Windows 11、Linux 6.12 等新平台下運行。配套軟體更多是對硬體進行操作，相當于調用硬體的 API，而凝結專利與商業秘密的硬體本體仍然是對用戶不可見的黑盒，在此情景下，開源未嘗不可。
即使選擇破產，還沒有其他廠商接手技術，廠商也仍不選擇開源（或用其他方式公開技術），寧願帶着自己的配套軟體遠走高飛，把源代碼鎖在自己的倉庫裡永不見天日。這個選擇，真的好嗎？
——恐怕不見得。
▍寫在最後
每年不知有多少各行各業的軟體，因為開發團隊的放棄而淪為「孤兒」。原本它們還有更多發展空間，卻因開發團隊不選擇開源，而只能永遠定格在最後一個版本，喪失了前進的機會。
對于硬體，尤其是工廠機器等大宗硬體，更是會因廠商的停止服務而淪為「廢銅爛鐵」「電子垃圾」。由于廠商乃至破產也不選擇開源配套軟體，即使這些硬體還有良好的工況、卓越的的性能、可觀的價值，都只有變為「垃圾」的宿命——還是被迫的。
筆者作為深受開源文化影響的開發者，寫下這篇文章，就是想倡導各路開發者和廠商，将開源作為一種延續產品價值的方式。畢竟，那些軟硬體，本來還可以繼續為我們的生活創造價值，何必要讓它們早早終止？不如選擇開源，吸引有識之士前來接續開發，實現資源的充分利用，那麼這些產品就能告訴大家，新生的力量有多蓬勃、偉大。
