通常開源專案需要面對長期維護的問題，而長期維護需要人力（開發者）物力（伺服器與基礎建設），個人開發者來說是個負擔。有些專案會有企業贊助，有些專案則是替用戶提供顧問與服務來收費維持。 這期選了 Bear 修改授權的新聞，也因為這則新聞，順道看了 Sentry 的授權模式。我們都希望擁有健康的開發生態，而授權條款很大程度左右了這點。 🗞️ 熱門新聞 Bear changes license to Elastic License Blog 平台工具 Bear 修改授權，原本是 MIT，現在改用 Elastic License。 看開發者的說法，原因是有人搭便車，fork 完直接部署成服務賣錢。開源不是免費勞工，這樣確實有點過分。Elastic License 的差別是不准以託管方式提供服務，算是補上這個洞。 相對 AGPL 來講，有時這種個人開發的小型專案，也不追求產業影響力，直接用 EL
Go
對分散式系統來說，消息的可靠性非常重要，想想一個金融應用的場景，如果在支付時，消息遺失了，或是重複遞送了，都會造成使用者的困擾。當我們在系統中引入消息隊列時，我們同時引入了複雜度，這意思是，系統的「處理消息」跟你想的不一定是同一件事。從可靠性的角度來看，「處理消息」的語義可以分為三個層次，第一層是「最多一次」，當你請系統處理消息時，它會幫你進行，但最多一次，並且不保證是否完成；第二層是「最少一次」，系統會幫你處理消息，而且附帶必要的錯誤處理，確保消息至少被完成一次；第三層是「準確一次」，意指消息不多不少，恰恰好被準確處理並完成了一次。 當試著從語言學的角度來看待系統時，我們才能規劃出系統的整體面貌。儘管「準確處理一次」有最佳的可靠性，但因為其處理成本，降低了系統整體的吞吐量。在〈Starbucks Does Not Use Two-Phase Commit〉一文中，Gregor Hohpe 精確描繪了星巴克的異步系統。收銀員收費後，
Go
這幾年隨著物聯網(IoT)越喊越熱，MQTT 這套通訊協定也越來越常聽人提起。物聯網的核心精神是將終端數據傳輸到網路，網路中的運算單元在分析這些數據後，可以將它轉化為使用者想要的應用。在網路中，數據是用通訊協定來交換，而常見的通訊協定 HTTP 結構相對複雜，傳輸成本較高，也更要求終端裝置的效能，而且 HTTP 採用輪詢(Polling)機制來取得資料，需要客戶端頻繁跟裝置拉取訊息，不適合 IoT 的應用；相對的，MQTT 輕量、採用發佈/訂閱模式，更適合 IoT 的傳輸需求。 最常見的 MQTT 工具是由 Eclipse Foundation 維護的 mosquitto，相關工具也都有開源。本文會講解如何使用 Golang 的 mqtt 套件，搭配 mosquitto 的中間人 Broker 服務，