DevRel: 開發者關係和技術布道

我寫這篇文章的動力其實很簡單。最近，我有幸與幾位中文區的 DevRel，如 Steven、dai 老師、uvd 和 George，進行了交流。同時，我也時不時與我的前老闆交流，發現中文區的 DevRel 人員並不多。基於我自己積累的一些 DevRel 工作經驗和體驗，我想借此機會分享我的見解。DevRel 是一個既複雜又年輕的職業，有時我也不確定自己是否走在正確的道路上。但有一點我相信：DevRel is a lifestyle。

特別謝鳴：Jenks @ filecoin 和 Rod @ Ledger，我的兩位導師，也謝謝前老闆。

PS: 太多可以說了，寫不完了啊啊啊啊

一些簡介#

我最早接觸布道是在 seedao，那時候我參與主講了一門課程。後來，也在 Rebels 和小幽靈社區進行過 Web3 知識分享，當時可能還沒到 DevRel 更多是作為講師的身份。我的專業背景偏向技術（專攻超算，研究課題與區塊鏈相關），這段背景可以幫助我更好地進行輸出。同時，根據費曼學習法，簡潔的語言向他人清晰解釋一個概念，可以檢驗自己是否真正理解了這個概念。在 Rebels 進行分享時，我發現自己能夠用簡單的語言清楚地解釋技術概念。逐漸地，我開始更深入地學習 web3 和區塊鏈，為我的畢業設計做準備。

在學習過程中，我接觸了 LearnWeb3 和 Alchemy Learn。Vitto（現在在 Cyfrin 工作）對我影響很大，因為通過他，我了解到了 DevRel 這個職位。也是因為開發社區，我了解到了開源和技術布道。後來，我加入了 BNB Chain，擔任 DevRel，感謝我的前老闆 Zoe 和 Yian。在 BNB Chain 期間，我主要研究 Greenfield 存儲鏈。之後，我加入了 FLock，選擇這裡是因為邏輯自洽，同時匹配我的背景。

雖然我個人覺得我的編碼能力不算強，肯定不如很多人，我最多只能編寫 MVP，對於更深層次的邏輯框架確實不太擅長。但是我有一項能力，那就是能夠把複雜的邏輯簡單化。這個能力不是很多人具備的，我會根據聽眾或是聊天對象的背景來進行簡化，改變我的敘事方式。例如，對於非技術人士，我會更追求高層次的概述。而對於對 web3 技術感興趣的人，我會更多地提到區塊鏈方面的知識。對於對 AI 感興趣的人，我則會重點解釋聯邦學習。

我相信，作為一個 DevRel，除了技術背景外，溝通和解釋能力也非常重要。這就是為什麼我努力學習如何用簡單明瞭的語言向他人傳達複雜概念。我會根據對方的背景和需求來調整我的敘述方式，以確保他們能夠理解和接受我的講解。

總結下來

技術背景
願意對外輸出
上下兼容的溝通和解釋能力
研究能力
一腔熱情

什麼是 DevRel#

DevRel 的歷史與演變#

在我們進入正題之前，我覺得我們應該先了解什麼是 DevRel 以及其具體的職責。DevRel 一詞最早起源於 1980 年代的蘋果提出，當時的情況是電腦和軟件的起源。那時候蘋果發現，蘋果的理念過於新穎，很多人沒有辦法理解他們是什麼，或是說 macOS 的好處。因此他們需要一個懂技術又懂市場營銷的人去做一些引導和指導的工作。教導和指引大家什麼是 macOS 和蘋果產品並使用它們。隨著更多的技術公司的出現，大家發現產品不再是主要的關注點，而是如何集成成了主要問題。由此，DevRel 走向了大眾，越來越多的人成為 DevRel。許多公司通過 DevRel 打造了屬於自己的生態，並通過生態夥伴逐漸變強。例如 Twilio 和 Spotify，關於這個我們會在下一章繼續詳談。

在 DevRel 的定義中，不僅僅是教導和指引，還包括了與開發者社區的互動、建立關係以及提供支持。通過與開發者社區建立密切的聯繫，DevRel 能夠更好地了解開發者的需求和問題，並提供相應的解決方案。這種互動還可以促進開發者之間的合作和知識共享。因此，DevRel 不僅僅是一種市場營銷手段，更是一種與開發者共同成長的過程。

另外，隨著技術公司越來越多，DevRel 也越來越重要。技術產品的競爭越來越激烈，僅僅有好的產品已經不夠，還需要通過 DevRel 來傳達產品的價值和優勢。通過與開發者社區的合作，技術公司能夠更好地推廣自己的產品，並吸引更多的開發者使用和支持。

現在 DevRel 在技術行業中扮演著非常重要的角色。它不僅僅是一種市場營銷手段，更是一種與開發者社區緊密合作的方式。通過與開發者社區建立良好的關係，DevRel 可以幫助技術公司推廣產品、解決問題，並促進開發者之間的合作和共享。在下一章中，我們將深入探討 DevRel 的具體實踐和案例。

這個 quote 我覺得挺經典的，確實是說明了一個 DevRel 的 Daily norm 是什麼，(一個全才 ((不是，具體感覺是 dev + mkt + prod 的融合。

Generating leads, taking over the documentation, being a partner to product management, on-site consulting, organizing conference booths, budgeting, create marketing materials, participating in product development, creating and running weekly workshops, maintaining integrations into other products, travelling your geo region up to 80% of the working time.
—— Alexander Reelsen

Dev Evangelist, Dev Advocate, Dev Relations#

這裡解釋一下，這三個工種，很簡單，在我看來大家都差不多。不過功能性可能因公司而異。

通常能夠進行這種分割的公司通常是大型公司，在小公司中很少能夠實現這種分割。據我了解，Polygon、Circle 和 BNBChain 都有明顯的分工。Circle 在 DevRel 方面分為 3 個部門在 MKT 下面（這個之後會聊），DevRel 團隊的創始成員是 Twilio 的 DevRel 團隊的成員。（Twilio 的 DevRel 是業界公認的一家做得很好的公司）Circle 的 Dev 社區的引入將由 Dev advocate 負責。Evangelist 將負責進行研討會和演講。最後，Dev Relations 將負責文檔和演示代碼。這是大公司的做法。其他中小型公司不會劃分得太細。

在 BNB Chain 的時候，我們也有解決方案架構師和 DevRel，很多時候根據活動地點派遣不同的人员。例如，我的上級在迪拜，他會參加迪拜、印度和中東地區的活動。解決方案架構師在歐洲，EthCC 就由他去參加。我恰好也在歐洲，所以也曾在 eth Lisbon 的演講中客串過。

Code, Community, Content：DevRel 的三大支柱#

不過接下來的段落，我會按照更科學的方法解釋 DevRel 的主要職責。我們可以通過三個 C 和 5 層金字塔來進行細分。三個 C 主要指的是 “code”，“community” 和 “content”。讓我們先聊聊這三個 C。

Code#

Code 代表 demo repo，live coding，以及一切和代碼相關的內容。目前，我看到了幾個比較好的例子，例如lensV2和Jarrads的boiler template和視頻。代碼範例和 live coding 可以快速幫助開發者集成各種服務。這一點非常重要，因為好的代碼範例能夠讓生態系統內的開發者事半功倍。代碼範例通常會與文檔關聯，而 live coding 則是社區和活動的一部分。因此，很多時候在業內討論時會說，DevRel（開發者關係）不需要太強調代碼。然而，我認為這個觀點是不正確的。只有當我們了解開發者的開發路徑，我們才能夠更好地編寫文檔，並通過使用 demo/SDK 來更好地輔助開發者加入生態系統。

Community#

在 DevRel 領域，“社區” 這一概念涵蓋了兩個主要部分：開發者生態和活動（線上和線下）。

開發者生態#

首先來看開發者生態，傳統上，管理開發者生態通常是開發運營（developer operations）的任務，這與 Docker 和 CI/CD 等 DevOps 工作不同。以 BNB 為例，他們在 BNB Discord 上設有專門的開發運營團隊，負責處理開發者面臨的各種問題，如節點設置和 Greenfield 開發。而我們在 DevRel 中的主要職責通常是對外技術講解。然而，在規模較小的公司中，DevRel 和開發運營的職責往往重疊，社區中遇到的任何技術問題通常都由 DevRel 來解決。例如，在 Lens 的開發者社區中，Nadar 會親自介入解答問題，這增加了社區互動的親切感。

活動#

另一個重要部分是活動，包括線上和線下活動。線上活動包括 Community Call、AMA 和 Workshop 等，DevRel 人員基本都能勝任這些活動。從之前的數據和體驗來看，技術社區通話是促進討論和展示項目活躍度的有效方式。AMA 既有外部主導的，也有內部主導的，具體取決於需求。例如，我曾參與 ZetaChain 和 Greenfield 的 AMA，並每週主持一個 AI x Web3 的 AMA，邀請各項目方參與討論。線上和線下工作坊的最大區別在於聽眾熱情的感知。線上活動由於常常涉及多屏操作，可能無法及時獲得反饋，而線下活動則可以讓大家直接在現場互動，容易感知和回應觀眾的情緒。線上工作坊的優點在於，它幫助那些社交恐懼的人更輕鬆地參與（如 starkastroCN、LW3 和 Developer Dao 所舉辦的線上工作坊）。

至於線下活動，比如黑客馬拉松（hackathon）、開發者大會（devcon）和 ETHCC 等，情況就更加多樣。在這些會議上，DevRel 通常會負責展位，幫助與會者更好地理解技術和產品。在黑客馬拉松中，DevRel 的作用尤為重要，因為我們最了解如何向外界展示，並且最能幫助參賽者解決問題。在這些會議上，你幾乎總能遇到一些常駐的 DevRel，如 Nadar（Avara，Lens/AAVE）、Simon（Edge&Node，The Graph）、Kevin（Polygon）和 Mirko/Francescco（Consensys&MetaMask）。DevRel 形成了一個緊密的小圈子。此外，線下的 talk 和 workshop，如 HackerHouse 分享會和各種活動中的演講，通常也是由 DevRel 負責。技術的對外傳播是我們的重點任務之一。

Content#

在 DevRel 中，內容創作是不可或缺的環節，主要包括兩大類：文字和視頻。

文字內容#

文字內容涉及多種形式，包括技術分析、文檔、教程、Course 以及 Thread。以我的個人經驗為例，我比較喜歡編寫文檔、教程和 thread。通常，我們官推的 thread 的撰寫會由我們的 technical writer 負責，而我主要負責寫一些自己做的研究和 DML 相關的內容。這裡我也分享一下我在維護文檔方面的一些經驗：很多時候 dev 並不喜歡寫文檔，但是好文檔才是開發者入門的敲門磚。如何寫得更容易理解和及時更新是關鍵。同時撰寫文檔不僅僅是記錄步驟和解釋，更要以引人入勝的方式組織敘事，讓每個信息點都能連貫地串聯起來。為此，我每個月都會專門花費 3-4 天時間來思考如何改進我們的文檔，使其更加有效和吸引人。教程這塊則是，請把你自己當成新人，按照理解邏輯，如果初學者都能理解的話所有人也都能。我自己寫文檔首先會去想主題，這個教程想要達成什麼，接著分解代碼，決定篇幅。最後著手開始寫。寫完後一定要把自己定位成初學者多跑幾次，做好測試集，不斷的優化和改善內容。

視頻內容#

視頻內容的製作是另一個關鍵領域。從業界領先者如 Patrick Collins、Nadar 和 Jarrods 的視頻製作方法中，我學到了很多。YouTube shorts 的製作通常強調在 60 秒內完整地講述一個概念或故事。而常規視頻內容則更為廣泛，通常圍繞 demo 和集成使用方法。例如，workshop 和 panel 的錄製視頻是寶貴的學習資源。儘管我個人更傾向於直接閱讀代碼，但考慮到不同的學習風格，結合視頻和 Git Repo 的方式是一個很好的選擇，尤其是在受眾群體不明確的情況下。對於 How to 類的內容，視頻是更合適的介紹方式，因為它可以通過視覺效果直觀地展示如何使用我們的產品以及注意事項。

金字塔#

以上是我對 3C 的理解。在寫文章的時候我也做了一些調研，發現還有一個更細分的解釋。這個解釋實實在在的說明了一個 DevRel 的大致工作任務，其他的雜活就放 misc 了。就像我上面說的 DevRel 通常會和 technical BD/product marketing 很接近但是很多不同。身為 DevRel 的首要原則是對自家產品的融會貫通，知道產品技術原理，用戶邏輯和執行邏輯。接著通過不同的手段把這些信息和優點轉化為所有人都能聽懂的語言。手段可以是活動，可以是 workshop，也可以是內容輸出。但是重點是讓大家能理解我們在做什麼，為什麼要用，怎麼去用。

events
workshop & webniar
education content
Community support
Documentation & onboarding

Developer first & Developer Plus#

在 DevRel 的世界裡，我們將公司分為兩種類型：Developer First 和 Developer Plus。

Dev First 是以開發者為主要用戶的產品，通常以開發者工具、開發工具和開發輔助為主。比較著名的例子有 Vercel、MongoDB 和 Twilio。這類產品的目標是讓更多的開發者使用 SDK 或服務進行開發。它們致力於為開發者提供優秀的開發體驗，幫助他們更高效地開發和部署應用程序。這些產品通常提供豐富的文檔、示例代碼和支持，以及與其他開發工具和服務的集成。通過滿足開發者的需求並幫助他們取得成功，Dev First 公司能夠建立起強大的開發者社區和忠實的用戶群體。
Dev Plus 是開發者作為次要目標或錦上添花的產品，而不是主要聚焦的中心。這些公司的核心業務通常是面向企業或消費者的產品。雖然它們也提供開發者工具和支持，但開發者並不是其主要的用戶群體。相反，它們的產品更注重於滿足企業或消費者的需求，提供解決方案和服務。著名的 Dev Plus 公司包括 Apple、Google 和 Microsoft，它們在不同的領域擁有強大的市場地位，並通過創新的產品和技術吸引了廣大用戶。

在 DevRel 中，Developer First 和 Developer Plus 都扮演著重要的角色。它們共同推動著開發者生態系統的發展和創新。Developer First 公司通過提供優秀的開發者體驗和工具，吸引了大量的開發者，並促進了開發者社區的繁榮。而 Developer Plus 公司則通過面向企業和消費者的產品，推動了技術的應用和推廣，為開發者提供更廣闊的市場和機會。

無論是 Developer First 還是 Developer Plus，DevRel 的目標都是與開發者建立良好的關係，理解他們的需求並提供支持。通過參與活動、舉辦工作坊和分享知識，DevRel 可以與開發者進行深入的交流和合作，幫助他們解決問題、提升技術水平，並促進產品的創新和發展。總的來說，Developer First 和 Developer Plus 在 DevRel 中都扮演著重要的角色，各自有著不同的定位和目標。無論是專注於開發者的產品，還是將開發者作為輔助目標的公司，它們都為開發者提供了豐富的資源和支持，推動了開發者生態系統的繁榮和創新。

Mkt or Ops or Dev? 我應該在哪裡！#

經過與眾多 DevRel 的交流和幾家公司的面試後，我發現不同公司對 DevRel 的理解和定位差異巨大。這其中並沒有對錯之分，只有實際效果的考量。一些公司將 DevRel 視為市場部門的一部分，而另一些公司則認為它應歸屬於技術部門，還有的公司認為 DevRel 更偏向於運營角色。這些不同的視角在很大程度上決定了 DevRel 的整體策略和職責定位。

很明顯，採取中庸的立場在這裡並不可行。相反，DevRel 的多面性恰好與我們之前提到的 “三 C” 原則相呼應。其中，“內容（Content）” 對應市場（Marketing），“社區（Community）” 對應運營（Operations），而 “代碼（Code）” 則與開發（Development）相聯結。每個公司根據自己的業務需求和戰略目標，對 DevRel 角色的理解和期望各不相同。

傳統和 Web3#

由於我沒有從事過傳統 web2 的 DevRel 工作，這段主要以我採訪的 web2 轉 web3 DevRel 和我收集的資料為主。

在傳統的 DevRel 和 web3 的 DevRel 之間，內核沒有太大的區別，主要的事務也是相似的。然而，web2 的 DevRel 更加商業化，而 web3 的 DevRel 更加注重社區的發展。

"web2 companies are actually profitable lol so it's much easier to see exactly how devs translate into profit, which in turn makes it easier to measure and plan devrel" - cat

這段引用來自我的一位 DevRel 領域的朋友，Aztec 的 Cat。她的話揭示了 Web2 和 Web3 公司在 DevRel 重視程度上的不同。在 Web2 公司，由於採用訂閱制和產品付費制，他們能夠更直接地觀察到各種開發者關係活動對營收的影響。相比之下，在 Web3 領域的 DevRel 工作，跟蹤 KPI 和制定 Metric 更具挑戰性。舉例來說，我們可能依賴於鏈上交易量和客戶端下載量這樣的直觀數據指標，但這些並不能直接體現在營收上，尤其是在產品處於測試網階段時。

在伊斯坦布爾，我有機會與多位 DevRel 深入探討 Web3 領域的情況。有一個觀點特別令我印象深刻：“在 Web2 時代，我負責的開發者人數可能在 1 萬到 10 萬之間，難以深入了解每個人的情況。但在 Web3 時代，開發者社群規模較小，成員在各種活動中經常互動，形成了一個緊密的小團體。” 實際上，根據 2023 年 10 月的Developer Report數據，Web3 領域的月活躍開發者數量為19,279人，估計全職開發者約6,279人。這表明，與 Web2 相比，Web3 開發者社群相對較小，但這正是它能形成獨特關係網絡的原因。

我的另一位朋友 Rod 曾說：“Web3 的開發者就像一個小家族，經常在各種黑客馬拉松活動中相遇。這種環境促進了特殊的人際關係，為交流提供了機會。” 相對於 Web2，Web3 中的溝通更為親密和個性化，因為參與者數量較少。這種親密感是我特別喜歡 Web3 的原因，它給人一種大家庭的感覺。

心得感受#

自 3 月開始在 BNB Chain 做 DevRel 到現在也小半年了，感覺仿佛過了 2-3 年。Web3 一天如人間一年真的沒有問題。今年飛了很多地方，說實話 10 年英國我除了回國以外，基本沒怎麼出去過。今年一年，有 25% 的時間在參會，也算是達標 DevRel 25% travel 這個標準了。4 月的 ETH Lisbon，7 月的 EthCC，8 月 GHH，9 月 Token2049，11 月 Devcon。這 10 個月真的做了很多不同的嘗試，不斷的試錯，總結，改善，進步自我。今年做的一些事兒，也做個總結。

今年參與籌備了 2 個線下活動，token2049 的 What the flock，ETH London 的 DML night
Judge 了 3 個 hackathon，BNB Chain 的 Zero2Hero（協助），HomeDao Hack 和 ETH London
參加了 4 個 hackathon，ETH Lisbon，ETH Paris，ETH Singapore（謝謝 Card3 團隊），ETH Istanbul
跑了 50 + 活動，做了 5 + 線下 workshop，10 + 線上分享
內容這塊寫了很多在備案中，陸續會更新出來！

總體體驗下來，DevRel 是一個很複雜的工種，我更願意稱之為 lifestyle（生活方式）。除了 3C 之外，DevRel 的主旋律是出差，尤其是大型 hackathon 和聚焦開發的 conference (devcon，edcon) 在不斷出差中，DevRel 逐漸變成一種生活方式。去到各地和當地的開發者進行接觸，了解痛點，解決痛點。對我來說今年去了很多地方，看到了很多有意思的趣事。

研究和敘事#

除了 DevRel 的基本職責之外，我會自己做些研究工作。我認為，對於 DevRel 來說，探索新趨勢和技術是至關重要的。這不僅涉及對新敘事的理解，還包括將這些敘事與現有技術框架相結合，進行創新性嘗試，以吸引新的開發者群體。

在巴黎聽完 bob, the solver 後我立即思考如何將我們的產品技術與他的觀點結合起來，如何不再依賴 classifier 而是 ai agent
DAO 和 ai agent 的結合，William（42 Agents）和 safe 目前也都在看這個方向。我個人也十分看好。趨於自動化的投票托管，從而提高投票效率。
研究內部發起的學術研究，ZK 的結合或是去中心化算力的結合

很多時候，由於 DevRel 和 technical BD 很接近，因此參會聊的很多項目也會由我去跟進和 review 文檔。日常是 DevRel 參會時是 BD 說的就是我吧。對於文檔的審核來說，這是一項挑戰重重的任務。我需要徹底了解項目的內容、操作方式、使用的 SDK，甚至是否有自己的專用語言，然後基於這些信息構思潛在的合作方案。這不僅要求我對我們自己的技術了如指掌，還需要洞察市場趨勢和理解合作夥伴的項目願景及技術實現。例如最近在看我們如何和去中心化算力進行合作，允許用戶租借算力，只需要貢獻數據即可。一個好的 DevRel 必然是使用過自己產品並且對自家產品非常熟悉。

黑客松#

我最喜歡的部分來了 hackathon。hackathon 是一個奇妙的場景，匯集了眾多 hacker，提供了極佳的交流和學習機會。作為 DevRel，我認為參與 hackathon 是最佳的學習和互動場景。在這裡，你會看到許多 DevRel 協助 hacker 構建產品，這個過程中充滿了創造和協作的氛圍。

我參與 hackathon 或擔任評委的原因很簡單：只有深入了解整個流程，我才能更有效地指導和支持其他參與者。DevRel 在 hackathon 中的主要 KPI 是項目數量 —— 我們希望儘可能多的項目使用我們的技術，這樣才能為後續的數據分析提供充足的樣本。例如，在 ETH London 上，我主要做了兩件事：一是簡化教程，我們的 Bounty 主要關注應用創新，因此我希望參賽者不要花費太多時間在集成我們的代碼上。我直接展示了接口代碼和返回數據，讓集成過程更直觀、更簡單。二是，我會在每天 1 點到 2 點之間巡視會場，了解開發者的進展情況，同時推廣我們的獎金賞金任務。我發現，在凌晨 1 點到 3 點這段時間是參賽者相對空閒的時段，因為大家在高強度工作後會有一段休息時間，這是與他們交流的最佳時機。

基於我的經驗和實踐，最終的反響非常積極。共有 12 個項目接入了我們的模型 API，這遠超出了我們的預期。在 hackathon 中吸引參與者在某種程度上類似於地推活動，特別是在這種高密度的開發者集結場合，利用評委的身份與開發者進行深入交流，推廣我們的獎金賞金任務和產品，並協助他們解決問題，這有助於進一步構建深厚的關係。這次的一個 compliment：“Thanks Tim, definitely the only one stayed up with us during the battle, thanks for the support”。這讓我感到自己所付出的努力是值得的。

活動，workshop 和 AMA#

先聊聊參會，今年我參與的各種活動和會議，時常感覺自己才是那個 BD。我這一年的經歷告訴我，能夠真正吸引開發者參與的活動並不多，開發還是得去 hackathon 前後尋找。因此，針對性的推廣或加入特定的小型群體成為了關鍵。在這方面，ElectricCapital 的 Developer Report 對我幫助極大，它像是 DevRel 領域的聖經，為我們提供了對開發者生態的深入分析。通過這份報告，我們可以清晰地了解當前開發者社群的狀況。當然，從開源的視角來看，如果項目本身不是開源的，這些分析也就失去了意義。

總體來說，組織和參與活動、workshop 和 AMA 是一項頗具挑戰的工作。我需要不斷思考如何進行有效溝通，確保參與者能迅速理解我們的工作內容。在 AMA 上，快速記錄嘉賓的發言是必不可少的，每輪回答我會去 echo 一下，提高觀眾對嘉賓回答的記憶。Workshop 的準備則類似於教師的備課，要深思熟慮如何教學和講解。開發者的需求各異，因此在構建優秀的開發者社區時，並不存在一成不變的答案。只有通過不斷的嘗試、接觸和激發討論，才能逐步建立起社群。沒有快速建立社區的捷徑，一切都需要時間和持續的努力。但可以肯定的是，持續舉辦活動和工作坊絕對能展現我們的努力，並有效吸引開發者的參與。

總結#

最後想說 DevRel 也太複雜了，真的痛並快樂著。希望開發者能變得越來越多，也希望我們能吸引更多開發者入圈。這裡主要是從項目方的角度出發，結合我看到的，我做的去聊。其實還有純開發者社區的做法，這塊我就不太熟悉了。

timtimtim