Weekly Issue 第 12 期：Bear 修改授權條款
通常開源專案需要面對長期維護的問題，而長期維護需要人力（開發者）物力（伺服器與基礎建設），個人開發者來說是個負擔。有些專案會有企業贊助，有些專案則是替用戶提供顧問與服務來收費維持。
這期選了 Bear 修改授權的新聞，也因為這則新聞，順道看了 Sentry 的授權模式。我們都希望擁有健康的開發生態，而授權條款很大程度左右了這點。
🗞️ 熱門新聞
Bear changes license to Elastic License
Blog 平台工具 Bear 修改授權，原本是 MIT，現在改用 Elastic License。
看開發者的說法，原因是有人搭便車，fork 完直接部署成服務賣錢。開源不是免費勞工，這樣確實有點過分。Elastic License 的差別是不准以託管方式提供服務，算是補上這個洞。
相對 AGPL 來講，有時這種個人開發的小型專案，也不追求產業影響力，直接用 EL 省事多了。拿人家的成果去賣錢真的說不過去。
Introducing the Functional Source License: Freedom without Free-riding
看了 Sentry 說明他們如何選擇授權，很有啟發。
開源授權最麻煩的，是如何解決搭便車問題。有些對專案沒有貢獻的人，直接拿你的專案去賺錢，這會讓開發者不願意開源，破壞開源的可持續性。Sentry 的 FSL 是兩年內不得用於競爭用途，兩年後會自動轉換成 Apache 或 MIT。
意思是 Sentry 同意你拿專案去賺錢，但要等兩年，給開發者留下合理的經濟空間。
Linux Foundation Welcomes DocumentDB to Advance Open, Developer-First NoSQL Innovation
DocumentDB 在今年稍早開源，現在進入 Linux 基金會，還有 AWS 的 DocumentDB 總監幫忙背書。
沒想到底層也是 PostgreSQL，雖然這個 DocumentDB 跟 AWS 的（應該）是不同東西，但前幾年 HN 上也是有人在猜 AWS 是不是用 PostgreSQL 當底，加上 AWS 也有貢獻該專案，也許還是有點關係？
是說我也曾經想把 mongodb 轉到 AWS DocumentDB 上呀。
✨ 科技觀點
Death by a thousand Substacks
beehiiv 的 CEO 發了篇長文〈Substack 式的凌遲〉，副標題是核心概念：「如果你不是負責賺錢的，那你就是酵母。」
本質上是批評 Substack 的商業模式，認為它們不具可持續性。Substack 多數收入都來自頭部創作者，因為他們是收抽成，這無異於逼頭部創作者跟平台談判－－如果不能拿到降低抽成，至少也拿個專人服務（我曾跟朋友開玩笑：這是唯恐別人不來跟你吵架）；與此同時，對營收沒有貢獻的長尾內容，意義在於強化品牌形象。
裡面的一些舉例有打到我，我在用他們家的產品確實會有點卡卡的，特別是 UX 與自主性，當時我解釋成「工程能力不到位」與「可能沒那麼優先」，但是拉高視角，問題會變成「那什麼是優先的事情呢？」
我對 Substack 的定位還是一個階段（跟 Medium 類似），當剛起步，需要驗證你的模式是否可行，Substack 是個好選擇，可是最好設個門檻，等營收達到後就要規劃下一步。
Thoughts on (Amazonian) Leadership
AWS 是少數我見過非常在意 Leadership Principles 的公司。
有時候我不確定，這些原則會被如何解釋。相對有把握的是，應該跟作者講的不同。
例如 Kiro，我覺得是個很有趣的產品，可是它不算是基礎元件，從基礎元件的角度來解釋「顧客至上」，聽起來跟其他公司的「顧客至上」也沒太大差別了－－當你要跟人吵架時，就說是因為顧客至上。
我猜他們的顧客至上還是比較偏電商文化？
Are people's bosses really making them use AI?
在 HN 看到一則「強迫導入」AI 的經驗分享。
儘管看起來都是個案，但也可以從個案中看到一些共同的，該說焦慮嗎？例如為什麼全公司要用同一個 ChatGPT 帳號呢？買個 Cursor 或直接用 GitHub Copilot 不好嗎？或者用資遣來推行 AI，可是公司有沒有跟 AI 顧問合作，讓導入更順利呢？
不知道。我可以理解焦慮，但把人丟到水裡，人還是不會游泳呀，組織變革也不是喊喊口號就能辦到的事。
我最喜欢的悖论
看到一則「辛普森悖論」：在分組數據中出現的趨勢，可能在合併後消失，甚至反轉。
意思是，同樣的東西，分開來看跟合起來看，會得到不同的結論。原文舉了幾個很有說服力的例子。例如 Youtube 的效能優化後，延遲時間反而增加。
看完後在想有沒有遇過類似的情境？要說的話，也是有 CDN 的 Hit Rate 拉高，但 Latency 反而變高的情況。當時的狀況是流量大增，雖然 Hit Rate 變高了，可是沒命中的流量反而變多，造成伺服器的壓力增加。這種問題真的麻煩，單純看指標不容易監測到。
Do the simplest thing that could possibly work
簡單是我很重要的一套工程原則，我對工藝的要求就是它需要簡單。
「就像許多技能一樣，真正的精通往往在於學會何時該少做，而不是多做。 」
舉個我的錯誤判斷，曾經有項任務是設計一套用戶幫助文件，我不贊成開發後端系統（這是對的），認為用個 Headless CMS 來管理，加上個自己開發的前端配上搜尋 API 應該夠用。我一直認為這是對的，直到前陣子看了 Anthropic 的方案，他們是用 Intercom。
Anthropic 的工程師不會設計系統嗎？當然不是，是因為維護 Intercom 要簡單得多，它也好用得多。但買一套方案就會讓人覺得不夠工程。
Great software design looks underwhelming
看到這段頗有感：「他說他不會讓這個候選人進入面試。在他看來，這份作業沒有展現出對各種高階語言特性的足夠理解。它太簡單了。 」
團隊在設計招募流程時，也在想是不是要找「更懂語言」的人選。以 Go 來說是問三色標示法或迭代器特性這類問題。只是那對我來說太奇怪了，有深度是一回事，熟悉很偏門的領域又是另一回事。
優秀的軟體設計應該要看起來簡單，產品設計也是。
You're Not Interviewing for the Job. You're Auditioning for the Job Title
最近在看分散式系統設計，跟朋友也聊到類似話題。
「接著，你在白板上畫滿方框、箭頭，以及至少一個多餘的 Kubernetes 叢集。無論是否需要，都加上一個訊息佇列——當然是 Kafka。 」
當時跟朋友講說，雖然我們花很多時間看 Kafka，但如果是自己的 Side Project，我只會用 Go channel 來達成類似的效果。畢竟我不用 Durable、不用處理分散式交易，我只是要開發個小工具讓我平常生活方便一點而已。
📌 工程實務
Building resilient multi-tenant systems with Amazon SQS fair queues
AWS 前陣子推出 fair queues，可以用來解決 SQS 的優先序問題。
這篇介紹寫得不錯，當某些生產者製造太多 message，會影響到同個 queue 的其他任務。通常為了解決這問題，需要替每個生產者配置一個 queue，但這樣會造成配置變得很複雜。
AWS 還有對應的指標跟 Dashboard，以後基礎建設的過渡可以更平滑了。先開 queue，再 fair queue，不行再多開新的 queue。
改天來想想其他 MQ 怎麼解同樣問題。
Everything I know about good API design
Goedecke 談他心中的優秀 API。
看完後的念頭是：「面試好像可以多問一題：你要怎麼設計 API 來防止別人惡意刷留言。」但想想現在到處是 AI，也不確定能擋到什麼程度。
以前學到一課，最好把開放 API 當成產品來看待，那跟直接給出 Internal API 是兩回事。從一家公司的 API 設計，大概也能看出他們的工程實踐到什麼程度。
當然這不代表他們的產品是成功的。反之亦然。
Permission Marketing
賽斯．高汀談「許可式行銷 」，看完有恍然大悟的感覺：
「僅僅因為我沒有抱怨，也不代表你獲得了許可。就算在你的隱私政策細則中寫明，同樣不代表那就是許可。」
以前常困惑產品行銷的界線在哪，什麼是合理的，能幫助產品成長的訊息，什麼是純粹自我感覺良好，在打擾使用者的訊息。這個原則很清楚了：只有通過明確許可的行銷訊息才是合理的（附帶個檢查方式：哪些 SaaS 會在沒有明確同意的情況下，替你打勾）。
用電子報來看的話，就是需要有 Double Opt-in 吧。