翻譯：話說平台（Stevey's Google Platforms Rant）by Steve Yegge

文章：Stevey's Google Platforms Rant 話說平台
日期：2011.10.13
作者：Steve Yegge
作者的部落格（2006至今）：Stevey's Blog Rants
作者舊的文章（2004與2005）：Stevey's Drunken Blog Rants


作者簡介：
目前任職於Google，之前任職於Geoworks與Amazon。程式語言生涯中有過兩次非常關鍵性的轉換，一次是組合語言，一次是Java 跟Perl，因為發現解決語言本身設計帶來的問題所花的時間，竟然比真正用在開發軟體系統的時間還多。其文章以長度聞名，長到應該稱為論文而非部落格，兼帶詼諧筆風，發表頻率大約一個月一到兩篇，作者總是說這些是在凌晨三罐啤酒下肚後的誇誇其談，但每一篇都是經過長時間醞釀，內容充實有見地的傑作。
獨立以Java/JPyton開發多人線上遊戲Wyvern，可讓玩家自行創建擴充遊戲內容。其工作團隊將Rails移植到Rhino上，Rhino是運作於JVM平台上的JavaScript引擎，Rails(Ruby on Rails)為一套受到廣泛喜愛使用的網站開發模組；為Emacs撰寫完整的JavaScript環境，期望在Emacs上可以有一套 JavaScript IDE，以及將來可用JavaScript而非elisp來開發Emacs extensions。


注意：作者已經刪除原文，因為原本應在公司內部流傳跟同事間互相討論的文章內容，卻意外地發佈到公開網路上。希望你能夠站在不同立場來閱讀，而不是斷章取義只看自己想看的部份。

這邊有原文的備份以及留言。
Steve的Google+頁面。


話說平台（Stevey's Google Platforms Rant）


我曾在Amazon工作了六年半，現在算一算，我在Google的日子也差不多那麼長了。關於這兩家公司，有個衝擊性的差異──在我的腦袋裡這樣的印象幾乎每天都在加深中──那就是，Amazon每件事都做錯了、而Google每件事都做對了。當然啦，這是很籠統的概括評論，但卻出乎意料的是個精確說法，很瘋狂吧。你可以舉出大概一百甚至兩百種不同的項目來比較兩家公司，而Google每一項都能勝出，除了其中3項以外。如果我記的沒錯，我確實曾用試算表列出來加以比較一番，不過法律部門不會允許我秀給任何人看，即使人事招募部門會愛的不得了。

讓我給你個例子稍微體會一下：Amazon的人事雇用流程存在著根本上的缺陷，每個團隊獨自為自己招募新人，以至於，各團隊之間的雇用標準，有著天差地別的不一致性，即使他們通過各種努力來撫平差異，仍然相去甚遠，而且，他們的操作方法一團糟，沒有真正的SREs，工程師們什麼事都要做、幾乎沒時間撰寫程式碼──當然啦，各部門情況不同，取決於你的運氣。他們不碰慈善、不幫助需要幫助的人、不鳥社群集體貢獻、或是任何類似的活動，相關話題從來沒有浮現過，或許只有在閒談說笑時才會提到，他們的辦公室是個滿佈灰塵的農場隔間，連一分錢都不會花在裝潢或是公共場地與會議室，他們的薪資與紅利遜斃了，最近因為來自Google與Facebook的競爭才好多了，不過，我們有津貼或額外獎金，他們都沒有──他們只是想要讓薪資帳面上的數字好看一點，就這樣子而已。他們的程式碼就像是災難過後滿目瘡痍，沒有工程標準或撰碼規則，除了團隊各自選擇性地、局部性地自己搞自己的以外。

話說回來，公道一點，他們的確有套不錯的程式庫版本控管系統，這是我們真的應該要盡力趕上的地方，以及發佈/訂閱系統，我們也沒有相對應的東西，不過，就大體而言，他們有的不過是一堆低劣的工具，藉以將狀態機裡的資訊，讀取或寫入到關聯式資料庫中罷了。我們不該模傚或借鏡，就算可以免費取得也要棄之不理。

我認為，他們的發佈/訂閱系統、程式庫版本控管系統，是Amazon比Google強的那3個項目之中的2點。

我猜你或許可以為他們辯護，"早早推出服務並不斷反覆地改進"，他們對於此作法有著近乎偏執的狂熱，你可以說他們這點做的很好，不過，關於這點，我們也可以從另一角度來爭辯，他們把"早早推出"這點，擴及應用到所有其他事項上，譬如說軟體工程守則與戒律跟其他一票的事項與流程，而這些都是會造成長期性的影響，所以說，即使這點讓他們在市場上有了某種程度的競爭優勢，但也造成其他許許多多的問題，總結而言，這不能算得上是個漂亮灌籃得分的項目。

但～是～，他們有一件事做的非常非常好，好到把其他政略上、理念上、技術上的缺失通通彌補回來。

Jeff Bezos是位惡名昭彰的微控經理人，他對Amazon零售網站頁面上的每一點像素都要微控管理，他雇用Larry Tesler，Apple的領頭科學家，可說是全世界中最有名且最受尊敬的人機介面專家，然後，Jeff不理會Larry提出的每一項建言，整整三年，直到Larry最後──明智地──終於離開了公司。Larry應會實踐大型的可用性測試，然後憑著研究報告、不存著一絲絲疑惑地證明出，根本就沒有人能夠搞懂、使用那該死的網站，可是，對於頁面上幾百萬個都包含著意義的像素，Bezos就是不能放手，就好像是對待寶貝兒子般呵護著，所以結果是，像素通通還留著，而Larry走人。

喔，對了，微控管理不是第三項Amazon做的比我們好的地方，我的意思是，沒錯，他們微控管理做的很好，但我可不會把這項列在強項或優勢清單上，以上所言只是為了下文鋪陳，幫助你了解背景。我們現在討論的人，是個在很多公開場合說過，而且是很認真地說，人們想進Amazon工作應該付他錢才對呀，當有人跟他意見不同時，他會遞出黃色便利貼有著Jeff的名字在上頭，提醒人們"誰才是公司的老大"，這傢伙可說是一個較守規矩的，嗯，Steve Jobs，我想應該可以這麼說，除了他沒有流行品味或是關於設計的理解力以外；可別誤解我了，Bezos可是超級聰明的仁兄，只不過呢，他的所作所為，讓那些一般般的控制狂看起來只不過像是抽大麻的嬉皮罷了。

有一天，Jeff Bezos發布一份命令書，當然啦，他總是不斷地在下命令，而如螞蟻般忙碌爬行的員工就會像被橡皮槌敲擊般地受到震撼，不過，有一次的情況是──大概是2002年吧，我想，誤差1年內──他發布一份命令書，發布範圍非常廣，內容龐大且沈重，讓你的眼珠子都快掉下來了，跟這份命令書相比，其他的就好像突然收到來自同儕的獎勵。

這份大大的命令書，其內涵大致如下幾點：

1) 從今以後，每個團隊要以透過服務介面(service interfaces)的存取方式，將資料與功能開放出來，。

2) 團隊間的溝通，都要透過這些介面。

3) 行程間的溝通(interprocess communication)，其他形式一概不允許：不能直接鏈結、不能直接讀取其他團隊的資料、不能使用共享記憶體模式、不能走後門、等等，唯一的溝通管道就是在網路之上的服務介面呼叫。

4) 任何技術皆可使用，HTTP、Corba、發佈/訂閱系統、客製的網路協定、等等，都可以，Bezos不管這些。

5) 所有的服務介面，毫無例外，都必須從骨子裡設計好，能夠對外界開放，也就是說，團隊必須做好規劃與設計，能夠把介面開放給外界的開發人緣使用，沒有例外。

6) 不做的人會被炒魷魚。

7) 謝謝，祝你有個愉快的一天！

哈哈！你們這群150位前Amazon員工，一眼就看出第7點是我加上的，純為搏君一笑，因為Bezos才不會去關心你今天過的好不好咧。

不過第6點就是認真的了，所以人們紛紛埋頭苦幹，Bezos指派了幾位上級牛頭犬來監督並確保進度，由超高級跟熊一樣大的牛頭犬Rick Dalzell領軍，Rick是前陸軍突擊隊員、西點軍校畢業生、前拳擊手、前Wal*Mart的首席虐刑官 斜線 首席技術長，而且也是個高大、和藹、令人敬畏的男人，經常使用"硬化介面(hardened interface)"字眼的男人，Rick本身就是個會走路會說話的硬化介面，所以不消多說，每個人都做出重大的進展並確保讓Rick知悉一切。

在接下來的幾年內，Amazon的內部轉變成服務導向架構(service-oriented architecture)，在這蛻變的過程中，他們學到了一拖拉庫的知識，在當時，是有著關於SOA的文件，但跟Amazon那種超大規模比起來，那些技巧就跟告訴印第安那瓊斯過馬路前要先看看兩旁有無來車一樣沒用，Amazon的研發團隊在這過程中學到了不少、發現了不少，其中的極少極小的抽樣範例如下：

- pager escalation變得異常困難，因為ticket可能會送過來送過去，過程中會超過20個服務呼叫，然後才能找到真正的擁有者，如果每一個呼叫都花去團隊的15分鐘的反應時間，那在找到真正的團隊之前幾小時就過去了，除非，你建構出很多很多的scaffolding、metrics、reporting。

- 你的同儕團隊，每一個，突然間都變成潛在性的DOS攻擊者，你沒辦法有進展，直到在每一個服務裡放上配額限制(quota)與節流閥(throttling)的機制。

- 監控(monitoring)與品質控管(QA)是同一回事。你過去不會這麼想，直到試著進行大規模的SOA才會有此體悟。但是，等到你的服務說"喔沒錯，我很好"的時候，到那時的情況可能是，伺服器裡唯一正常運作的功能就只是那一小塊懂得用愉快機器人的聲音說"我很好，收到了，收到了，停止通話"的部份而已，為了要確認整個服務是否真正運作無虞，你必須對每一個部分都發出呼叫要求，同樣的情況會遞迴式地出現，直到你的監控系統能夠全面性地對整個服務與資料做出各種面相的檢查，到那時，就跟自動化QA沒什麼兩樣了，所以這兩者皆位於同一連續帶上。

- 如果你有上百個服務，而且你的程式只能經由這些服務來跟其他團隊的程式做溝通，那麼，沒有一套服務探索機制(service-discovery mechanism)的話，你就不能找到想要的服務，而且在那之前，你得先有一套服務註冊機制(service registration mechanism)，而這本身也是一項服務，所以，Amazon有一套全體適用的服務註冊機制，以反射可程式化(reflectively, programmatically)的方式找出服務，得知API為何、目前狀態是否可用、在哪裡。

- 跟他人程式有關的除錯，這問題變得更難了，基本上是不可能的，直到有一套全面性的標準方式，能夠在可除錯的沙盒環境內執行服務。

上面這些只是少數幾個例子，Amazon在蛻變得過程中，逐漸發現、學習了數十個、甚至數百個像這樣子的知識，關於把服務開放出去，會有幾個想都想不到的冷僻知識，不過不會像你想的那麼多，將功能重新加以組織劃分成服務後，團隊學會了不該信任彼此，就如同他們也不該相信外部的開發人員一樣。

當我在2005年中離開Amazon加入Google時，這轉變過程還處於進行式，但已經相當先進了，從Bezos頒佈法令的時間點到我離開之時，Amazon已經從文化心態上轉變成一家凡事以服務架構為優先考量的公司，到如今，已經成為他們進行所有設計時的基本原則，即使是那些僅在內部絕不會被外部世界使用的功能。

現在，他們不是怕被解雇才朝這個方向進行，我是說，他們仍然怕被炒魷魚，這點佔了在那兒生存的一大部分，在可怕海賊王Bezos的底下工作。不過，他們朝"服務"的方向前進，因為他們已經相信這就是正確的方向，關於SOA這種作法，不用說當然有優點也有缺點，某些缺點還很大，但是整體而言，這是正確的，因為，以SOA來進行設計，會產生出平台(platform)。

沒錯，這就是Bezos他的法令想要達成的目標，他以前（現在也是）對各團隊過的好不好一點都不在乎，不關心他們使用的技術為何，事實上也不去管他們怎麼進行他們的工作，除非他們有搞砸的跡象，但是，Bezos很早很早以前就領悟到，在絕大部分的Amazon居民都不知道以前，Amazon必須成為一個平台。

你應該不會想到線上賣書的網站需要成為一個有擴充性、可程式化的平台吧，你會嗎？

嗯，Bezos領悟到的第一件大事是，為了販賣銷售書籍與各種商品所打造出來的架構，可以轉變成為用途可再定義的絕佳運算平台，所以，現在他們有了Amazon Elastic Compute Cloud(亞馬遜彈性運算雲端)、Amazon Elastic MapReduce、亞馬遜關聯式資料庫服務(Amazon Relational Database Service)，以及其他可在aws.amazon.com查得到的一狗票服務，這些服務是某些相當成功的公司的後端架構，我喜歡舉的例子之一是reddit。

另一個大領悟是，他知道，他們不可能永遠都打造出對的東西，我認為，當Larry Tesler說他媽媽完全搞不懂怎麼使用那個見鬼的網站時，Bezos的某條心弦被撥動了，也不清楚說的到底是誰家媽媽，但無關緊要，因為沒有人的媽媽能夠使用那個天殺的網站，事實上，我自己都覺得Amazon網站的介面令人膽寒、卻步，那時我已經在那裡工作超過五年了，我後來終於學會，如何控制眼睛的焦點、關注在那接近頁面中間的幾百萬個像素。

我不是很確定Bezos是如何體悟到這點的──洞察到他不可能打造出一套適用於所有人的產品，不過這不重要，重要的是他領悟了，其實，這玩意有個正式的名稱，叫做可存取性(accessibility)，這是運算世界中最重要的事情。

最 重 要 的 事 情。

如果你在心理嘀咕著，"啥？你是說，盲人聾人那種可存取性嗎？"，你不是唯一一個這麼想的人，我已經知道有很多很多像你這樣的人：上述那玩意對你們來說沒有可存取性，所以這觀念還沒能進入到你的腦袋裡，不了解也不是你的錯，就好像有人眼盲、耳聾、行動不便、或有其他殘疾也不是他們的錯一樣，當軟體──或可稱為概念體──不管是什麼理由，如果不能被某人存取、使用，那麼，就是軟體的錯、或是那概念的傳遞出錯了，這就是失敗的可存取性。

就如同生命中任何重要的大事，可存取性有個邪惡的雙胞胎哥哥，在幼年期享有父母的偏愛溺愛，已經成長為同等強大的復仇邪神第一名（是的，對可存取性來說，復仇邪神有好幾個），其名為安全性(security)，但是，乖乖隆個咚，這兩個從來沒被公平對待過。

不過，我主張可存取性比安全性來的重要多了，因為，可存取性若為零，你根本沒有產品，而若安全性為零，你仍然能夠得到在相當程度上算是成功的產品，譬如說Playstation Network。

所以說，對了，假使你還沒注意到，我其實可以寫出一整本書來討論這個主題，厚厚一本，填滿了那家我曾工作過的公司裡關於螞蟻與橡皮槌的有趣軼事，但那樣一來，我就永遠不可能發表這篇短短的夸夸其談了，而你也就無法讀到，除非我現在開始收尾做總結。

Google做的不太好的最後一點是平台，我們不了解平台，我們沒抓到它的意涵，你們其中一些人領悟了，但你們是少數民族，過去六年來，越清楚這一點就越讓我痛苦，我曾有一度希望，從Microsoft與Amazon來的競爭壓力，以及近來的Facebook，會讓我們集體清醒過來，並且開始動手打造泛用型的服務，不是半生不熟、特製的那種，而是，大致上類似Amazon的那種方式，一次全部到位，真正的，沒有作弊抄捷徑，並且從現在起把這點放在優先順序的第1位。

但是實際上沒有，它好像被我們放在第10還是第11位，或是第15位，我不清楚，只知道相當低；有少數幾個團隊很認真地看待這個觀念，但大部分的團隊，不是從來沒有思索過，就是只有一小搓人以小尺度的心態想過這個議題。

對大多數的團隊來說，若要求他們提供讓其他人以可程式化的方式存取他們的資料與運算資源，就算只是提供簡單粗略的服務，也是翻天覆地的大動作；他們大部分人都認為他們在打造產品，而且提供粗略服務是可悲的，回頭看看Amazon那串學習到的知識，然後告訴我，哪一點是粗略服務可以達成的，就我所知，沒有。僅提供粗略服務就好像需要汽車時卻只有零件。

沒有平台的產品是沒用的，說的更明白更正確一點，無平台的產品總有一天會被另一套平台化的產品所取代。

關於我們沒能了解平台的重要性，Google+是個超明顯的例子，從最最上層的管理領導人（嗨，Larry、Sergey、Eric、Vic，哈囉，您好），一直到最最底層的員工（嘿，就是你），都沒能了解，我們全部通通沒能體悟，平台的黃金守則是吃你自己的狗食，Google+這個平台是個可悲的後見之明，在啟動之日完全沒有API，最近我查了一下，目前也只有極少數可用的API。團隊成員之一在發佈API之時走進來通知我，我問道："所以，這是個跟蹤者API嗎？"，她臉現怒容說"對啦"，我的意思是，我那時是在開玩笑啊，但是，喔不，我們提供的唯一的API就是取得某人的訊息串流，所以，我想我把玩笑開到自己身上了。

Microsoft知道狗食守則已經有至少20年了，這已經是他們文化的一部分，已有一整個世代之久，你不能吃人類食物而給你的開發人員們狗食吃，那麼做只是為了短期的成功果實而劫掠了平台具有的長期價值。所謂平台，就是要考慮到長遠以後。

Google+就像膝蓋猛然一動的反射動作，就像是短期思考後的研究報告，根據錯誤的想法做出的結論，以為Facebook會成功其原因是他們打造出偉大的產品，但那可不是他們成功的理由，Facebook能夠成功是因為，藉由允許外界在其上開發，進而建立起一整群的產品，所以對每個人來說Facebook都不一樣，有些人把全部時間花在Mafia Wars上，有些人只玩Farmville，另外還有上百個甚至上千個不同的高品質的時間消耗機可用可玩，所以，所有人都可以在其上找到他們想要的某種玩法、用法。

我們的Google+團隊，看了看現況後說："天啊，看來似乎我們需要有遊戲，找一些人承包，嗯，為我們寫些遊戲吧"，現在，你是否開始能看出這樣的思考模式錯的多麼嚴重嗎？癥結在於，我們試圖預測使用者想要的，然後推出產品給他們。

你沒辦法做到，真的不能，沒有可靠的方法，在這個世界上，在整個電腦運算歷史上，從過去到現在，只有少數幾個人能夠穩穩地做到這點，Steve Jobs是其中一位，可是我們沒有Steve Jobs，我很抱歉，我們真的沒有。

Larry Tesler可能說服過Bezos相信他不是Steve Jobs，但Bezos明白他不需要成為Steve Jobs才能提供給所有人對的產品：大家喜歡的介面與覺得容易使用的操作流程，Bezos明白他只需要提供出平台，讓第三方開發人員來做，自然而然就會有了。

我要向某些（很多）人道歉，這些人會覺得我以上所說的不是再明顯不過了嗎，沒錯，的確是超超明顯到不行，但是我們並沒有朝那個方向前進，我們沒有領會平台這玩意，而且我們沒有體悟到可存取性的重要，這兩者基本上是同一件事，因為平台會解決可存取性的問題，擁有一套平台就是擁有可存取性。

嗯沒錯，Microsoft有平台的概念，你知道我也知道這多麼令人震驚啊，因為就其他事情來說他們通常"領會"到的程度多半不深，他們能夠了解平台完全是意外性的副產品，因為他們一開始的生意與業務就是提供平台，所以他們在這個領域有著三十多年的學習經驗，如果你去逛逛msdn.com花點時間瀏覽，假設你從沒去看過，等著被嚇到吧，那裡面的東西可是多如牛毛啊，他們擁有幾千、幾萬、幾十萬個API呼叫啊，他們擁有一套巨大的平台，其實話說回來，太巨大了，因為他們要面面俱到，不過至少他們朝著平台的方向在作事。

Amazon也領會了平台的概念，Amazon的AWS(aws.amazon.com)很棒，去看看吧，瀏覽一下，令人感到羞愧啊，我們可沒有那些東西。

很明顯的，Apple也體悟了，環繞在他們的行動平台上，基本上是非開放的形式，不過他們了解可存取性的重要，他們明白善用第三方開發團體的力量，而且他們吃自己的狗食，你知道嗎，他們做的狗食不錯吃喔，他們的APIs跟Microsoft比起來又乾淨又清爽，不能放在一起比較，而且是從很久很久以前就是如此了。

Facebook也體悟了平台這玩意，這點是真正讓我擔憂的，使得我抬起懶惰的大屁股寫下這篇，我恨寫部落格文章，我恨...加一下（譯註：指到Google+上發表），不管怎麼稱呼，反正就是在Google+上發表長篇大論，就算這是個糟糕的發表園地，但你還是這麼做了，因為說到底你真的希望Google能夠成功，我真的這麼希望！我的意思是，Facebook想找我去，其實說去就去滿容易的，但Google是我的家，所以我堅持我們要展開這場小小的家庭爭論，就算你感到不舒服也要做。

等到你被Microsoft與Amazon提供的平台嚇到後，嗯，我想也會被Facebook嚇到（我沒仔細看，因為我不想變得太沮喪），回頭到developers.google.com瀏覽一下，有很大的差別，對吧？看起來就好像你五年級的侄子搞出來的東西，當他被指派功課，試著描述一家大而有力的平台公司可能會打造出來的東西，前提是他們擁有的資源，僅是一個五年級生而已。

請不要誤解我──我知道，其實呢，dev-rel團隊可是經過一番"搏鬥"後才能把那些API向外公開，就我所知他們是很棒的，因為，他們真的領會了平台這玩意，而且如同英雄般努力掙扎地要創建出一套出來，可是，他們所處的四周環境卻是，講好聽一點是對平台冷感，難聽一點是對平台這觀念抱持著敵意。

我只是直白地描述出在一個外人眼裡developers.google.com長什麼樣子，看起來很幼稚。拜託，老天爺啊，Maps APIs在哪呢？其中有些東西還是實驗性質的專案，我有點進去看過的APIs都很瑣碎無用，很明顯地都是些狗食，甚至稱不上是好的有機食品，跟我們內部APIs比起來，簡直就是豬鼻跟馬蹄。

還有，也不要誤解我對Google+團隊的看法，他們可不是唯一的例子，現今，我們在內部進行的是一場戰爭，一邊是受壓迫、少數的平台推廣者，打一場或多或少逐漸敗退的戰鬥，而對手是勢力強大、信心堅定的產品家。

應該打造出外界以可程式化的方式存取的平台，若有任何人成功地將這觀念消化吸收、從頭到腳內化，這種團隊都是受壓迫者──我立刻想到Maps跟Docs，而且我知道GMail是往這個方向踏出第一步的團隊，但是他們很難得到資金挹注，因為這觀念不屬於我們文化的一部分，Maestro獲得的資金跟龐大的Microsoft Office開發平台相比有如九牛一毛：就好像小毛兔跟暴龍相比，Docs團隊心知肚明，除非他們能趕上Office的腳本語言功能，不然無法跟它競爭，但是，他們得不到任何關愛啊，我在此假定如此，根據Apps Script只能在Spreadsheet裡運作這點來看，而且API裡甚至沒有鍵盤快捷鍵的功能，就我來看，Docs團隊並沒有受到重視。

諷刺的是，Wave是個絕妙的平台，願他們在地底長眠，但搞出平台並不會帶給你立即的成功果實，平台需要殺手級應用軟體，Facebook──在這裡指的是，那一堆他們提供的服務，包括塗鴉牆、朋友、其他等等──就是Facebook平台的殺手級應用軟體。若你得出結論說，沒有Facebook平台，光有Facebook應用軟體也能像如今這麼成功，這可是個非常明顯的誤解。

你知道，外面的人總是不斷地說Google好自大傲慢喔，我是個Google員工，跟你一樣，每次我聽到那些話都覺得很煩躁憤怒，大體上而言，我們並不傲慢，大約99%不自大，我在文章開頭寫道──如果你回首看看久遠前的記憶──Google"每件事都做對了"，當有人說我們很自大，大部分的情況是因為我們沒有雇用他們，或是因為他們對我們的政策感到不爽，或是那一類的事情，他們推斷出傲慢這回事，因為這樣會讓他們覺得好過些。

但是，當我們擺出姿態，說我們知道如何為全部的使用者設計出完美的產品，那麼我們就是笨蛋，相信我，我可常常聽到有人這麼說，你可以用傲慢自大、天真浪漫、或其他字眼來形容──不重要，重要的是這就是愚蠢，不可能有這麼一個完美產品適用於所有人。

照這樣的思路下來，我們的瀏覽器居然不能讓人設定預設的字型大小，這不就是公然對可存取性(accessibility)的冒犯嗎，當我年紀越長，總有一天會失明，講的實在一點，我一輩子都在近視下過活，一旦當你到了40歲，你就沒辦法看清近距離的東西了，所以，字型選擇變成是生與死的問題了：可能把某使用者完全排除在產品之外，但是Chrome團隊就是這麼傲慢自大：他們希望打造出零組態的產品，而且相當自豪，誰理你是瞎子或聾子啊，誰管你，去你的吧，用你的餘生在每一個頁面按下Ctrl-+吧。

不僅是他們，我說的是所有人，問題癥結是，我們是家"產品"公司，一直都是，我們打造出成功的產品，擁有廣泛的吸引力──搜尋引擎──而那樣巨大的成功使得我們心有成見、視野偏了。

Amazon過去也是家產品公司，因為有道異常的力量， 才使得Bezos領悟到他們需要平台，那道力量是他們的市值逐漸蒸發，他被逼到牆角了，不得不想方設法突圍，但他擁有的不就是一群工程師跟一堆電腦嗎...要怎麼樣才能變成印鈔機呢...你可以看出他是如何達到AWS這個結論，不過這是放馬後砲。

Microsoft從一開始就是個平台，所以他們有很多經驗與知識。

Facebook，嗯：他們讓我感到憂慮，我不是專家，不過我很肯定他們一開始也是產品，並且取得很長久的成功，所以我不知道他們何時轉變成為平台，應該是很久以前，因為他們要成為平台後那些像Mafia Wars（這些東西已有一定年紀了）才會出現。

或許，他們做的僅是將我們檢視一番後問道："我們如何擊敗Google？他們缺少了什麼？"

我們面臨一堵巨大的問題高牆，需要經過一番有如腥風血雨般的文化心態轉變後，才能開始迎頭趕上，我們對外沒有在做服務導向的平台，同樣的，內部也沒有，這表示說，整個公司都"沒有領悟"：PMs沒有、工程師沒有、產品團隊沒有、沒人有，即使單獨個人有、即使你有，那也無關緊要，除非我們把目前情況當做生死存亡之秋來處理，我們不能不斷推出產品，然後假裝之後會把產品轉變成又美又迷人的可擴充式平台，我們試過了，沒成功。

平台的黃金守則，"吃自己的狗食"，可以換句話說"先打造出平台，然後用它打造任何東西"，你沒辦法事後才把平台放進去，再怎麼說事後才想要做太困難了──去問問那些動手把MS Office平台化、或是把Amazon平台化的人，如果你放在後面才動手，事情會比從一開始就做好難上十倍，你沒辦法作弊、沒有捷徑的，你不能讓內部軟體走秘密後門擁有特殊的優先存取權限，不管理由為何都不能這麼做，難題必須從一開始就起手解決。

我並沒有說現在動手已經太遲了，但我們等的越久，就越接近"太遲了"的那一天。

老實說，我不知道怎麼收尾，我已經把今天想說的都寫下來了，這篇文章醞釀了6年之久，如果言詞間有冒犯之處，或是我誤解了某產品、某團隊、某位同僚，還請包涵，或是其實我們真的有在進行打造平台，卻剛好我以及跟我討論過的人從未聽說過，我在此說聲抱歉。

不論如何，我們必須開始把它做對。