你的產品，有多少比例是"你的"？
之前，我們開發了一個不錯的工具，當時因為沒搞清楚產品規格的定位及時程壓力，最終落得無人問津的下場。雖覺得可惜，但也只能把它留在倉庫。最近專案在做自家產品的大規模整頓時，希望能為這類的產品導入一個正規的工具，來優化製程，因此就又讓這個產品重見天日。很幸運的是，產品的作者還在我組內，為了讓新人也瞭解這工具的能力及實作原理，我請他為這個專案做一些導入的處理，補上一些專案的功能需求，以及原來沒支援的特性。
新人很努力的瞭解工具的能力，和專案人員也常常視訊會議討論，釐清需求。由於作者就在他身後，有什麼問題第一時間就能獲得協助，這全程比我預期的還要快很多，幾乎算是合作愉快。可昨天一通電話過來的要求，就讓這宗合作案隨即終止。
「我希望接下來的支援的速度能更有效率，別通過新人再滿足需求，直接請作者處理。」
對方不斷說明，他們的時程有多趕，有多要人命，壓力有多大…我能理解，但也盡力說明，這工具原先的設計，和他們現在要導入的環境並不相同，所以才請新人來處理這件事。一來是作者手邊也有事情要處理，二來可讓這個工具多一個人瞭解，將來就多一個人能維護。工具是我們開發的，作者也在這裡，透過新人滿足需求，我聽不出哪裡有問題啊？現在是他在導入的，是他跟作者討論過導入的，為什麼非得直接要找作者處理？作者真的下來處理，為了接上新人之前的進度，他還得回頭跟新人討論最新進度，才有辦法繼續推進吧？人力資源的調動，往往是看當下事情的優先權決議，我的職權實在沒辦法給他保證，讓作者放下手邊的事，第一優先幫他們處理。最後只能跟他說明，我願意幫忙，如果他能解決人力資源調度的問題，能給”被插隊”的專案交待，我這邊就沒問題。
後來，就收到專案團隊的通知，因為他們時程較趕，而且規格還有很多未明之處，因此最後決議他們先自己開發一個簡單的版本，等上線後再視情況，看看需不需要導入我們這個正規的工具。
這個過程讓我覺得很無奈的，是對「軟體」的不可掌控性。
10幾年前那個時候，公司內的軟體還處在Non-OS的時代。在那個”美好”的時代裡，源碼是可以”掌握”的。就像壽司師父手上的飯，魚，芥末，噴槍…所有的東西都是能完全理解它們的用途，在「壽司」這個產品中扮演的角色，師父的巧手可以創造一切，也可以修正所有的錯誤。到了現在這個時候，所有的軟體產品，所處的軟體框架都是極其龐大的。Windows/MacOS根本沒有開源；不管是Linux還是Android都大到不可能可以理解所有驅動程式還是行程管理；圖學領域的書可以排滿一整個圖書館的書架；資安的觀念從演算法，簽章，甚至可以一路延伸到區塊鏈；啊？你說還有VR/AR/MR還是元宇宙？對，那是「宇宙」啊；這些東西怎麼學得完？哦，對了，還有機器學習…
前陣子一部有名的公視劇集叫《你的孩子不是你的孩子》。結果你猜怎麼著？在軟體世界不也一樣嗎？你的源碼根本也不是你的啊。當我們在享受別人努力的成果時，我們同時也在接受制約。用別人開發好的工具或是函式庫，你還能找到作者就該偷笑了，如果沒付費，你怎麼會認為作者應該第一時間把手邊的事情放下來，來幫你解決問題還是滿足需求呢？當我們在Windows下運行我們開發的產品，結果Windows有bug，更新了介面，不再支援你的裝置…你當然會覺得Microsoft人不是很多嗎？怎麼沒辦法趕快來解決這個問題呢？這樣我怎麼賣我的產品？Windows真爛…結果你會發現Windows的穩定度其實比Ubuntu還要好。大家明明都知道，軟體都是人寫的，外國的月亮不會比較圓，寫出來的軟體都會有bug。可大家還是會有一種不切實際的期待，覺得大廠或開源社群的產品，開發者那麼多，有問題的話一定會獲得立即的技術支援，會有”熱心”的工程師趕快出來解決問題，我們只要等，什麼事都不用做，問題就會自己修好，新功能就會自己冒出來。
孩子，若源碼在你手上就別作夢了，要就挽起袖子自己修，要就自己想辦法繞過去。若源碼不在你手中，那就自己摸摸鼻子，看怎麼閃掉眼前的問題，而不是花時間去報怨為什麼沒有人，會放下手邊的事情來解決你的問題？
現在已經不是整個產品的源碼，是可以被看”完”的時代了。任何一個產品的底下，都是一大塊的”智慧結晶”。你覺得人家的產品怎麼這麼不成熟？你覺得這個產品為什麼沒有配置人力，來支援身為用戶的你？或許真正的問題是，你並沒有真正理解「軟體」是怎麼被開發出來的。你的產品，有多少比例是”你的”？