收拾行李搬家去:從 Medium 到 Ghost

收拾行李搬家去:從 Medium 到 Ghost

想搬家想很久,連身邊的朋友都搬完了,我還沒動工。

原因是我懶,我討厭麻煩,每次有人問我吃什麼,我都回答麥當勞。搬家是一件麻煩事,我已經有一份很讚的工作了,全副精神都放在工作上,偶爾才會想起來,反正家什麼時候都能搬,一點也不急,有什麼好急的呢對吧。這樣一拖,就拖到現在。

繼續用 Medium 不好嗎?

跟男女朋友分手一樣,通常被問到:「對方不好嗎?」得到回答是:「也沒有不好啦,只是……(以下開放填空)。」

從優點開始講吧!Medium 的編輯器很棒,它是 WYSIWYG(所見即所得)類型的編輯器,能讓創作者快速發佈內容,也因為它讓內容發佈更容易了,它開始吸引一批優秀的創作者,這批創作者持續創作內容,又吸引來更多讀者,更多讀者激勵創作者產出內容,內容又再吸引讀者……這形成一個增強迴圈。Medium 還能支援多人協作,拜它時尚簡約的風格所賜,科技公司會使用 Medium 來打造品牌形象,例如我前公司的 Tech Blog 就是使用 Medium。

Medium 有很多優點,但真正吸引我的,是 Ev Williams 離開 Twitter 後,寫下的這段話

我們相信你所閱讀與書寫的內容很重要。文字可以分裂或賦權我們,激勵或使我們氣餒。在一個最轟動且膚淺的故事常勝的世界裡,我們正在建立一個獎勵深度、細膩與時間投入的系統。一個重視深思熟慮對話多於匆匆評論,重質不重量的空間。

身為一名喜愛閱讀的人,我知道空間有多重要;而身為網路世代的原生住民,我相信網路能創造對話空間。我見過好幾個例子,像是科技島讀、像是釀電影、像是 TechBridge 技術共筆部落格,像是 StarBugs Weekly 星巴哥技術週刊。

既然如此,Medium 的問題在哪?也談不上問題啦,只是……

蓋版廣告

首先,我真的、真的很討厭蓋版廣告。

有次參加技術研討會,講者是某內容平台的研發總監,在聽眾提問環節時,聽眾直接問:「你們有計畫拿掉蓋版廣告嗎?」全場一片笑聲。我相信我不是笑最大聲的。

產品原則告訴我們,好產品要以使用者為中心來打造,可是環顧四週,我們能發現許多產品無視這項法則。除了設計者自身問題外,很大原因在於「可持續性」。如果產品沒有變現管道,再好的產品也無法持續。要變現,要有商業模式,而商業模式跟產品品質關係不大。巴菲特買波克夏不是因為波克夏是優秀的紡織廠,而是因為波克夏倒閉後的帳面價值高於它的股價。

Medium 的目標是獎勵深度平台,它自然要有獎勵機制,現行的獎勵機制來自於會員訂閱。創作者創作內容,讀者付費閱讀,聽起來不錯吧?可是現實不是這樣。現實是,即使你將內容無償開放給所有人,但讀者如果沒有 Medium 帳號,他照樣會看到擋住半個版面的付費文案。這是 Medium 的第一道牆:平台帳號。

Medium 的蓋版廣告

所見一切皆要付費

那麼,只要讀者有註冊,應該看不到蓋版廣告了吧?是沒錯,可是第二道牆出現了:付費牆,想閱讀的內容都在牆後,要看請買會員資格。本來這不算問題,大家各取所需嘛,想變現的設付費牆,不想花錢的可以只看免費內容。問題在於,因為營收來自付費牆,Medium 自然會想推薦付費內容,要是內容沒設付費牆,反而會降低能見度。

讀者願意付費嗎?這是個好問題。依照經驗,如果內容有價值,讀者的確願意付費給創作者,但這不代表讀者願意付費給平台。兩者的獎勵對象不同。Medium 嘗試以平台為單位,對「空間」收費,可是對讀者來說,值得他們付費的「空間」不是平台,而是特定的出版物(Publication)。當讀者不願意付費給平台,又在推薦欄看到整排付費內容,體驗可想而知有多糟糕。

推薦文章大多設有付費牆

你的內容不是你的內容

平台降低內部曝光還在其次,只要搜尋引擎能替內容帶來流量,你還是很有機會被看見。然而,這關係到網站權威性(Domain Authority)的問題,網站權威性可以當成搜尋引擎對各網站的信譽評分,如果網站常產出優質內容,常被人引用,網頁體驗核心指標(Core Vitals)也表現不錯,就會有相對高分的網站權威性,自然也更受搜尋引擎青睞。

假設我在經營個人網站,需要建立網站權威性,最快的方式是什麼?就是讓高分網站放上我的連結,可以想成有信譽的人幫你背書,你也會跟著有信譽。通常這件事不太容易,華盛頓郵報會放上你的部落格連結嗎?想也知道不可能。但如果高分網站是 UGC(使用者生成內容)的網站,例如 Medium,這件事就變得輕而易舉,開個帳號寫篇貼滿連結的文章發佈即可。

Medium 在 ahrefs 有高分的 Domain Rating

如果網站充斥這類低品質的內容,就會導致網站權威性下降,最終生態系崩壞。為了維護自身網站權威性,Medium 不得不主動汰除低品質內容,告訴搜尋引擎別索引它們。問題來了,你以為低品質內容是具有大量連結的內容嗎?錯,在 2021 年的風波中,Medium 無預警封鎖大量網頁,而官方說明

隨著新系統的推出,作為創作者,你可能需要一些時間才能成為 Medium 網絡中受信任的一員,並達到被索引的門檻,但如果你的故事符合我們的基本品質標準,它們將最終出現在外部和原生的搜尋索引中。

Medium 說你低品質你就是低品質,假設你是一名受到 Medium 信賴的創作者,恭喜你,你的內容可以被 Google 看見,而假設你是一名新來乍到的創作者,你可能得等上幾個月,才有機會在 Google 搜尋看見自己的創作。好消息是:因為太具爭議了,Medium 後續有放寬限制;壞消息是:你不知道有沒有下次。

透過一道又一道的層層封鎖,Medium 將內容鎖在站內。究其原因,我認為是 Medium 的商業模式限制了它達成願景的能力,它並沒有走向開放與交流,而是走向封閉與營利。我沒打算將論述簡化成「Ev Williams 為了利潤背棄承諾」(聽起來像是八點檔的台詞),事情複雜得多,系統環環相扣,沒人能在開始就看見全貌。

要搬去哪呢?

既然 Medium 不適合長期經營,還有哪些選擇?先看看需求,我最在意的是內容掌控度,具體來說,我希望內容可以放到自己的網域,這樣要搬家時,可以把網站權威性一起帶走,這需要自己架站或使用的服務支援 Custom Domain;其次,我需要 WYSIWYG 的編輯器,讓我能輕易發佈內容;再來,我想知道網站的訪客有誰,都是從哪些管道進來的,因此需要網站能支援 Google Analytics 或者同等級的追蹤服務;最後,如果可以,我希望佈景主題(Theme)可以客製。

WordPress

最先想到的是 WordPress,最先淘汰的也是 WordPress。

起因於 WordPress 的開發商 Automattic 跟服務供應商 WP Engine 的爭執。Automattic 批評 WP Engine 使用 WP 商標,容易讓外界誤認兩家為同一公司,並聲稱 WP Engine 對 WordPress 的貢獻過低,它要求 WP Engine 付出 8% 的營收取得授權,或是用這 8% 的營收支付員工薪水,並讓員工們貢獻 WordPress 專案。

關於這件事,我的觀點跟 DHH 一致

Automattic 要求 WP Engine 提供 8%的收入,理由是他們「對 WordPress 的回饋不夠」,這是對一般開源理念及 GPL 授權條款的肆意違反。Automattic 完全越界了,對開源世界的潛在傷害遠遠超出 WordPress 範疇。……

……沒有任何主要授權條款會說類似「它是免費的,但只有在專案擁有者認為你太成功時,你才必須支付營收的 8%來支持專案」這種話。這是一個完全瘋狂且任意的標準,基於惡意規則,而非法律。

假設我使用 DigitalOcean 託管的 WordPress 服務,誰知道哪天 Automattic 會不會阻擋 DigitalOcean 對 WordPress.org 的網域存取?到時,我在 DigitalOcean 的網站將會無法更新,曝露在風險中。這種拿使用者綁架對手的行為,真的讓我無法認同。

Eleventy

Eleventy 是個超棒的靜態網站生成器(Static Site Generator),搭配 GitHub Pages,可以在無需管理伺服器的情況下,得到優秀的網頁體驗核心指標。它的生態系也算活躍,你可以在 Eleventy Themes 中找到幾十個免費模板。

Eleventy 主要的問題是編輯器,因為它是從 Markdown 格式生成,我通常都用 VSCode 來編輯,雖然平常工作也是用 VSCode,但能不能看見發佈的最終樣貌,甚至能不能支援應用場景,對我來說還是有差。

Substack

Substack 跟 Medium 同樣是內容創作平台,但他們的商業模式不同。Substack 的收費是採抽成,如果創作者有開訂閱,Substack 會從收入中抽取 10% 作為平台費。這樣的商業模式讓 Substack 跟創作者的利益一致,而讀者付款也有明確的獎勵對象。

Substack 支援 Custom Domain 跟 Google Analytics,但會收取 50 美金的一次性費用,如果用年費角度來看還算合理,平均一個月不到 5 美金。它的問題在幾個方面,從技術指標來看,Substack 在我瀏覽器的 Lighthouse Performance 僅有 44/100,代表來自搜尋引擎的流量可能不會太理想,而 Semrush 的數據也反映了這點,來自 Google 搜尋的流量僅有 10.72%。

Substack 的產品設計也稱不上完美,體驗起來像是行走在到處有人發傳單的人行道上,三不五時問你要不要訂閱。而等到你想回到自己的創作空間時,卻發現自己找不到入口。Medium 只要點開右上角的帳號菜單,出現的都是跟自己有關的選項,而 Substack 點開後的 Home 卻是 Substack 的首頁,至於創作入口,它放在視窗側欄下方,導致你游標需要不斷在畫面右上左下來回折返跑。

Ghost

Ghost 的使命是「幫助創造創作者經濟。」

這點也反映在他們的商業模式中,Ghost 的收入來自平台託管費,而非會員資格或抽成,對頭部創作者來說,這當然更為理想--抽成是頭部創作者跟平台間最大的分歧,當創作者有足夠的會員後,通常會反過來跟平台談降低抽成,否則就要另起爐灶(經紀公司的典型模式)。藉由專注在工具上,Ghost 避開了商業上的爭執,這固然削弱了他們的產業影響力,卻也讓他們有更多空間,將產品打造得更為盡善盡美。

Ghost 是開源軟體,你可以完全掌握自己的內容,從 WYSIWYG 編輯器 Koenig 到設定 Google Analytics 到佈景主題,都能依照創作者的意願設計。它的問題在於,如果你要自建,需要具備有基礎程式能力,但這對我沒差。假設真的不懂程式,它也有全託管方案。它幾乎提供了我要的所有東西,而沒有的部分,我也能使用插件自行添加。

要怎麼搬?

首先自然是從 Medium 匯出內容,打開 Medium 頁面,點選右上角帳號菜單 > Settings > Security & apps,按下 Download your information 後,等待 Medium 將資料送到你的信箱

接著來架 Ghost,我選擇用 Hostinger 的 Ghost VPS 託管服務,兩年 107.78 美金,付完後就有一台 Ghost 可以用了。但後來發現好像可以用 DigitalOcean 的 Droplets,每個月 4 美金起,而且有 100 美金的額度可以抵,等於開始兩年都不用付錢。如果覺得管理伺服器太麻煩,直接用 Ghost Pro 的全託管方案也行,每個月 11 美金,自動幫你維護升級。

Ghost 有設計 Medium 的搬家工具,在 General settings 的 Import/Export 中,可以看到 Migration tools 圖卡,依照指示操作,把載好的 Medium 檔案上傳。要注意搬完後,圖片仍然是 Medium 的 hotlink,如果哪天 Medium 倒閉,在 Ghost 中的圖片也會跟著不見。因為圖片不多,我是手動一張一張替換,但這塊應該能寫個爬蟲來自動化。

搬完內容搬流量,記得把 Medium 文章的 Canonical Link 指向 Ghost,這是用來告訴 Google,如果在網路上找到兩篇一模一樣的文章,哪篇才是應該索引的正版。新網域的網站權威度絕對沒有 Medium 高,如果沒設 Canonical,你的網站會被 Google 當成內容農場。雖然有次跟 SEO 專家聊到這題,人家說 Google 有時也不看 Canonical,但有設有保佑, 至少多了一個連結,讓 Google 知道有新網站存在。

最後記得公告親朋好友,讓大家知道你搬家了。保持平常心,等流量慢慢回來。剛開始會不習慣,因為少了平台加持,流量會受到衝擊,但這些流量都是你的,內容也都是你的,不用煩惱哪天平台找麻煩。

小結:看不見的引力

我可嘆地仍如五月那樣傾向古典而缺少現代性地相信必然性的存在——《其後》

事後想來,是否在一開始,Medium 已經走上現在這條路,只是都沒人察覺?這話當然過於武斷了。這段時間內有無數陰錯陽差與巧合,Medium 也在編輯台與平台間搖擺不定,然而商業模式有著巨大的引力,會一再將 Medium 吸回原來的道路上。Ev Williams 在 2022 年卸任執行長,改由 Tony Stubblebine 接手。我們未來仍然有機會看到一個空間,真正達成 Ev Williams 的理想,只是不一定是 Medium。

差點忘了講,這篇文章會同時在兩個平台發表,我的新家位置是 https://blog.kenwsc.com,如果想要繼續關注我的文章,可以訂閱 RSS https://blog.kenwsc.com/rss/,Readwise 或 Feedly 都是不錯的訂閱器。

Reference

Read more

OpenTelemetry 的可觀察性工程:以 Sentry 為例

OpenTelemetry 的可觀察性工程:以 Sentry 為例

點進 OpenTelemetry 的官方文件,它最先映入眼中的句子是「什麼是 OpenTelemetry」。例如,它是套可觀察性框架,用於檢測、蒐集與導出遙測數據;它是開源且供應商中立,能搭配其他的開源工具,像 Jaeger 或 Prometheus;它能將應用程式與系統儀表化,無關是用 Go 還是 .NET 開發,也無關部署在 AWS 還是 GCP 上。 但是身為一名開發者,當下我們想的是:「公司常開發一些沒人要用的功能,聽說 OpenTelemetry 可以提高可觀察性,也許我們應該放棄開發功能,轉頭建立更好的開發環境。」「AWS 常常要不到需要的數據,也許我們應該改用另一套工具,像是 OpenTelemetry,來解決這件事。」我們想像 OpenTelemetry 「應該」要能解決目前面臨到的一些問題,就像在技術的鏡像中尋找願望一樣。 如果已經有在用 Sentry,還需要導入 OpenTelemetry

By Ken Chen
標準化之路:Go 1.23 中的迭代器

標準化之路:Go 1.23 中的迭代器

Ian Lance Taylor 在 "Range Over Function Types" 這篇文章聊到 iterator 誕生的原因。如果我們有兩個容器,稱為集合(Set),想要取得這兩個集合中的不重複元素,加到新的集合中形成聯集,我們可以寫個 Union 函式來執行 // Set holds a set of elements. type Set[E comparable] struct { m map[E]struct{} } // Union returns the union of two sets. func Union[E comparable](s1, s2 *Set[

By Ken Chen
OAuth 2.0 的身份認證:OpenID Connect

OAuth 2.0 的身份認證:OpenID Connect

OAuth 2 讓網路服務可以存取第三方的受保護資源,因此,有些開發者會進一步利用 OAuth 2 來進行使用者認證。但這中間存在著一些語義落差,因為 OAuth 2 當初設計目的是「授權」而不是「認證」,兩者關注的焦點會有些不同。OpenID Connect 是基於 OAuth 2 的一套身份認證協定,讓開發者可以在 OAuth 2 授權的基礎上,再加入標準的認證流程。在這篇文章中,我會說明授權跟認證的場景有何差異,並講解 OpenID Connect 如何滿足認證需求。 因為 OpenID Connect 是建構在 OAuth 2 的基礎上,我會假設這篇文章的讀者已經知道 OAuth 2 的組件與流程,如果你不熟悉,可以先閱讀另外兩篇文章 * OAuth 2.0:

By Ken Chen
更好的選擇?用 JWT 取代 Session 的風險

更好的選擇?用 JWT 取代 Session 的風險

因為 HTTP 是無狀態協定,為了保持使用者狀態,需要後端實作 Session 管理機制。在早期方式中,使用者狀態會跟 HTTP 的 Cookie 綁定,等到有需要的時候,例如驗證身份,就能使用 Cookie 內的資訊搭配後端 Session 來進行。但自從 JWT 出現後,使用者資訊可以編碼在 JWT 內,也開始有人用它來管理使用者身份。前些日子跟公司的資安團隊討論,發現 JWT 用來管理身份認證會有些風險。在這篇文章中,我會比較原本的 Session 管理跟 JWT 的差異,並說明可能的風險所在。 Session 管理 Session 是什麼意思?為什麼需要管理?我們可以從 HTTP 無狀態的特性聊起。所謂的無狀態,翻譯成白話,就是後面請求不會受前面請求的影響。想像現在有個朋友跟你借錢,

By Ken Chen