開源與否？
我們想分享我們對開源的想法，以及我們應該如何授權我們的程式碼。在 Meili，我們正在用 Rust 🦀 建立一個即時搜尋引擎，並且我們想要開源它。
我們想分享我們對開源的想法，以及我們應該如何授權我們的程式碼。這對我們來說是全新的，而且我們仍在找出最佳解決方案和機會，因此如果您有任何閱讀建議，請隨時告訴我們。
快速提醒：在 Meili，我們正在用 Rust 🦀 建立一個即時搜尋引擎，並且我們想要開源它。我們仍在思考適合我們的商業計劃，我們也可能會寫關於這方面的文章，但今天的主題是授權！
為什麼我們選擇開源？
我們認為每個應用程式都應該擁有一個像樣的搜尋引擎。這意味著搜尋引擎技術應該成為一種商品。我們在 Algolia (非常適合開發者使用但屬專有) 和 Elastic Search (難以設定即時搜尋) 之間找到了平衡點。
我們認為，如果您想成為您領域的標準技術，您應該開源，這樣您就可以與使用它的人一起建構您的功能，並獲得對程式碼的信任。此外，因為我們是很酷的開發人員，我們使用了許多開源程式碼，並且我們想透過貢獻開源和分享我們的專案來回饋社會。
什麼是開源？
開源很複雜，如果您問兩個人對開源的定義，您可能會發現開源有很多種定義。 Steve Klabnik 寫了一篇非常有趣的部落格文章，內容關於開源核心的文化戰爭，我們從中了解了開源的歷史，以及為什麼人們會為其定義爭論不休。
最初，有自由軟體基金會 (Free Software Foundation)，該基金會於 1985 年成立。FSF 由 Richard Stallman 創立，旨在支持 GNU 專案和自由軟體的概念：軟體應該可以自由使用、自由複製和自由再散佈。然而，「自由」一詞非常受限制。對於 FSF 來說，自由軟體必須採用「拷貝左」授權。「拷貝左」意味著所有從其衍生的作品也必須採用「拷貝左」。我們稱這種授權為「繼承」或「污染」授權，我們很快就理解這種授權可能會嚇跑企業。
然後出現了開源促進會 (Open Source Initiative)，這是一個於 1998 年成立的非營利組織。Eric S. Raymond 和 Bruce Perens 撰寫了開源定義，其中規範了限制較少的授權 (MIT、Apache、BSDs 等)。這些授權都要求註明您正在使用的軟體作者，但您正在建構的內容可以採用任何其他授權。此開源定義的目標之一是更「適合商業」，因為「自由」一詞可能會嚇跑公司，並且透過更友善的名稱和限制較少的授權，您可以鼓勵公司投資並參與開源。
為了說明差異，我們可以採用兩個基於 Unix 的作業系統：一邊是 Linux 核心，它採用 GPLv2 (「拷貝左」) 授權，這也是為什麼基於 Linux 的 Android 是開源的。另一方面，有 Berkeley Software Distribution (BSD)，它採用 BSD 授權，它最著名的分支是 iOS 和 Mac OS，它們是專有且私有的。
這些是現今開源的定義，問題是
- 每個人對開源的定義都不一致，因為每個人都有自己對開源的意識形態
- 每個人都不遵守相同的規則：有些公司在一些不明的 FTP 上發布其 GPL 授權的專案，而有些公司則在 GitHub 上公開發布其程式碼，但沒有 OSI 核准的授權。對您來說，什麼是開源？
現今的開源
正如您在過去幾個月所讀到的，一些「開源」專案由於相同的原因而變更了授權。我們認為 MongoDB 解釋得非常好
對於開源專案來說，這是一個絕佳的機會，有可能促進新一波偉大的開源伺服器端軟體。然而，現實情況是，一旦開源專案變得有趣，大型雲端供應商就太容易捕捉所有價值，但卻沒有回饋給社群。
而且他們並非唯一擔心這種情況的專案。
例如，Redis 正在以其自己的授權授權其部分 Redis 模組，即 Redis 來源可用授權。他們之前是在 Apache 授權上使用 Commons Clause。Commons Clause 在像 Apache 這樣現有的授權之上增加了一些關於商業發行的限制。但他們為了避免混淆而更改了它；人們不確定它是否為開源。
Confluent 也變更了其授權，他們選擇從 Apache 轉為建立 Confluent 社群授權，因為他們也害怕一些大型雲端公司。
開源與 Meili
重點不是關於大型公司是否應該對開源做出更多或不同的貢獻，而是開源正在發展，我們需要一個新的定義，一個新的術語來聚集在一起並知道我們正在談論什麼。
也許我們需要標籤來定義和框住我們作為公司所支持的意識形態？也許我們需要一個專利式的系統，聲明您作為公司發布的每個程式碼，將在您編寫程式碼 3 年後採用 MIT 授權或任何其他授權。這樣一來，您可以在一段時間內將您的程式碼商業化，同時也能公開您的程式碼？
在 Meili，我們對這些問題還沒有明確的願景，但我們正在深入思考。我們希望我們的程式碼可以供任何人使用，可以自由使用和修改，用於您的專案。如果您打算將其用於某些個人專案，請放心使用，如果您想將其用於您的公司，您也應該這麼做。我們不希望任何雲端供應商 git clone 我們的專案，並成為 SaaS 產品的競爭對手。因為我們認為，如果我們可以在此基礎上建立可持續的業務，我們的專案將會更蓬勃發展。
今天我們的程式碼仍然採用 MIT 授權，但明天我們可能會將其變更為 Commons Clause，或像 MongoDB 和 Confluent 那樣編寫我們的公開授權。不，它不會像 OSI 所說的那樣是開源的，但我們認為，公開可用的原始碼仍然比封閉原始碼好，可惜今天沒有明確的術語。
