很興奮看到Facebook能一直有效的處理懲罰來自snap這個急速生長的新興企業的威脅。Facebook以其璀璨的產物和社交應用，一直在不絕減弱SNAP之前流星般的增長速度。這是一個研究大公司操作他們當前優點，當真自我迭代以面臨競爭敵手威脅的案例。這種環境也讓我想起了我在谷歌的時候，其時Facebook對谷歌而言是一個快速增長的威脅，我們的團隊其時本可以更好的操作競爭優勢，下面是對谷歌Open Social的反思和一些履歷教導。

Facebook vs Open Social

在2007 - 08年，Facebook的影響迅速飆升，他們收集了大量的用戶信息，跟著時間的推移，這顯然對谷歌的告白業務組成了威脅。

一個鮮為人知的奧秘是其時照片和游戲占據了絕大大都的頁面欣賞量，用戶的許多時間都花在了Facebook上。為了消除這種日益增長的威脅，谷歌成立了社交網絡同盟，試圖“圍剿”Facebook這個平臺。Open Social就是谷歌在社交規模上首次對戰Facebook。

這個觀念很簡樸：建設一個技能尺度，讓所有社交網絡都可以實現和支持。

其時谷歌已經聚積了相當一批社交網絡的參加者，將會把這些流程尺度化，答允第三方開拓者通過API在網絡中陳設應用措施。甚至有一個名為“盛宴”的參考實現尺度，使java和PHP也能接入。

已經有很多社交網絡同意整合，My Space、雅虎、Hi5、Bebo、Orkut、Friendster、LinkedIn和許多其他公司都談好了。其時的代價主張就是不輸給Facebook，開拓人員構建的代價互換可以編寫應用措施并在任那里所運行應用措施，理論上看，這將得到更多的用戶。

尺度的碎片化

實現API不能老是寄但愿于尺度化的空想上，固然Open Social能實現Apache的參考尺度，但它有兩種分類：Java和PHP，險些不能生存一致性，所以假如一個容器是成立在PHP中，他們大概無法支持java版的溝通成果操縱。更為巨大的是，My Space，其時最大的參加者，本身用定制版的C #，從參考尺度上看，這造成了更多的分歧。

最終，谷歌應用引擎僅合用于其時的Python，這限制了Open Social有一個更完整的開拓者故事。第三方開拓者本應該可以或許在任何語言編寫應用措施，與其他基于Java的API和Open Social接口一樣，然后直接陳設和擴展在他們的應用措施上。然而功效卻恰恰相反，這些應用措施開拓人員必需尋求AWS的輔佐。

需要 “marquee container”

因為與尺度的紛歧致性，Open Social自己釀成了一個“進修一次，每個處所都要重寫”的操縱而不是推行“一次編寫，隨時運行”的理睬。可是開拓者的代價主張是編寫一次就行，在My Space，雅虎、Hi5和其他參加者身上都能用，假如開拓者不得不手工編寫和改寫每個社會網絡，那這樣開銷就太大了。不如把留意力放在思考Facebook是如何到達100萬用戶的呢？

My Space的樂趣開始下降，雅虎從未真正實現一個主要屬性，韓國云服務器 美國云主機，谷歌的主要產物Orkut，只在巴西和印度這樣不引人注目標處所有很高的占有率。谷歌一直在提供和強化一個主要選框容器的形式，YouTube大概已經可以或許標志基本信息了。假如沒有這樣的強力相助同伴，對比于和Facebook競爭這件事是不值得繼承的，谷歌但愿從Facebook手中獲取市場份額，但并沒有理睬將這些成果打造本錢身的焦點產物，并操作現有的網絡實現快速增長，說到底，它們缺乏社交產物的DNA。

Open Social對谷歌而言是社交產物恒久盡力開始：Friend Connect， Buzz， Latitude， Google+和其他谷歌的產物都是。極具嘲諷意味的是，社會周邊信息和內容搜索問題直接引導出谷歌最驚艷的產物：谷歌圖片。這就是谷歌樂成的原因，產物問題可以容易辦理。可是，領略社會和產物并不在同一緯度。

在早期，谷歌只做搜索，界面設計清潔簡樸，這點直到本日仍然如此。除此之外，險些沒有空間來思考“用戶體驗”，絕大大都重點是花在靠山：提供高質量的搜索功效，優化機能和晉升速度等等。簡直，這些都是很重要的事情，但某種水平上間接影響了產物的信息架構，因而影響到了用戶的體驗。所以如今的產物團隊很洪流平上是重視技能而輕視設計，因為有UI團隊在身后支持，這早就定好了基調，但對付社交產物而言這點并不是一個要害問題。