開源交付
本文是前一個文件（設計規範）的邏輯延續，討論組織層面的架構控制問題。很多組織都在搞“開源”，還有細分為“內部開源”和“外部開源”這兩種概念。但很多管理層甚至工程師其實都不知道開源本質到底是什麼東西，彷彿把程式碼給出去，就叫“開源”。
從這樣描述的語義來說，“開源”的作用似乎和“慈善”的效果一樣，只具有“廣告”效應。這就是為什麼很多公司管理層總認為“開源”不是正道，你會認為一個公司負責“慈善”的部分是這個公司的關鍵問題嗎？這不一般是給董事長老婆的福利麼？
如果我們能有“守弱”一點的思維，虛心實腹，謹守直接可見的邏輯，少那麼多高大上理念。我們很容易會發現，開源的作用就只有一個：工程師可以看得見原始碼。
從這個基本邏輯開始推演，我們就必須接受，“開源的好處就是工程師可以看得見程式碼”，不是“高手都做開源”，“開源後高手就會加入我們的開發”，“開源是工程師職業生涯的證明書”，“開源會把不好的程式碼暴露在陽關下，人們就會把程式碼寫好”……真是扯淡，老婆還在天天抱怨房子沒有隔壁老王的房子大呢，你有空去看別人的程式碼？你這是裝天真還是揣著明白裝糊塗啊？
工程師什麼時候會有空去看別人的程式碼呢？嘿嘿，當然是要抄的時候。
比如我要做一個GPIO驅動，怎麼做呢？當然是直接找其他廠商的驅動直接拷過來開始改啊。找哪個呢？當然是找一個接近的啊，比如我的裝置是經過一個controller來控制所有gpio埠的，上面還連了一個iommu，就找這個唄。找不到？那就找一個接近的嘍，先用那個作為基礎，沒有iommu不要緊，網絡卡不是用了iommu嗎，從網絡卡這裡再抄一個。還要用debugfs暴露介面？不要緊，這個模式不是和rasdaemon很像嗎？從ras框架上拷貝就可以了。什麼？還要一個記憶體分配演算法，那我們可以拷貝slab的演算法啊，slab太重了？也不要緊，uclibc那個malloc肯定不重，從那裡拷貝吧……
你看，這就是現在大部分工程師寫程式碼的過程——拷貝貼上，再把邏輯拼在一起，減少漏洞，搞定。
開源給了他們拷貝的機會。
拷貝的缺點我們都知道了，這會導致程式碼的急劇膨脹（這也是Linaro成立的原始動力，因為ARM廠商眾多，這種拷貝的做法讓ARM的目錄轉眼間就超過Linux的所有其他程式碼了，Linus出來一頓痛罵，然後幾家ARM SoC供應商跑到Linaro合計合計，一年後這個目錄又縮回到普通大小了：））
這就是程式碼都在一起的威力：你手上一個二進位制，我手上一個二進位制，把拷貝的目錄合併？先開一年會好不好啊？
考量這個細節，我們就可以區分出開源交付的兩種形態了：
- 交付二進位制，提供原始碼
- 交付原始碼
很多企業（特別是國內企業）開源，其實做的是前者，這上面的收益其實很低，其實就是慈善，因為除了拷貝，你做不了其實任何事情。
第二種才是真得能達成構架收益的開源，比如我做一個記憶體演算法，交付給一個統計程式。這個我不是交付一個libmem.so的，我交付的是stat/mem這個子目錄，這樣，任何一個其中的開發工程師手上都是全部程式碼，架構師和系統工程師就有機會權衡我們前一片提到的“抽象”問題，決定每個特性是開克隆，還是合併為一個抽象。這完全取決於這個系統的架構師對這個市場的需求的選取（是需求在決定關聯，不是設計 ）。這樣，整個系統才有可能真得“合道”（最優解）。
開源的需求是來自非常細節的設計和開發過程，不是你紙上談兵在PPT上可以想清楚的。它的重要性和慈善，貢獻之類的關係非常少。它是放下了“保密”的包袱，來換取架構優化的優勢。如果這個地方沒有架構優化的餘地，你就只剩下“洩密”這個缺點了。
很多工程師可能覺得這是個小問題，但如何拷貝程式碼還能保持複用，對很多公司來說都是大問題。我們以前曾經嘗試過一種所謂CBB（Common Build Block）的策略，我認為這個方法是個徹底的失敗。
所謂CBB，就是把相對獨立的模組獨立出來的，在多個產品之間共享。但這種東西只能停留在PPT上用來YY。因為沒有沒有依賴的所謂“獨立模組”。就說你做的是一個二叉樹好吧，純粹的演算法，應該可以在各個產品中複用吧？
好了，現在的問題是，裡面要分配記憶體用什麼分配函式？
要寫日誌呢？
收到signal呢？
多執行緒訪問呢？
要跨機遷移呢？
要異常倒換呢？
……
你可以說，這些東西我都可以做成“可配置的”——為了用你一個二叉樹演算法，我還要配置一大堆這種引數？我不如自己寫呢。而且，本來一個二叉樹演算法挺好寫的，結果要考慮十幾種配置數百種組合下都能跑？——什麼叫“過度設計”啊？小哥哥。
什麼可以被抽象，什麼必須分離，現在沒有演算法可以自動做到，AI也不行。只有人能做到，而人必須看得見程式碼才能做到，這就是開源的驅動力。其他的，都是浮雲。就算比不開源，軟體的開發本質仍是這樣，你不對架構師提供原始碼，帶來的僅僅是這個損失。所以考慮原始碼提供的邊際，在於你認為這個地方有多少可抽象的餘地。如果你部門牆太多，純用二進位制交流，或者用二進位制交付，提供原始碼這種方式號稱開源，你的架構就面對很大的挑戰。
對這個模式的認知，也給我們如果對組織進行架構控制提供了思路。要對組織進行架構思想滲透，就是要調好的產品後者模組，把那個模組做到好，然後用開源的方式滲透到更多的產品，等這個雪球滾到一定的成都，就不需要你自己推了，工程師們會說：“我自然”。所以做這種整體的事情，永遠都是這個問題：“你要求名，還是求道”？