參考平臺
這幾天在一個標準組織開會，會場上想法多，有些問題就先寫下來，用來分享給其他參會者，不一定會很嚴謹，先建一下邏輯而已。
現在很多標準組織都喜歡建“參考平臺”，核心原因是現在標準已經越來越難寫了。所以，幾十年前你會看到POSIX這樣的非常詳細的標準，現在就只能看見SBSA這樣的簡單“建議”。現在跑通一個東西太容易了，效能才是關鍵問題，但效能是沒法靠標準來規定的。你定了標準也沒法執行，效能上不去，Who Care？
問題是，參考平臺在標準組織中其實很難運作。你要不要做得實用？不實用，沒人用，這東西有什麼“參考”價值？你做得實用，你就成為其他實用系統的競爭對手了，誰會參與這個開發？
戰略這種東西，沒有“中間地帶”的。你定義一個角色，就要把這個角色做到極致，沒有“都可以”這一說。商業公司有商業公司的極致，標準組織有標準組織的極致。而這些極致正是他們的短板。比如商業公司提供的平臺，無法取信於生態——我寫一個軟體，為什麼要繫結在一家公司上面？同樣，標準組織提供的平臺，無法獲得支援——如果你是和我競爭的，我為什麼要加入你？
所以，參考平臺唯一的生路，是在沒有商業應用的時候做到最優，有商業應用的時候，放棄，然後僅做標準，或者，再擴充套件一點，它可以做一個CI系統，把商業應用整合程序，做標準驗證。這才是它的驅動力，否則都是運作不久的。
CI系統本身可以有很多目的，我能想到的是這樣一些：
- 驗證關鍵特性在不斷演進的新軟體和硬體上得到保證
- 驗證同一個軟體棧在不同的硬體上可以互聯互通
- 驗證軟體的不同部件在不同的軟體上可以互聯互通
要做到這個，就需要有一個（組）核心的人可以持續在這個上面進行運作（簡單說，需要一個架構師），無論這個人來自標準組織本身，還是來自其中一個成員。
另一個難以處理的問題是，所謂是否有商業軟體在生態中，這背後是個很微妙的事情：部分成員可能沒有做這個商業軟體，但他可能有做這個商業軟體的意圖，他們會在這個合作中盡力嗎？這個其實考驗運作團隊的智慧，因為如果大家都承認“現在沒有商業軟體”，你就已經佔據話語權的中心了，這個優勢本身可以幫助你壓掉那種小動作，直到你自己決定做商業軟體，並把參考平臺轉化為CI系統。