進入公部門寫專案的我竟然把程式碼開源了
TonyQ
關於我
2005~2009 軟體工程師
2009~2010 地方政府替代役
2010~2014 軟體工程師
2014~2015 在行政院服務
2015~2018 在地方政府服務
2018~2022 軟體工程師
2022~2022 市議員候選人
2023~迄今 軟體工程師
(概略的分類)
關於我
自我認同為軟體工程師
對任何事都抱著可改變的想像
不在意別人覺得做不到的事情
不在意別人覺得很簡單的事情
只在意自己能做的事情
你得去試，才有經驗可以分享
前言聲明
簡報不重要，你閉上眼睛聽我說故事，也沒有問題的。
這是一份字很多的簡報
在大會議程共筆上有簡報連結
有興趣可以會後再重新看
今天要聊的其實是
失敗的故事
但真的想跟大家聊的其實是
什麼是開源
問題的核心是
開源是什麼
首先第一件事情，什麼東西需要 Open Source？
第二件事情，沒有人會認真的去把你 open 的 source code 讀完，除非他需要的功能你 code 有bug 或者你沒作。
第三件事情，Open source project 並不代表 All you can do
第四件事情：收入、熱情、維護。
說了這麼多，我想表達的是 Open Source Project 雖然是人人有門票，但回過頭來還是同一件事，你必須找到你自己想做跟你該做的需求，並試著說服別人接受你的提案，不管這個別人是使用者或者是 project team member.
TonyQ@2011
"經歷"
也可以 open source
今天的四個故事
- 用開源的系統解決政府問題
- 從需求端開源的政府系統
- 從勞務委託中開源的系統
- 從內部工作中開源的系統
片末有小彩蛋第五種
這個討論「不會」涉入太多「技術開發」的細節，而會著重在「需求的來源跟執行」以及「什麼時候開源」、「開源之後的影響」，
「文化」面的討論
預算視覺化
https://github.com/g0v/twbudget
2012 yahoo hack day
- 最早的 contributor 是 zbryikt,clkao
- 他是一個已經存在的系統
2015 北市府推動
引用自 "g0v 預算視覺化後續 - 臺北市經驗" @ g0v sommit 2016 https://www.slideshare.net/tonylovejava/g0v-62023579#5
背後的故事
系統如何落地導入?
背後的故事
系統如何落地導入?
背後的故事
其他單位的需求 (等於重新導入
背後的故事
其他單位的需求 (等於重新導入
背後的故事
其他單位的需求 (等於重新導入
背後的故事
中央單位的需求
背後的故事
中央單位的需求
背後的故事
中央單位的需求
最後的故事
其他單位的需求 (等於重新導入
政府資料開放平臺上的預算資料
臺北市數位災民證
https://github.com/g0v/shelter Credit by yu-tin liu
photo from 105年災害救助研習班 簡報
問題的起源
photo from 105年災害救助研習班 簡報
問題的起源
photo from 105年災害救助研習班 簡報
問題的起源
photo from 105年災害救助研習班 簡報
問題的起源
photo from 105年災害救助研習班 簡報
問題的起源
photo from 105年災害救助研習班 簡報
問題的起源
photo from 105年災害救助研習班 簡報
既有系統設計
問題
現場如果沒網路怎麼辦
改為分散式設計
不能解決所有的問題
臺北市各區災害應變中心收容組 標準作業程序
中華民國112年6月20日 北市正民字第1126010556號函增修
再後來彙整需求
委託給廠商協助
台中市參與式預算系統
從勞務委託中開源的系統
起源
團隊接到計畫
因為工作有專案需要、時程複雜、系統需求強烈，
找合作伙伴討論
討論過程
討論過程
專案開發
最後結果
最後結果
幾年後政策轉換，網站下架，
所有資料沒有再公開
嘉義燈會志工管理系統
2xxx 人的志工管理、報到、志工時數。
嘉義縣智慧城市辦公室
2016 @ 嘉義縣政府
因為自己就是 user
所以基本上沒啥限制，自己SA自己開發，自己提供服務。
對應業務單位信任度高
溝通成本很低
路燈報修系統
把所有路燈放在地圖上，讓村民跟村里幹事可以即時回報公所修復。
溝通過程
鹿草鄉公所聊天時提出需求
我表示縣府可以協助，所以幫忙製作系統
溝通過程
水上鄉公所後來知道這件事情
水上劉鄉長表示他們也想一起用，
協助他們導入，他們還有印在年曆上。
後續結果
我從嘉義離職後系統因無人維護，
目前網站已關閉。
中埔鄉有一個類似的機制
https://street-lamp.jhongpu.cyhg.gov.tw/SL606/
回顧
什麼東西需要 Open Source？
以政府單位來說，陌生的東西、需要別人協助的東西、無法確認、且不涉及敏感資訊的東西，
他們會願意跟社群、開源合作，來一起探索。
合作的對象會需要一定的信任感。
回顧
第二件事情，沒有人會認真的去把你 open 的 source code 讀完，除非他需要的功能你 code 有bug 或者你沒作。
在預期沒有太多人使用或一次性使用的前提下，說明文件、程式碼內容、相關的接手文件品質都會顯著變得更差勁。
且，在缺乏其他誘因的情況下，比較不會有綜效。
回顧
第三件事情，Open source project 並不代表 All you can do
有一些事情是社群或者開發者們自己覺得更好的方案，但是受限於組織的條件、目標甚至責任分工，會導致我們需要選擇差很多的方案。
回顧
第四件事情：收入、熱情、維護。
在既有的遊戲規則中，政府專案流行製造技術壁壘，來確保自己的標案永續性。（比方說只有特定廠商知道的 schema、程式流程、複雜的系統串連）
並且標案導向的專案，對於需求跟功能是定的很死的，體系不太能接受會成長的功能，也都會擔憂這些功能後續的維護性。
在開源的角度來說，若無企業願意承接專案，本身難以延續。而由企業承接專案，他是否願意放棄自己的壁壘，則非常考驗人性。
用 Hackathon 來開源
最後的小工商
行動自然人憑證目前開放一般企業介接（不限制只有公營企業介接）。
有興趣歡迎聯繫以下信箱
moica@authme.com
有關的部分是我正在遊說他們做 SDK & open source。
