在標準建立之前，軟體所存在的問題

開源專案需要認真對待交付成果中所包含的標準

無論以何種標準來衡量，開源軟體作為傳統的專有軟體的替代品而崛起，取得了不錯的效果。 如今，僅 Github 中就有著數以千萬計的程式碼倉庫，其中重要專案的數量也在快速增長。在本文撰寫的時候，Apache 軟體基金會 開展了超過 300 個專案， Linux 基金會 支援的專案也超過了 60 個。與此同時，OpenStack 基金會 在 180 多個國家擁有超過 60,000 名成員。

這樣說來，這種情景下有什麼問題麼？

開源軟體在面對使用者的眾多需求時，由於缺少足夠的意識，而無法獨自去解決全部需求。 更糟糕的是，許多開源軟體社群的成員（業務主管以及開發者）對利用最合適的工具解決這一問題並不感興趣。

讓我們開始找出那些有待解決的問題，看看這些問題在過去是如何被處理的。

問題存在於：通常許多專案都在試圖解決一個大問題當中重複的一小部分，而客戶希望能夠在競爭產品之間做出選擇，不滿意的話還能夠輕鬆選擇其他產品。但是現在看來都是不可能的，在這個問題被解決之前它將會阻礙開源軟體的使用。

這已經不是一個新的問題或者沒有傳統解決方案的問題了。在一個半世紀以來，使用者期望有更多的選擇和自由來變換廠商，而這一直是通過標準的制定來實現的。在現實當中，你可以對螺絲釘、燈泡、輪胎、延長線的廠商做出無數多的選擇，甚至於對獨特形狀的紅酒杯也可以專注選擇。因為標準為這裡的每一件物品都提供了物理規格。而在健康和安全領域，我們的幸福也依賴於成千上萬的標準，這些標準是由私營行業制定的，以確保在最大化的競爭中能夠有完美的結果。

隨著資訊與通訊技術（ICT）的發展，以同樣類似的方式形成了一些重要的組織機構，例如：國際電信聯盟（ITU）、國際電工委員會（IEC），以及電氣與電子工程師學會標準協會（IEEE-SA）。近千家財團遵循 ICT 標準來進行開發、推廣以及測試。

雖然並非是所有的 ICT 標準都形成了無縫對接，但如今在我們生活的科技世界裡，成千上萬的基本標準履行著這一承諾，這些標準包含了計算機、移動裝置、Wi-Fi 路由器以及其他一切依賴電力來執行的東西。

關鍵的一點，在很長的一段時間裡，由於客戶對擁有種類豐富的產品、避免受制於供應商，並且享受全球範圍內的服務的渴望，逐漸演變出了這一體系。

現在讓我們來看看開源軟體是如何演進的。

好訊息是偉大的軟體已經被創造出來了。壞訊息是對於像雲端計算和虛擬化網路這樣的關鍵領域，沒有任何單獨的基金會在開發整個堆疊。取而代之的是，單個專案開發單獨的一層或者多層，依靠需要時才建立的善意的合作，這些專案最終堆疊成棧。當這一過程執行良好時，結果是好的，但也有可能形成與傳統的專有產品同樣的鎖定。相反，當這一過程執行不良時，壞的結果就是它會浪費開發商、社群成員的時間和努力，同時也會辜負客戶的期望。

最明確的解決方法的建立標準，允許客戶避免被鎖定，鼓勵多個解決方案通過對附加服務和功能進行有益的競爭。當然也存在著例外，但這不是開源世界正在發生的情況。

這背後的主要原因在於，開源社群的主流觀點是：標準意味著限制、落後和多餘。對於一個完整的堆疊中的單獨一層來說，可能就是這樣。但客戶想要選擇的自由、激烈的競爭，這就導致回到了之前的壞結果上，儘管多個廠商提供相似的整合堆疊，但卻被鎖定在一個技術上。

在 Yaron Haviv 於 2017 年 6 月 14 日所寫的 “除非我們協作，否則我們將被困在專有云上” 一文中，就有對這一問題有著很好的描述。

在今天的開源生態系統當中存在一個問題，跨專案整合並不普遍。開源專案能夠進行大型合作，構建出分層的模組化的架構，比如說 Linux — 已經一次又一次的證明了它的成功。但是與 Linux 的意識形成鮮明對比的就是如今許多開源社群的日常狀態。

舉個例子：大資料生態系統，就是依賴眾多共享元件或通用 API 和層的堆疊來實現的。這一過程同樣缺少標準的線路協議，同時，每個處理框架（看看 Spark、Presto 和 Flink）都擁有獨立的資料來源 API。

這種合作的缺乏正在造成擔憂。缺少了合作，專案就會變得不通用，結果對客戶產生了負面影響。因為每個人都不得不從頭開始，重新開發，這基本上就鎖定了客戶，減緩了專案的發展。

Haviv 提出了兩種解決方法：

• 專案之間更緊密的合作，聯合多個專案消除重疊的部分，使堆疊內的整合更加密切；
• 開發 API ，使切換更加容易。

這兩種方法都能達到目的。但除非事情能有所改變，我們將只會看到第一種方法，這就是前邊展望中發現的技術鎖定。結果會發現工業界，無論是過去 WinTel 的世界，或者縱觀蘋果的歷史，相互競爭的產品都是以犧牲選擇來換取緊密整合的。

同樣的事情似乎很有可能發生在新的開源界，如果開源專案繼續忽視對標準的需求，那麼競爭會存在於層內，甚至是堆疊間。如果現在能夠做到的話，這樣的問題可能就不會發生了。

因為如果口惠無實開發軟體優先、標準在後的話，對於標準的制定就沒有真正的興趣。主要原因是，大多數的商人和開發者對標準知之甚少。不幸的是，我們能夠理解這些使事情變得糟糕的原因。這些原因有幾個：

• 大學幾乎很少對標準進行培訓；
• 過去擁有專業的標準人員的公司遣散了這些部門，現在的部署工程師接受標準組織的培訓又遠遠不夠；
• 在建立僱主標準工作方面的專業知識方面幾乎沒有職業價值；
• 參與標準活動的工程師可能需要以他們認為是最佳技術解決方案為代價來延長僱主的戰略利益；
• 在許多公司內部，專業的標準人員與開源開發者之間鮮有交流；
• 許多軟體工程師將標準視為與 FOSS 定義的“四大自由”有著直接衝突。

現在，讓我們來看看在開源界正在發生什麼:

• 今天大多數的軟體工程師鮮有不知道開源的；
• 工程師們每天都在享受著開源工具所帶來的便利；
• 許多令人激動的最前沿的工作正是在開源專案中完成的；
• 在熱門的開源領域，有經驗的開發者廣受歡迎，並獲得了大量實質性的獎勵；
• 在備受好評的專案中，開發者在軟體開發過程中享受到了空前的自主權；
• 事實上，幾乎所有的大型 ICT 公司都參與了多個開源專案，最高階別的成員當中，通常每個公司每年的合併成本（會費加上投入的僱員）都超過了一百萬美元。

如果脫離實際的話，這個比喻似乎暗示著標準是走向 ICT 歷史的灰燼。但現實卻有很大差別。一個被忽視的事實是，開源開發是比常人所認為的更為嬌嫩的花朵。這樣比喻的原因是：

• 專案的主要支持者們可以撤回（已經做過的事情），這將導致一個專案的失敗；
• 社群內的個性和文化衝突會導致社群的瓦解；
• 重要專案更加緊密的整合能力有待觀察；
• 有時專有權在博弈中被削弱，高資助的開源專案在某些情況下會導致失敗。
• 隨著時間的推移，可能個別公司認為其開源策略沒能給他們帶來預期的回報；
• 對關鍵開源專案的失敗引起過多關注，會導致廠商放棄一些投資中的新專案，並說服客戶謹慎選擇開源方案。

奇怪的是，最積極解決這些問題的協作單位是標準組織，部分原因是，他們已經感受到了開源合作的崛起所帶來的威脅。他們的回應包括更新智慧財產權策略以允許在此基礎上各種型別的合作，開發開源工具，包含開原始碼的標準，以及在其他型別的工作專案中開發開源手冊。

結果就是，這些標準組織調整自己成為一個近乎中立的角色，為完整方案的開發提供平臺。這些方案能夠包含市場上需要的各種型別的合作產品，以及混合工作產品。隨著此過程的繼續，很有可能使廠商們樂意推行一些包含了標準組織在內的舉措，否則他們可能會走向開源基金。

重要的是，由於這些原因，開源專案開始認真對待專案交付所包含的標準，或者與標準開發商合作，共同為完整的方案做準備。這不僅會有更多的產品選擇，對客戶更少的限制，而且也給客戶在開源方案上更大的信心，同時也對開源產品和服務有更多的需求。

倘若這一切不發生的話，將會是一個很大的遺憾，因為這是開源所導致的巨大損失。而這取決於如今的專案所做的決定，是供給市場所需，還是甘心於未來日趨下降的影響力，而不是持續的成功。

本文源自 ConsortiumInfo.org的 Standards Blog，並已獲得出版許可

（題圖：opensource.com）

---

作者簡介：

Andy Updegrove - Andy helps 的 CEO，管理團隊，由他們的投資者建立的成功的組織。他曾作為一名先驅，自1979年起，就為高科技公司提供商業頭腦的法律顧問和策略建議。在全球舞臺上，他經常作為代表，幫助推動超過 135 部全球標準的制定，宣傳開源，主張聯盟，其中包括一些世界上最大，最具影響力的標準制定機構。

---

via: https://opensource.com/article/17/7/software-standards

作者：Andy Updegrove 譯者：softpaopao 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出