所有開發者的最大夢魘，莫過於當程式發佈之後，收到使用者或者系統回報回來的各種程式錯誤，卻找不到足夠的脈絡去判斷到底是怎樣的使用情境，或是哪一段程式碼導致程式異常；此外，當大量錯誤訊息湧入開發者的收件匣時，怎麼判斷處理錯誤的優先順序，也讓人傷透腦筋。
若用真實情況做對比，就像是某間診所突然湧入大量的病患，但每個病患都只說自己感覺身體不舒服，醫生也沒有足夠的儀器與驗證機制來判斷哪名患者應該被優先醫治，以及如何有效醫治病患。若無法快速找出程式錯誤的源頭並判斷處置的優先順序，不僅會讓使用者對產品留下不好的印象，開發者也必須花費很多心力找出程式錯誤的來源，進而耽擱了產品開發的時程。幸好，隨著軟體開發的產業日漸茁壯，有軟體公司開始投入能即時監測、記錄並彙整程式錯誤的軟體服務。
Sentry：百萬開發者都愛用的程式錯誤監控服務
在眾多軟體監測的服務裡，成立於 2012 年的程式錯誤監控服務 Sentry 則獲得不少開發者的青睞。Sentry 目前共支援 Python、JavaScript、.NET 在內等數十種主流的程式語言或框架，在網頁端、行動端、物聯網、遊戲等前端或後端的開發環境中皆能部署，也能跟像是 Slack、Trello、Datadog 等協作與資料分析工具進行整合。更重要的是，Sentry 的系統會可以將依照專案與錯誤類型，將錯誤回報進行整理與分組，以避免大量的錯誤回報資訊淹沒了開發者的信箱，導致開發者不知從何開始修改錯誤。Sentry 最獨樹一格的地方在於他們的核心服務是以 BSL 1.1（Business Source License 1.1）的條款開源釋出。開發者只要遵循相關條款，就能依自己的需求對 Sentry 的程式碼進行修改並部署到自己的主機上，不需要使用 Sentry 的付費 SaaS 服務來監控程式錯誤。（關於 BSL 1.1 的相關使用條款，會在文章後半部說明）
Sentry 表示目前已有上百萬名的開發者以及多達 50,000 間企業在使用他們的服務，其中包含 Microsoft、Dropbox、Paypal、Uber 和 Symantec 等知名企業。在 2019 年一年內，就累積偵測並管理超過 5,000 億個程式錯誤回報。共同創辦人暨 CTO David Cramer 表示，Sentry 目前有超過 18,000 名付費用戶，也是同業中擁有最多付費用戶的服務。在 2019 年的 9 月，Sentry 獲得由 Accel 與 New Enterprise Associates 所領投的 C 輪募資，總募資金額已達到 6,650 萬美元（約新台幣 19.95 億元）。
從 A 輪就開始投資 Sentry 的 Accel 合夥人 Daniel Levine 表示：「Sentry 的領先地位年復一年證明了他們能夠看清科技的趨勢，並且更重要的是，為市場帶來開發者願意為之付錢的產品。我們（Accel）已看著 Sentry 達成並維持他們在錯誤監測的領先地位，我們也很高興能協助他們重新發明出應用程式性能管理系統（APM，Application Performance Monitoring/Management ）來顛覆市場規範，並為接下來以 app 導向的世代裡，為消費者帶來更好的關鍵工具。」[1]
兩度退學、自學程式的共同創辦人 David Cramer
Sentry 的共同創辦人暨 CEO David Cramer，有個很不尋常的成長歷程：他曾經分別從高中與大學退學，並非因為學校課業成績太差或是家裡無法負擔學費，又或者跟許多矽谷名人一樣，為了創業而放棄學業。他純粹只是覺得課堂上教的內容無法滿足他的求知慾，因此不想交作業，也不願意正常出席，當然也不會得到什麼漂亮的成績。David Cramer 自小所兼備的聰明與叛逆，從他某次訪談中所分享的故事就可以窺其一二。[2]
David Cramer 在從高中退學之前，曾選修過一門資訊課，課堂的規定之一就是要完成指定數量的作業。當時的他已經具備基礎電腦常識，也開始在網路上用 PHP 寫些程式，所以 Cramer 很快地就解決像是 Word、Excel 與 FrontPage 等相對簡易的課程，並達到課堂規定的作業數量門檻。在達標之後，他因著對電腦的熱愛，更進一步選讀 C++ 的課程，甚至把整本教科書讀完，大幅超過指定的範圍內容。雖然他在程式學習的表現驚人，Cramer 最終在這堂課仍只獲得 D 的評比：因為他都不出席上課，只全然沉浸在解題的樂趣裡面。從此之後他也就對正規體系心灰意冷，並向家人表示希望在家自學。
除此之外，他展開開發者生涯的經歷也十分特殊：他的第一份正職其實是某個遊戲入口網站的內容編輯，當時網路遊戲《魔獸世界》（World of Warcraft）才剛推出，他負責撰寫相關的攻略。但後來因為他有自學程式的經驗，所以也就開始嘗試協助同事直接從遊戲的程式碼中找出相關資料，以提供情報給讀者。後來也因為這樣的經驗，他在 19 歲的時候就以首席開發者的身份加入一間提供《魔獸世界》攻略的公司，並在那邊負責打造蒐集攻略、模組等資料庫的網站。
從 80 行的開源專案，到服務百萬開發者的開源服務
就跟過去曾介紹過的一站式 API 開發平台 Postman 一樣，Sentry 最一開始也是兩位創辦人 David Cramer 與 Chris Jennings，試圖解決自己在開發中所遭遇的問題而開發出的開源專案。當時任職於留言整合管理服務 Disqus 的 David Cramer，不只在工作上會用到 Django （以 Python 語言寫成的開源網頁框架）進行開發，同時也是 Django 與 Python 開源社群活躍的一員，在 2013 年曾造訪台灣擔任「PyCon Taiwan 2013」的主題講者。
會讓他們想起心動念開發 Sentry，是因為當時 Disqus 的程式品質管理不佳，時常發生程式錯誤，但 Django 的系統預設會每發生一次錯誤就寄一封信通知工程師，沒過多久就把 Chris Jennings 的電子信箱塞爆了。為了解決這項困擾，他們開發出原始程式碼不到一百行的初版 Sentry 套件，只要將 Sentry 嵌入在原先以 Django 寫成的程式中，它會統整相同類型的程式錯誤並統一寄給開發者，以減少電子信箱塞滿錯誤通知的困擾。[3]
因為當時並沒有同類型的 Python 套件，Sentry 很快地受到開發者的熱烈歡迎，也因此有在網路部署服務 Heroku 工作的網友，建議他們可以將 Sentry 製作成擴充程式（add-on）上架到 Heroku 並向使用者收費。不過，為了要在 Heroku 上架，Sentry 的產品形式就得從現有的嵌入式套件轉變為雲端服務。
經過近一年的努力，雲端服務版的 Sentry 在 2012 年二月於 Heroku 上架，也吸引到越來越多開發者願意付費支持，在收入上獲得非常穩定的成長。雖然 Sentry 從此刻起就開始提供收費的雲端服務，但是他們仍維持開源的本質，仍讓開發者可以自行部署在自己的伺服器上。隨著越來越多開發者使用 Sentry 進行程式錯誤的偵測與回報，也開始有各程式語言專長的開發者，協助 Sentry 持續優化並增加對各種程式語言的偵錯回報整理。
兩位創辦人表示，Sentry 之所以能維持如此開放的態度，有很大一部分是因為兩位創辦人在當時都有正職工作，並不需要仰賴 Sentry 的快速成長以支持基本生計。Cramer 表示，當時有約九成的開發者選擇自行部署 Sentry，雖然 Sentry 無法從這些使用者上獲得營收，但卻能確保 Sentry 的開發社群活絡。而且當這些使用者的專案逐漸壯大，需要監測並處理更大量的程式錯誤時，他們也會自然而然會優先考慮使用 Sentry 的付費雲端服務。直到 2015 年，兩位創辦人才決定要將這項副業變成他們的全職工作，並開始向創投募資並積極招募人員，也逐步拓展 Sentry 在程式錯誤監測上能支援的程式語言與開發環境的數量。
商業開源的 SaaS 新創要如何對抗雲端服務的歌利亞？
雖然兩位創辦人決定辭掉穩定的正職，把 Sentry 從業餘專案變成追求營利的新創，但他們仍秉持著開源的精神，在 Sentry 尋求企業營收成長的同時，仍把大部分的程式碼開放在 GitHub 上，並混合使用 Apache–2.0、MIT 和 BSD 3-Clause 的開源授權規範。而且，Sentry 與許多只開放核心（open-core）的產品不同，其收費的雲端版跟提供開發者自行部署的版本的程式碼內容是完全相同的。隨著越來越多服務部署在雲端上，AWS 等雲端服務供應商，卻也開始會將這些開源的開發者工具，直接（或者透過 Fork 複製成新專案的方式）整合至雲端服務中，並使其成為所提供的附加服務之一。如此一來，雖然雲端服務供應商能為開發者提供更全面的服務，也這舉動也不違反開源的相關條款，但是像 Sentry 這些實際為開發者工具做出貢獻的公司，卻無法從雲端服務供應商手上獲得任何營收。在之前像是開源的資料搜尋引擎 Elasticsearch、開源資料庫管理系統 CockroachDB 等，也都曾吃過雲端服務供應商的虧，也進而必須採取反擊的策略。
例如 CockroachDB 就在 2019 年 7 月將他們的授權條款，從原先的 Apache Public License 2.0 改採用 BSL1.1（Business Standard License）。這個由 MySQL 關連式資料庫管理系統 MariaDB 公司所創立的授權條款，針對商業開源的專案提出了更完整的保護。雖然有部分的開源支持者認為，BSL1.1 的部分規範並無遵從開放原始碼促進會（Open Source Initiative）所提出的開源定義，因此不該被稱為「開源授權條款」。但根據 MariaDB 的說法，BSL 的目的在於：「希望能在經營一間財務健全的軟體公司，與支持開源的原始信念之中找出一個平衡。譬如讓所有的軟體開發者都能成為創新循環的一部分：在一開始就提供完整的原始碼，讓他們可以自由存取，進而修改並重新部署軟體。我們的最終目標是希望 BSL 能創造出更多的開源軟體。」[4]
與主流的開源條款相同，採用 BSL1.1 授權條款的專案仍開放使用者自由複製、修改、分叉（Fork）或發佈。但這條款嚴格規定到，只要在專案中有使用到 BSL1.1 規範的開源專案的公司或個人，就會需要在專案釋出之後的固定時間後（CockroachDB 是規定 3 年後），將此專案以 Apache 2.0 的條款開源釋出。如果不想要將專案以開源釋出的話，就必須支付授權費用給開發專案的原公司。BSL1.1 試圖讓商業的開源公司能夠遏止雲端服務供應商在不支付費用的情況下，「合法」將他們所開發的工具變成雲端服務的一部分。要保障這些商業開源公司在獲得他們應得的收益的同時，也讓他們能持續對開源社群做出貢獻。
Sentry CTO：過去的開源授權模式，已無法完全涵蓋今日的使用方式
CTO David Cramer 表示[5]，其實在創辦 Sentry 的前幾年，他們就有想過調整授權條款，從原先混用多種開源授權條款的狀況調整為統一採用 Apache 2.0，讓使用者不必為此傷透腦筋。但後來，Sentry 開始遇到其他公司直接剽竊產品程式碼，然後大言不慚地說：「因為 Sentry 是開源的專案，所以我們可以這麼做。」再加上 Elasticsearch、CockroachDB 等開源商業公司的前車之鑑，他們在 2019 年的 11 月決定要跟隨 CockroachDB 的腳步，將 Sentry 改為 BSL1.1 的授權。
其共同創辦人 David Cramer 也因此寫下〈重新授權 Sentry〉（Re-Licensing Sentry）這篇文章，來解釋 Sentry 之所以改採用 BSL1.1，而非其他受原始碼促進會所認可的「開源授權條款」的原因是：「過去的授權模式，像是『開放核心』、GPL 或者像是 BSD 跟 Apache–2.0 的寬容式的授權，已無法完全涵蓋今日開源軟體被散佈或使用的方式。我們想要探索出一個替代方案，一個能夠讓人們輕易採用並公開散佈我們的軟體，但同時能防止競爭者重新打包我們的嘔心瀝血之作，並威脅到 Sentry 的未來發展。」
另一個歌利亞的威脅：Google
除了面對像是 AWS 等雲端服務供應商的威脅之外，另一個可能對 Sentry 造成威脅的科技巨頭則非 Google 莫屬。Google 旗下的 Firebase，是一項後端支援平台服務 BaaS（Backend as a Services），能幫助開發者其產品在跨平台蒐集到的各種資料，統整在 Firebase 當中，其中當然也包含 Sentry 的產品主力：程式錯誤的蒐集與統整。除此之外，市面上也有像是 Instabug、New Relic 等同樣有提供類似服務的公司。
Sentry 目前的優勢，仍在於他們所支援的開發環境與語言仍是同類型產品之中最多，且其秉持開源的產品服務也讓開發者更放心無論是透過雲端服務或者自行架設的 Sentry 來監控軟體。並且隨著未來有越來越多的產業與產品，都必須透過程式與網路相互連結時，如何即時追蹤並修改程式的錯誤，就會成為越來企業與開發者所關注的焦點。而 Sentry 或許也有機會乘著這波浪潮崛起，為更多的開發者與企業把關程式品質。
參考資料：
本文依 CC 創用姓名標示 - 非商業性 - 相同方式分享 4.0 國際釋出