我想壟斷我自己 (I Want to Monopolize Myself)

我知道這個描述有點ㄎ一ㄤ，不過請聽我娓娓道來。

軟體壟斷 (Monopoly)

眾所周知，軟體壟斷是存在的，例如：Google 電子郵件帳號、Android 手機、微軟作業系統、臉書社交平台...。

使用軟體本身沒有問題，問題在於閉源軟體、或是軟體與平台實際上被特定的商業實體所掌控，形成供應商鎖定，例如：微軟在作業系統上強推 AI 功能、TPM 硬體；又或是 Google 在 Android 上強推集中化且侵入性的政策...。消費者總是處於權益受損的被動方。

因此這世界上有一些人是十分認真看待這件事的，它們追求去中心化、自由、平等的軟體使用體驗，我作為開源軟體的支持者多少是認同這種理念的，但是有時候更多是現實的無奈。

比如說臉書，現實就是我國有很高的基數在使用 Meta 體系的社交平台（臉書、IG、脆），而這種平台為了避免資訊外流，不僅 SEO 不友善，大部分資料都藏在 API 之後，還透過 EULA (End-User License Agreement) 保護，所以現實就是不使用就容易和周遭的人脫節。

又比如 Gmail，雖然 SMTP (Simple Mail Transfer Protocol) 本身是開放的，想要架設 Email 伺服器本身很簡單，但是想要跟其他人的 Gmail 通訊，還需要滿足 SPF、DKIM、DMARC、DNS...等等設定，即使滿足設定也要「養」IP 和 Domain 的信譽才能避免信件被這些寡頭過濾掉。

壟斷抽象層

好了，所以我使用這些商業軟體或平台是一個既定事實，並且也有需求而仰賴著它們。

事實是，受開源軟體所賜，大部分商業軟體或平台都有開源替代方案，真正的問題是這些軟體不會自己架好給人使用，而且軟體的品質參差不齊，需求不見得被滿足、bug 不見得有人修。不過沒關係，先讓我們假設有一個公司存在，它只使用開源軟體，然後我可以直接使用這個公司的服務而無須自己煩惱維護軟體的細節。

於是一個比 Google 更邪惡的公司誕生了，因為現在我使用的所有（開源）服務都集中在這間公司身上，形成壟斷。

這件事情也可以換一個描述方式：假設一個諸如保護傘公司、荒坂公司、東亞重工這種虛構作品中虛構的壟斷企業，然後假設我所使用的所有軟體或平台都來自這個企業，而不是來自 Google 或 Meta...。然後使用開源軟體來「實做」這個虛構的「壟斷抽象層」。

我壟斷我自己

開源軟體只是實做這個抽象層的要素之一，它依然需要勞動力跟決策領導者才能運作，於是我作為董事或員工進入這個企業。從而形成了「我壟斷我自己」的傑作。

這個架構能夠解決另外一個問題，如果我單純的以 side project 的方式維護 homelab，我實際上很難區分我作為自然人的休息資源以及我投入在 side project 上本質屬於勞動的資源，資源包含時間和資本，透過這個虛構的企業，我便能把自己作為消費者以及法人生產者的資源區分開來。

曌銕重工

這個蠢主意其實不是剛想到的，而是已經醞釀一陣子了，為了那個「虛構的法人」我甚至已經準備了：

曌銕重工 (Stellar Cation Heavy Industries) 組織章程（草案）

Details

第一章 總則

1. 本組織名稱為曌銕重工(以下簡稱本會)。
   1. 讀作「ㄓㄠˋㄊ一ㄝˇ」。
   2. 英文名稱為 Stellar Cation Heavy Industries。
2. 本會不以獲取商業營利為最終目的，亦不進行盈餘分配；其內部治理與成員權利義務悉依本章程之約定。
3. 本會為開源、技術探索與自由創作之非營利虛擬實體。
4. 本會以地球本體、近地空間（Near-Earth Space）及地月系統（Earth-Moon System）之全部宙域為核心組織與治理區域。
5. 本會以維持運作之伺服器設備與資訊基礎設施所在之虛擬網路空間為核心會址。鑑於基礎設施之物理位置具備動態移轉性，本會不設實體會址，其行政作業與通訊通聯之核心網際網路平台，授權由理事會決議並公告之。
6. 本會之任務如下：
   1. 虛擬法人實體之營運與技術與非技術項目研究與開發之管理。

第二章 會員

7. 本會會員分下列一種：
   1. 個人會員：凡贊同本會宗旨之自然人，填具入會申請書，經理事會審定通過，並繳納入會費後，為個人會員。
   2. 團體會員：凡贊同本會宗旨之外部專案機構或團體，填具入會申請書，經理事會通過，並繳納入會費後，為團體會員，並推派自然人代表一人行使權利。
8. 會員(會員代表)有違反本章程或不遵守會員大會決議時，得經理事會決議，予以警告或停權處分，其危害團體情節重大者，得經會員大會決議予以除名。
9. 會員有下列情事之一者，為出會：死亡、喪失會員資格者、或經會員大會決議除名者。
10. 會員得以書面並敘明理由向本會聲明退會。
11. 會員經出會或退會，已繳納之各項費用不予退還。
12. 會員(會員代表)有表決權、選舉權、被選舉權與罷免權。每一會員為一權。
13. 會員有遵守本會章程、決議及繳納會費之義務。連續一年未繳納會費者，視為自動退會。

第三章 組織及職權

14. 本會以會員(會員代表)大會為最高權力機構；理事會為執行機構。
15. 會員(會員代表)大會之職權如下：
    1. 訂定與變更章程。
    2. 選舉或罷免理事。
    3. 議決入會費、常年會費之數額及方式。
    4. 議決年度工作計畫、報告及預算、決算。
    5. 議決會員(會員代表)之除名處分。
    6. 議決財產之處分。
    7. 議決團體之解散。
    8. 與會員權利義務有關之其他重大事項之議決。
16. 本會置理事一人，由會員(會員代表)選舉之，分別成立理事會。 遇理事出缺時，依序遞補，以補足原任者餘留之任期為限。理事之當選名次，依得票多寡為序，票數相同時，以抽籤定之。
17. 理事會之職權如下：
    1. 議決會員(會員代表)大會之召開事項。
    2. 審定會員(會員代表)之資格。
    3. 選舉或罷免常務理事、理事長。
    4. 議決理事、常務理事或理事長之辭職。
    5. 聘免工作人員。
    6. 擬定年度工作計畫、報告及預算、決算。
    7. 其他應執行事項。
18. 理事會置常務理事一人，由理事互選之，並由理事就常務理事中選舉一人為理事長。 理事長對內綜理會務，對外代表本會，並擔任會員(會員代表)大會、理事會主席。 理事長應視會務需要到會辦公，其因故不能執行職務時，應指定常務理事一人代理之，不能指定時，由常務理事互推一人代理之。
19. 理事之任期十年，連選得連任，理事長之連任，不設上限。
20. 理事為無給職。
21. 理事有下列情事之一者，應即解任：
    1. 喪失會員(會員代表)資格者。
    2. 因故辭職經理事會決議通過者。
    3. 被罷免或撤免者。
    4. 受停權處分期間逾任期二分之一者。
22. 本會置總幹事(或秘書長)一人，其他工作人員若干人；依資格條件遴選工作人員，提經理事會通過後聘僱之，解聘時亦同。
23. 本會理事得兼任會務工作人員。
24. 本會設立分支機構，其組織簡則由理事會擬定，載明設立依據、組成、任務、經費來源等，提經會員（會員代表）大會通過後行之。
25. 本會得由理事會聘請名譽理事長一人，名譽理事一人，顧問一人(均為義務職)，其聘期與理事之任期同。

第四章 會議

26. 會員(會員代表)大會，分定期會議與臨時會議二種，由理事長召集， 召集時應於十五日前以書面或電子通訊通知之。 定期會議每年召開一次；臨時會議於理事會認為必要，或經會員(會員代表)五分之一以上之請求時召開之。 會員（會員代表）大會得以視訊會議或其他經理事會公告之方式召集之，簽到及表決方式則配合電子化設備功能辦理。但涉及選舉、補選、罷免事項，應以實體或具備身分驗證之特定非視訊集會方式辦理。

27. 會員(會員代表)不能親自出席會員(會員代表)大會時，得以書面或電子授權委託其他會員(會員代表)代理，每一會員(會員代表)以代理一人為限。

28. 會員(會員代表)大會之決議，以會員(會員代表)過半數之出席，出席人數過半數或較多數之同意行之。但下列事項之決議以出席人數三分之二以上同意行之：

    1. 章程之訂定與變更。
    2. 會員(會員代表)之除名。
    3. 理事之罷免。
    4. 財產之處分。
    5. 團體之解散。
    6. 其他與會員權利義務有關之重大事項。

29. 理事會每一個月召開一次，必要時得召開臨時會議。 前項會議召集時除臨時會議外，應於七日前通知，會議之決議，以理事過半數之出席，出席人數過半數或較多數之同意行之。 理事會議得以視訊會議或其他經理事會公告之方式召集之，簽到及表決方式則配合電子化設備功能辦理。但涉及選舉、補選、罷免事項，應以實體或具備身分驗證之特定非視訊集會方式辦理。

30. 理事應親自出席理事會議，不得委託他人代理；連續二次無故缺席，視同辭職。

31. （本條因原屬陳報主管機關之程序，於虛擬法人架構下無適用對象，故予以移除，保留編號以維繫章程結構）

第五章 經費及會計

32. 本會經費來源如下：

    1. 入會費：會員入會時，應一次繳納新臺幣100元。
    2. 常年會費：每年新臺幣500元。
    3. 會員捐款，得區分為一般經常性捐款，或針對特定技術、創作項目之「專門指定捐款」。
    4. 委託收益。
    5. 基金及其孳息。
    6. 其他收入。

33. 本會會計年度自每年一月一日起至十二月三十一日止。

34. 本會每年於會計年度開始前由理事會編造年度工作計畫及收支預算表，並於會計年度終了後三個月內由理事會編造上年度工作報告、會計報告，連同當年度工作計畫及收支預算表，提經會員(會員代表)大會通過。會員(會員代表)大會因故未能及時召開時，可先經理事會通過，事後提報大會追認。

35. 本會於解散後，剩餘財產之歸屬，由會員(會員代表)大會決議處置之。

第六章 附則

36. 本章程未規定事項，由理事會依本會宗旨另訂內部規範辦理。
37. 本會辦事細則，由理事會訂定之。
38. 本章程經會員(會員代表)大會通過後施行，變更時亦同。

組織章程是拿「臺北市社會團體章程草案範例」改的，有趣的是命名時我其實面臨了抉擇，因為要法人化，因此不能使用情感連結太強的名稱，必須要是可割可棄的存在，不然到時候像賈伯斯被踢出去之後會很惱火，這麼一想，突然能理解為什麼一堆公司的名字都這麼菜市場了。

除了抽象的組織章程，落地方面， 我也準備將個人的 Side Project 重新編制方式：

曌銕重工實體與專案檢索表建置與維護作業辦法（草案）

Details

1. 目的

   • 為規範本會行政助理於建置、更新「外部實體-專案檢索表」時之作業流程，確保資料登錄之準確性與即時性，以利日後行政查核時能快速透過實體名稱反查專案流水號，特訂定本辦法。

2. 管理職責

   • 本辦法之主管機關為理事會，負責外部實體識別碼之核准、表單結構之變更及不定期抽檢。本會行政助理為「外部實體-專案檢索表」之直接維護與登錄人員，應負責日常資料之依據核准登錄、變更追蹤與定期備份。

3. 檢索表建置媒介與存取權限

   1. 檢索表應建置於本會指定之試算表（Spreadsheet）或資料庫系統中。
   2. 本表之「編輯權限」僅限行政助理與理事會成員；本會其餘個人會員與團體會員僅開放「檢視（唯讀）權限」。

4. 實體識別碼之編發與核發權責

   1. 實體識別碼由五碼組成，採「類別英文字母（一碼）」與「流水號（四碼）」之組合。
   2. 類別英文字母定義如下：
      • 「C」開頭：代表具備獨立法人資格之公司、行號、商業實體或官方機構（如 C0012）。
      • 「P」開頭：代表自然人、個人委託者或獨立開發者（如 P0005）。
      • 「G」開頭：代表外部開源社群、非正式組織、DAO 等外部協作群體。
      • 「I」開頭：代表本會內部之特定興趣小組（Interest Group）、委員會、或本會自發性、無外部委託對象之自有研發專案（RD 性質）。
      • 「U」開頭：代表未知或無法考證之歷史實體。
   3. 實體識別碼之核發遵循「唯一性」原則。同一識別碼一經核發即具備唯一性，不得重複核發予不同實體，亦不得刪除。
   4. 核發程序：
      • 實體或內部單位首次與本會建立合作或立案關係時，由行政助理依時間先後順序及本條第二款之分類預編識別碼，提報理事會審查。
      • 實體識別碼須經主管機關（理事會）審查並正式核發後，始生效力。

5. 檢索表之常態登錄與建表作業

   1. 行政助理於接獲以下核准通知後，應將相關資料登錄至檢索表：
      • 通知一：主管機關（理事會）正式核發新「實體識別碼」之通知。
      • 通知二：依《研發專案字號編製作業要點》核准新「研發專案字號」之立案通知。
   2. 檢索表之表頭欄位應嚴格遵循以下結構建置：
      1. 【實體識別碼】：填寫經理事會正式核發之五碼代碼。
      2. 【實體全稱】：填寫公司法人登記全名、組織官方名稱、社群群體正式名稱或個人真實姓名。
      3. 【常用別名/社群ID】：填寫網路常用暱稱、Discord ID、GitHub 帳號或機構縮寫（如：Stellar Cation Heavy Industries 加註 SCHI），以利多元關鍵字搜尋。
      4. 【完整專案字號】：必須填寫包含後綴的完整字號（如 SCHI-2026-001-ODM）。
      5. 【專案流水號（核心）】：單獨列出專案核心流水號（如 2026-001），作為核心檢索錨點。
      6. 【專案性質】：依《研發專案字號編製作業要點》第三條第四款之分類，填寫 RD、ODM 或 OEM。
      7. 【專案名稱】：填寫該專案之正式名稱或開發代號。
      8. 【立案日期】：填寫專案正式啟動或合約簽署之西元日期（格式：YYYY-MM-DD）。
      9. 【結案狀態】：分為 執行中、已結案、暫停、註記作廢。

6. 歷史專案與實體之補登程序

   1. 針對本會成立前或本辦法實施前之歷史舊案，行政助理應協同專案負責人考證歷史資料，提出溯及補登申請，經理事會審查通過後，於一個月內完成「實體-專案檢索表」之登錄。
   2. 若歷史專案之委託或合作對象已無法考證，經理事會核准後，【實體識別碼】欄位依序配發「U」開頭之未知實體代號（如 U0001），【實體全稱】欄位則註明「未知或無法考證之歷史實體」。

7. 行政檢索操作指引（查找特定專案流水號）

   • 行政助理或會內成員於日後需要查找特定專案資訊時，應依下列步驟進行操作：
     1. 步驟一：開啟「外部實體-專案檢索表」，使用快捷鍵（如 Ctrl + F）開啟搜尋功能。
     2. 步驟二：輸入欲查找之實體名稱、別名或社群 ID。
     3. 步驟三：定位至該實體之資料列，即可直接於同列之【專案流水號（核心）】或【完整專案字號】欄位中，查得該特定專案的流水號。
     4. 步驟四：若欲查找該實體歷年來的所有合作，可直接對【實體識別碼】欄位啟用試算表之「篩選（Filter）」功能，即可一鍵列出該實體名下的所有歷史專案。

8. 資料維護與更正機制

   1. 實體識別碼與專案字號一經核發並登錄，行政助理不得任意刪除或變更。
   2. 倘專案後續發生撤案或終止，助理應依據理事會之決議或通知，將【結案狀態】欄位更改為「註記作廢」，並於備註欄說明原因。
   3. 外部實體或內部單位更名時，助理應檢具更名證明文件提報理事會，經核准後更新【實體全稱】欄位，但原有的【實體識別碼】與其對應之歷史專案流水號一律保持不變，以維持歷史資料的真實性。

9. 施行

   • 本辦法自發布之日起實施，修改時亦同。

曌銕重工專案字號編製作業要點（草案）

Details

1. 主管機關

   • 本作業要點主管機關為理事會。

2. 專案立號義務

   • 凡本會之研發專案，均應依本要點之規定編製專案字號，以資識別、統計及檔案分類管理。

3. 字號組成格式

   • 專案字號由「組織代碼」、「年份」、「年度序號」與「專案性質」組合而成，區分為四段式結構，各碼間以半形連接號（-）銜接。其標準格式如下：
     • SCHI-<年份>-<年度序號>-<專案性質> （範例：SCHI-2026-001-AD）
   • 各區段定義如下：
     1. 組織代碼：固定為「SCHI」（Stellar Cation Heavy Industries），用以標示本會所屬專案。
     2. 年份：採西元紀年，以四位數計（如 2025），用以標示專案立案之年度。
     3. 年度序號：採三位數流水號（自 001 開始），不分專案性質，一律依專案申請登記之先後順序，依序編發。
     4. 專案性質：用以識別專案之運營模式與法律責任分類，分為以下四類：
        • RD（Research & Development）：本會自有之核心技術探索、開源專案與自由創作項目。
        • ODM（Original Design Manufacturer）：本會為主導規劃、設計並開發，但智慧財產權與實體成果歸屬外部委託方之專案。
        • OEM（Original Equipment Manufacturer）：純屬承接外部明確規格、按圖施工之純技術勞務代工項目。
        • AD（Artistic Design）：凡屬本會自製或受託承接之視覺傳達、平面設計、LOGO識別、多媒體美術創作等美術設計類項目。

4. 序號更易與管理機制

   • 專案字號之年度序號遵循「每年更易一次」原則。每逢新結算年度（跨年）時，號碼應重新起算，自 001 開始編列，不得延續上一年度之流水號。
   • 專案字號之前置核心「SCHI-<年份>-<年度序號>」一經核發，即具備唯一性。同一年度序號不得重複核發予不同專案，亦不得因末端「專案性質」之不同而重複遞補使用（例如：已核發 SCHI-2025-001-RD 後，該年度即不得再出現 SCHI-2025-001-ODM）。倘專案後續發生變更、暫停或終止（撤案），該字號應予保留或註記作廢，不得刪除。

5. 歷史專案之溯及編列與常態補登機制

   • 本要點實施前已存在、啟動或結束之歷史研發專案，應追溯納入本字號編製體系。
   • 歷史專案之字號編列原則如下：
     1. 年份認定基準：一律以該專案當初「實際發起、首次程式碼提交（Commit）、公開發表或首度執行」之西元年份為准。
     2. 歷史序號整編原則：歷史溯及專案之補登，於各該歷史年度內，仍應自 001 開始依實際發起時間之先後順序依序編列。於本要點通過後六個月之整編期內，專案管理人員得打破既有登記順序，對同一歷史年度之專案流水號進行調整與插編，以還原真實歷史排序。
     3. 外部專案與歷史代工移轉認列：
     • 凡個人會員或團體會員於入會前（或本會成立前）所獨立發展或承接之舊有項目，有助於彰顯成員技術履歷與本會歷史貢獻者，得申請追溯認列為本會歷史專案。
     • 前項歷史專案經理事會審查通過後，依其最初發起年份發給專案字號，並依第三條第四款之標準認定其專案性質，據以配發 RD、ODM 或 OEM 之性質尾碼。
     4. 常態補登與歷史序號凍結限制：本要點通過實施屆滿六個月後，歷史專案之整編期即告結束，該歷史年度已存在之流水號序位予以凍結，不得再進行任何因應歷史排序之插編或變更。整編期結束後，會員仍得隨時申請補登歷史專案，主管機關應依其歷史年份予以認列，惟其流水號應承接於該歷史年度既有最後一號之後，依申請時間順序遞增編列。

本來是想把手邊的三台舊筆電用 Talos 拼成 Kubernetes 叢集運行 email 和 Kimai 作為曌銕重工的第一號財產，選擇的理由很簡單：

• email 可以說是數位基礎建設，雖然跟 ID Provider 是兩回事，但是實務上它就是 ID 之源，其他帳號的密碼都可以忘，就是 email 的不行。對我而言它應該已經像是郵政服務一般的存在了，政府沒有在這方面努力對我而言算是十分的不解，不過這又是另外一個話題了。
• Kimai 是用來「打卡上班」的基礎設施，也可以說是 HR 的自動化基礎設施，畢竟人力資源是生產要素基本中的基本。

至於這個規劃為什麼拖延了許久？說來話長。

原本選擇筆電叢集的原因之一是基於「這輩子大概跟（機架式）伺服器沒什麼緣份」的前提定調的，然而最近卻因緣際會跟它結了緣，現在上班都會有伺服器用它的風扇聲在我腳邊喵喵叫。總之，因為這樣我不得不經歷思想鬥爭：繼續往筆電叢集的道路前進，還是考慮比較能和職業結合的機架式伺服器體系。

另一方面是因為搬了家，沒有管理室幫忙收包裹的情況購買鐵力士層架這種大型物品簽收會變得很麻煩，目前房間又沒有比較合適的空間可以安置這三台筆電構成的叢集。

除此之外亦有來自週邊影響的「AI 焦慮」，不得不把一些精力和時間分配給相關主題...。

結論

總之，看到這裡，你應該對於「我想壟斷我自己」有比較具體的想像了。至於它究竟是一個神經病得幻想還是實際上有點意義的概念？

之後我們或許就知道了。