廚房裡有一種很老派的煩惱。你煮了一鍋很好喝的湯，一家四口喝剛剛好，湯的鹹淡、火候、下料的順序，都是照著這張桌子調出來的。結果某天親戚來了八個人，你就開始手忙腳亂：鹽要加倍嗎？鍋子夠大嗎？要不要乾脆重新設計一份「多人版食譜」？
9 月 24 日晚上，開發者社羣 V2EX 上出現了一篇低調的帖子：一個叫 OpenApp 的專案開源了，採用 Apache-2.0 授權。一句話介紹是，讓單使用者應用，成為每個人都能獨立使用的服務。聽起來很工程，但你把它放到廚房裡想，就是我們剛剛說的那鍋湯。
好用的工具，往往是照著一個人的胃口做的
OpenApp 的作者觀察到一件事：很多 Web 工具、AI 工作臺、自架專案，本來就很好用，但它們是按「一個人使用」設計的。就像一間一人份的廚房，砧板就一塊，碗就一副，冰箱裡的東西全是你自己的。一但要用來請客，麻煩就來了：要加帳號系統，等於要給每個客人發一副自家鑰匙；要分權限，等於要規定誰可以開冰箱、誰只能拿調味料；要做多租戶，等於把一間廚房打通隔間，改成一間小餐館。
傳統的做法，是把整個後端重構，等於把祖傳食譜整本重寫。很多團隊最後等於同時養著兩套架構，一套單人版，一套請客版，日子久了，兩邊的味道還會走岔。
OpenApp 的思路剛好反過來：食譜一個字都不改，改的是廚房的樣子。
每個人一副碗筷，同一本食譜
它做的事情，說穿了很像辦桌的邏輯。同一個大廚、同一套菜色，但每個客人面前有自己的碗、自己的筷子、自己的一份。A 夾到碗裡的菜，永遠不會跑進 B 的碗裡。OpenApp 為每個使用者建立獨立的執行環境和持久工作區，同一份應用鏡像可以同時服務多人，資料彼此隔離。開發者只要寫一個 Adapter，像是在原本的爐子上接一條延伸管線，業務邏輯幾乎不用動。
用帖子裏作者的例子來說：如果你寫了一個 AI Agent 桌面應用，接上 OpenApp 之後，Alice 和 Bob 各自擁有獨立的 Agent、終端、檔案和設定。你的程式碼還是那個「一人份」的程式碼，只是外面多了一個會分碗筷的管家。帳號、環境分配、部署、升級、監控，這些請客時最瑣碎的雜務，都交給平臺去張羅。
這跟我們之前聊過的搬進新家後廚房開火的第一頓飯是同一種心情：換了爐子，火還是那個火，菜還是那個菜，重要的是有人替你把瓦斯、鍋具、流理臺都安頓好了。
不是每個人都想開餐館
當然，帖子下面也有人不買帳。一位網友的回覆很直白：做使用者是為了收費，收費這塊人家憑什麼讓給你？他說如果不是為了收費，他寧願自己的獨立服務軟體用本地儲存，根本不上伺服器。
這話翻成餐桌語言就是：有人煮飯是給自己喫的， fridge 裡的剩菜自己消化就好，何必搬到巷口去擺攤。這種想法沒有錯，而且某種程度上很健康。自架（self-host）的樂趣，就像在自己廚房裡醬一缸豆豉、醃一罎梅子，時間和味道都掌握在自己手上，OpenApp 也確實標榜自架友善，目前支援 Docker 和 OrbStack，之後計畫擴展到 Kubernetes 等更多執行環境。
作者回應得很樸素：這是為了解決業務團隊只維護一套程式碼的問題，適合快速上線、前期快速迭代。翻過來就是，小攤子剛開張，先別急著裝修成大飯店，一副碗一副筷地添，穩。
回到你家餐桌
這則消息對不做軟體的你，其實也有一點滋味可嚐。
我們家裡很多東西都是「一人份」邏輯的：阿嬤的醬油比例是照她自己的舌頭調的，爸爸泡茶的水溫是照他那把壺摸出來的。這些食譜之所以好，恰恰因為它們不用服務所有人。而當某天你真的要請客，聰明的做法往往也不是重寫食譜，而是把桌子拉長、把碗筷補齊、把上菜的動線安排好。味道留在原處，份量和座位交給新的規矩。
下次你在廚房裡猶豫「這道菜到底要不要改成大鍋版」的時候，可以先問自己一句：是菜要變，還是桌子要變？很多時候，答案是後者。加一副碗筷，比改一鍋湯容易得多，而且每個人喝到的，都還是你當初調好的那個味道。
開源專案的倉庫就放在 GitHub 上，有興趣的讀者可以自己去看看那間「會分碗筷的廚房」長什麼樣。至於今晚，先把家裡的碗筷數一數，說不定這個週末，就有人要來喝湯了。