g0v Dev Policy | 零時政府開發政策
成為 g0v 專案的條件
- 如果是軟體開發專案，必須採用任何一種 open source 授權
- 只要開源，營利專案也可以成為 g0v 專案
- 程式碼可以放在自己的 github 個人帳號，也可以放在 g0v 組織帳號
- repo 裡建議放 g0v.json 檔案，以利程式自動抓取專案資訊放到專案列表中，雖然這並不是必要的
- 如果是內容創作專案，必須採用任何一種 creative commons 授權
- 為了符合開源精神，可編輯的原始工作檔案（psd、ai、aep、band…）必須一併釋出
- 建議將釋出的檔案放在 g0v 共用的 google drive 資料夾，以便將來整理至授權中心
- 期望專案主旨不違反以下精神，雖然這並不是必要的
- 支持 open government data、資訊自由
- 支持公民基本權平等
- 支持…
不能成為 g0v 專案的情況
非開源專案。違反自由、平等、人權等普世價值的專案(?)
ET Blue宣揚歧視的專案是否能成為g0v專案？例如反對同志平權，或者打壓台灣國家主權等
普世價值不易衡量，如法規亦毒氣的授權雖然開源，但是具爭議性，也許正面列舉充要條件即可，這一節可以省略？
已標記為省略 XD
成為 g0v 專案貢獻者的方式
- 可以聯絡專案窗口，彼此討論有哪些適當的坑
- 如果是軟體開發專案，也可以衝 github 直接 fork 程式碼、提出 pull request
- 如果是內容創作專案，也可以衝 google drive 直接 fork 工作檔，建立自己的作品資料夾
外部商業 / 政府 / 非營利組織和 g0v 一起開發的方式
- 依主導權
- 邀 g0v 貢獻者主導開發：來黑客松提案，看有沒有人願意跳坑，專案方向由開發者自行決定
- 這是一般最常見的合作模式
- 優點：自由、快樂、超展開、充滿驚喜
- 缺點：無法預測會發展成什麼樣子，也不一定會有人跳坑
- 共同開發：開發過程中，雙方一起討論取得共識並執行
- 範例：404失蹤兒專案
- 優點：開發出來的成果組織本身馬上可以使用，不需要額外的轉換工作
- 缺點：如果組織本身有時程壓力，g0v 貢獻者不保證能夠配合。如果對專案發展的方向產生歧見，g0v 貢獻者不保證會持續投入開發，也可能會自己 fork 出另外的版本。
- 邀 g0v 貢獻者參與組織主導的開發：
- 如果專案主導者超有個人魅力，也許可以成功說服個別貢獻者接受這樣的方式
- 優點：可以很符合主導者的需求
- 缺點：如果主導的人不是超有魅力，很可能找不到人跳坑。由於專案仍是開源的，同樣無法保證 g0v 貢獻者會持續配合，也可能 fork 出另外的版本
當然也是可以花錢請 g0v 相關專案貢獻者進行開發、設計等等，只是可能會依照最終授權而有不同的收費標準
- 依源碼授權
- 部分 open source
- 開源和非開源的程式碼分開來放
- 延遲 open source 的時間點
- 在尚未 open source 前，視為一般私人專案
- 在尚未 open source 前，如果想邀請 g0v 貢獻者參與，依一般私人專案的作法和個人簽約
取用 g0v 的開發成果
- 應用在開源專案
- 只要遵循授權即可取用程式碼
- 如果需要向原開發者諮詢技術細節，可以直接上 g0v irc 或 github 發問
- 應用在非開源專案
- 只要遵循授權即可取用程式碼
- 如果需要向原開發者諮詢技術細節，可以個別聘請開發者為顧問