TL;DR
Open-NCU旨在提供中央大學的開發者一個機會，替校內師生開發應用服務。這邊會談談這個計劃發展中遇到的問題和個人的一些想法。
前言
我在中央大學擔任技師，2014年8月時與另一個同仁、五個工讀生開始了這個團隊。一開始只是為了開發一些校內使用的APP，後來開始思考將APP開源的可能性；也把資料提供的部份用NCU API代替，並且開放給校內使用。最後這些成果都以MIT License的授權方式放在github上。
我想分享在這期間內遇到的一些問題和想法，供其他大學的教職員或學生團隊參考。
內部
使用Slack做為溝通平台
我們一開始使用電子郵件。但學生沒有回信給所有人的習慣，常常只回信給寄件者；也沒有隨時收信的習慣，在溝通效率上其實很慢。後來使用Slack，Slack非常適合用來作為團隊溝通平台的工具，並且也可以與github、Trello等其他工具溝通；分享程式碼、圖片或檔案也非常方便；也可以用瀏覽器或app參與討論；免費的額度對於一個不到十人的團隊非常夠用。使用Slack有一個重點是分享彼此的討論過程，任何問與答的過程都可以被其他人看到，這對於實務經驗比較少的學生來說，可以更快速地提升他們的技術能力與實務經驗。
Slack雖然有即時溝通的功能，我還是建議當成留言板來使用，因為學生與社會人士不同，他們主要的工作是唸書，因此不能期待全部人都可以即時回應，必須要有點耐心。但有時還是需要適當的催促。
工作時間
對工讀生來說，寫程式很難有一個給薪的標準，所以我們的評估是一星期約8~12小時，再乘以學校規定的時數上限給薪。學生會有期中考週和期末考週，這點也必須特別注意。建議寒暑假時可以密集一點，但對於要考研究所的工讀生可能需有另外的考量。開會時間
人一多就很難有一個共同可以開會的時間，尤其是來自不同年級或不同系所，所以建議是將小部份的問題在Slack就先解決，會議上再來討論大方向。技術
從課程與餐廳開始規劃API
從以前辦app比賽的經驗得知，大部份學生有興趣的資料就是課程與餐廳，所以建議可以從提供課程資料與餐廳資料的api開始。但我們的課程api頂多只提供個人課表查詢（read），並未提供加退選等功能（write）。這有兩個原因：
- 選課系統當初在開發時並未考量到要提供api，所以必須另外開發功能
- 假設開發者使用課程api，開發了可以讓其他使用者進行加退選的服務，若因為網路不穩、介面顯示錯誤等原因導致加退選異常，這其中的責任很難歸屬。
使用新技術
我們使用Jenkins來作為自動化流程的一部分，包含測試、打包與部署。一般學校並不會把Continues Integration、Continues Delivery和DevOps的概念納入課程，因此你不能期待工讀生有這樣的程度。我的建議是將基礎工具先建立好，直接讓工讀生使用。在Jenkins上的權限設定也要考慮過，避免一個工讀生有太多的權限。集中式和分散式
一般學校是將所有功能包在一起，成為一個官方app；我們則是將不同功能分成不同的app，Google Play。這有幾個考量：- 節省空間：讓使用者安裝他想要的功能。
- 維護方便：維護只需要改動一小部份的程式碼。
法律
教職員與學生的id
我們有個API是可以利用教職員證或學生證的卡號來做簡單的身分認證，其中學生的ID是學號，教職員的ID則是由身分證字號轉換而來。這部份需注意是否會觸犯個資法。我們與法律顧問討論後的結論是應該不會，有三個原因：- 並未顯示全校的id。
- 用途明確。
- 使用者知情。為了避免惡意開發者使用trial and error的方式，取得全校的id，必須將卡號和密碼（使用者身分證後四碼）一併傳至api進行認證，並且在一定時間內設有額度限制。
MIT License
這是一個可以商業使用的授權，我們的考量點是，若真的有學生能夠運用我們的成果做出商業化的產品或服務也無妨，倒不如說我們就是希望學生能夠運用我們的成果，做出商業化的產品與服務。當然，是否收費需要再討論。在Google for Education雲端硬碟儲存個資
因為Google for Education雲端硬碟有無限的空間可以使用，所以我們曾經也考慮過使用Google雲端硬碟來儲存資料。但因為中央大學計中有ISO 27001的認證，在這部份因為無法掌握Google如何儲存資料，也無法掌握其備份的方式等資訊，可能會違反個資法或ISO 27001的要求，所以若有將資料儲存在雲端的需求，需特別考量。不過Google for Education已通過ISO 27018的認證，也許可以修改該單位的資訊安全政策以達成此目的。
外部
開發者參與的比例不高
這裡指的是校內學生與教職員申請使用NCU API開發的比例不高。根據資料顯示，NCU API開放後一個學期，申請使用api的服務不到五個。大概有幾種可能性：
- 目前API的種類不多
- API所能提供的資料太少
- 使用API開發服務的風氣沒有像國外那麼盛行
- 沒有那麼多人有能力使用API來開發服務
- 宣傳不足
開源可以吸引人才
對於從事資訊產業的工程師來說，一個github帳號幾乎等同於一份履歷。大學計中應該都是負責處理校內的校務系統，工程師在校務系統上的貢獻很難被外界得知與量化，即使寫在履歷表內，一般企業還是會將工程師的能力打折扣；加上薪水受科技部限制難以與外界競爭；更不用說大部分都是約聘。以上種種的條件會使得一個國立大學的計中難以找到優秀的人才。若能將成果以開源的方式分享出來，因為即便無法提供高薪正職等條件，對吸引人才還是有所幫助的。不過資料取得可能就要特別留意，避免把資料庫的位置與帳號密碼上傳，或是可以像我們一樣採用API的方式取得資料。
不能完全依賴開源
因為台灣的風氣並不像國外那麼盛行，人口的比例也有差，所以即使將程式碼公開了，也不能期待隨時有人會幫忙維護，還是必須有專人維護。未來
機器可理解
提供有語意的API，讓機器可讀並可理解資料內容，例如將行政單位的資訊以json-ld的格式包裏起來。可能的情境為向人工智慧的公司註冊該單位的API endpoint，讓人工智慧來讀取公開資訊，甚至透過OAuth讀取個人資訊，提供更無縫的服務。接下來將以apple的SIRI和《機械公敵》的VIKI為例子，幫助大家想像我心目中的未來情境。
VIKI
利用這些機器可理解的API來訓練人工智慧（例如IBM Bluemix Watson），使其成為理解該機關相關事務的VIKI，最後可對使用者的問題與需求作出回應。可以與IoT結合，讓VIKI感測及管理空間內的裝置。
SIRI &VIKI
若人工智慧間有共同的通訊協定，則可以讓SIRI和VIKI彼此能夠溝通，交換資料，這樣就不用人工註冊了。情境
一個教授將出席一場在中央大學召開的研討會，車子上的SIRI知道教授有這項行程，因此在車子快接近中央大學時，通知中央大學的VIKI(通訊協定)。
VIKI知道校內確實將舉行這場研討會(API)，因此預訂距離會場最近的空車位(IoT)，並將資訊回傳給SIRI，然後通知主辦單位與會者即將到達(API)。
SIRI接收到停車位資訊後傳給車子，車子則自動開到該停車位(自動導航)。
SIRI、VIKI、感測裝置和車子，都是不同單位的產品，但是透過API、通訊協定和IoT等技術被串連在一起了。
參考影片：
How to Build Linked Data APIs with JSON LD and Hydra
Optimize Your Data Architecture for an Integrated Future
