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 專案的情況
非開源專案。
違反自由、平等、人權等普世價值的專案(?)
成為 g0v 專案貢獻者的方式
- 可以聯絡專案窗口,彼此討論有哪些適當的坑
- 如果是軟體開發專案,也可以衝 github 直接 fork 程式碼、提出 pull request
- 如果是內容創作專案,也可以衝 google drive 直接 fork 工作檔,建立自己的作品資料夾
外部商業 / 政府 / 非營利組織和 g0v 一起開發的方式
- 依主導權
- 邀 g0v 貢獻者主導開發:來黑客松提案,看有沒有人願意跳坑,專案方向由開發者自行決定
- 這是一般最常見的合作模式
- 優點:自由、快樂、超展開、充滿驚喜
- 缺點:無法預測會發展成什麼樣子,也不一定會有人跳坑
- 共同開發:開發過程中,雙方一起討論取得共識並執行
- 範例:404失蹤兒專案
- 優點:開發出來的成果組織本身馬上可以使用,不需要額外的轉換工作
- 缺點:如果組織本身有時程壓力,g0v 貢獻者不保證能夠配合。如果對專案發展的方向產生歧見,g0v 貢獻者不保證會持續投入開發,也可能會自己 fork 出另外的版本。
- 邀 g0v 貢獻者參與組織主導的開發:
- 如果專案主導者超有個人魅力,也許可以成功說服個別貢獻者接受這樣的方式
- 優點:可以很符合主導者的需求
- 缺點:如果主導的人不是超有魅力,很可能找不到人跳坑。由於專案仍是開源的,同樣無法保證 g0v 貢獻者會持續配合,也可能 fork 出另外的版本
- 依源碼授權
- 部分 open source
- 延遲 open source 的時間點
- 在尚未 open source 前,視為一般私人專案
- 在尚未 open source 前,如果想邀請 g0v 貢獻者參與,依一般私人專案的作法和個人簽約
取用 g0v 的開發成果
- 應用在開源專案
- 只要遵循授權即可取用程式碼
- 如果需要向原開發者諮詢技術細節,可以直接上 g0v irc 或 github 發問
- 應用在非開源專案
- 只要遵循授權即可取用程式碼
- 如果需要向原開發者諮詢技術細節,可以個別聘請開發者為顧問