上週末我在 COSCUP 的演講「讓 AI 接管你的應用，打造微秒級無縫的 Ruby 安全沙盒」分享 Kobako 設計過程中的一些考量，後續的提問被問到在 AI 時代不太需要考慮語言時，為什麼要選 Ruby 呢？
簡單地回答，單純就是「我喜歡用 Ruby 這個語言」然而在 Kobako 的設計，還有很多更深層的考量。
實驗性
之所以會有 Kobako 專案誕生，剛好是 2026 年初 Harness Engineering 變得熱門，搭配我在 2025 年底的經驗，我對未來方向有一些預測。
大致上就是虛擬檔案系統（Virtual Filesystem）和沙盒技術（Sandbox）被我判斷是最值得的，正好四月的 RubyKaigi 我也跟不少人提到這幾個方向，又順便問自己，要不嘗試看看？
搭配 RubyKaigi 的 Code Party 活動被分配到 dRuby 組別，又更近一步讓我認為沙盒很可能是能夠實現，而且只需要把東西組裝，而不是去設計一套新的解決方案。
雖然最後因為 WASIp1 的標準讓我無法對 ruby.wasm 做任何擴充，鎖死了關鍵的幾個步驟，但這些都變成後續 Kobako 設計的基礎，像是使用相同的 Wasmtime 驅動 WebAssembly 環境、使用類似 dRuby 的方式設計宿主（Host）和客體（Guest）的互動機制，這也讓我後續的概念驗證順利成功。
開放標準
在實際開發的過程中，我一直在思考「自由度」的問題，也就是使用的人能不能拿去做到他想做的那些事情，這對我自己來說也很關鍵。
運氣很好的是，在 Ruby 生態系有語法幾乎相同的 mruby 可以選擇，而 Wasmtime 本身就是 Rust 為基底，而前幾年 Ruby 社群推動使用 Rust 寫 Extension 的支援後，幾乎只需要考慮怎麼去設計 Kobako 就可以。
最初，我考慮的是 WebAssembly 本身就是可替換的，因此在設計 ABI（Application Binary Interface）的時候，就盡可能限縮到大多數語言都能用的組合，並且把預設的溝通協定用 MessagePack 處理，這表示即使不用 mruby 也能用任意可以編譯成 WebAssembly 的語言，所以是 Ruby 搭配任意語言，而非只有 mruby 而已。
後續的整理，我開始思考很多公開介面設計的問題，這剛好是因為朋友任職的公司是做 WasmEdge 這個專案，實際上就是 Wasmtime 的替代品，因此我很快的就推出 Runtime 的概念，可以透過實作這個特性，讓任何能運行 WebAssembly 的套件都能夠用來跑 Kobako 的架構。
更近一步的處理，我為了把耦合解開，所以加入很多新的介面設計，並且不斷地問「這裡可不可以替換？」這樣的問題，像是「MessagePack 可以換掉嗎？」「如果不需要動態的介面，是不是可以改用 Protobuf？」這樣的提問，一步一步的擴充。
到目前為止，Kobako 更像是一個通用介面的提案，你可以用 Rust 把底層跑的 mruby 換掉或者擴充，也能更換 MessagePack 或者 Wasmtime，這讓他像是一個框架，而不單純是 Ruby Gem。
開源的意義
在 COSCUP 前夕，我反而因為 Kobako 這個專案的調性，以及現在 AI 時代的變化，重新思考「開放原始碼」到底是什麼？
自從開放原始碼變成熱門話題後，非常多公司都用開放原始碼的招牌推廣自家產品，直到近年還發現許多公司乾脆收回開放原始碼授權，或者根本就不是開放原始碼，更接近 Source Available（只把程式碼公開）這樣的概念。
也就是說，我們在網路上或者 GitHub 看到的大量專案，很可能都是不能自由修改也無法自己重現的，這樣還是一種「開放原始碼」嗎？實際上所謂的「開源模型」對於開源社群的人來說更接近「開放權重模型」的原因就是這樣，因為這些模型只是公開程式碼，但大家無法自己修改也很難重現。
總而言之，對我來說開放原始碼更像是一種「歡迎大家來改造成自己好用的形狀」這種感覺，我在把專案放到 GitHub 上時確實也是下意識的這樣思考，如果只是覺得小工具有用那就不會花太多心力在上面。
如果是 Kobako 這種類型，我則是會很仔細思考這些東西的公開介面是怎樣的，使用者可以怎樣去客製化，光是能提供這些，就能讓使用者省下很多的時間。
基本上這就是為什麼 Kobako 選 Ruby 的原因，他是個人喜好沒錯，但是背後所有的考量都是「不限於 Ruby」去設計。