2020中文學生開源年會講者系列專訪之三：Nova&Benny&Keshane

2020中文學生開源年會將於10月18日以線上方式舉行，在本次活動之前，開源年會組委會特別推出講者系列專訪：從即日起至10月18日，我們將為每位講者推出一篇獨家專訪。

記者專訪

記者：
非常感謝各位能夠抽空參與我們的釆訪，請問各位能先做一個簡單的自我介紹嗎？
@Benny：
這個問題啊，很難回答啊。自我介紹這種東西是最難說的了簡單的說，我是：一位不知名博主，熱愛開源與自由，菜，社畜一枚，已經是老叔叔老阿姨了。
@Nova：
是一個喜歡折騰的菜雞開發者，寫代碼能力不怎么樣，鬼點子特別多。
@Keshane:
又到了我最討厭的自我介紹環節，我是一個菜雞開發者，剛剛成為社畜，老二次元了。

記者：

各位演講的題目是：WebP Server Go,請問各位能向我們的讀者做一個簡單的介紹嗎？

@Benny：
有請我們的總設計師Nova來介紹一下！
@Nova：
WebP是一種同時提供了有損壓縮與無損壓縮的圖片文件格式，目標是減少文件大小，但達到和JPEG格式几乎相同的圖片質量。生成單張 WebP 圖片非常簡單，批量轉換也沒太大難度。但是如果讓點的圖片可以無痛地以 WebP 格式輸出，比如我們的博客上有 100+ 張圖片轉換該如何操作呢？部分云服務商提供了轉換服務，對於個人站點而言，為了同樣在不改變站點原始 URL 的的情況下將圖片壓縮 WebP 格式輸出，做到節省流量+提升頁面加載速度的效果，WebP Server Go 應運而生。

使用 Go 編寫的 WebP Server 是一個單一的 binary，性能優異，并且可以無縫轉換JPG/PNG為webp。只需要一次配置即可在不改變 URL 的情況下將站點圖片以 WebP 格式輸出，唯一改變的只有 content-type 和 length，無痛加速站點。原來下載10M的圖片要花10秒鐘，使用WebP Server Go ,只需要一秒鐘就夠了。”

記者：
在瀏覽了各位在博客上發表的 “讓站點圖片加載速度更快——引入 WebP Server 無縫轉換圖片為 WebP” 后，我的個人理解是各位復現了的Cloudflare所提供的Polish功能，并將其開源，請問是這么一回事嗎？

@Nova:
對的，最初是閱讀到了朋友 BlueCocoa 的文章之后開始有了將站點上的圖片轉化為 WebP 輸出的想法，由於不想手動處理圖片轉換，所以需要有一個在不改變 URL 的情況下直接輸出 WebP 的功能，在調研的過程中發現了 Cloudflare Polish，由於 Cloudflare 是一個中心化的平台，考慮到有很多場景下我們沒法使用 Cloudflare 或者希望對這個轉換的過程有一個更加可控的部署方案，所以開始有了這個 WebP Server，慢慢我們發現這個需求可能不少人都會有，於是就把它開源了。
@Benny：
其實Nova還有一個想法，Cloudflare提供的那些Pro、Enterprise才有的功能，咱都想給復刻一遍。

記者：
各位當初選擇Go語言除了在性能上的考慮外，請問還有一些什么其他的原因呢？以及請問Go在這個項目上的表現是符合預期的嗎？

@Nova:
最初是用 Node 的 Express 寫的 WebP Server Node，之后開始自學 Go 之后打算通過一個實際項目開始學習，就嘗試用 Go 寫了 WebP Server Go 的初版，當然，寫的很糟糕啦，后來有了 @BennyThinks 和 @muzi 的加入之后，慢慢 Go 版本的功能也越來越多了，關於性能部分的話，有請 @BennyThink 來回答。
@Benny：
選擇Go的原因，從我的角度來說，第一個原因是Go具有非常強的交叉編譯能力，進一步說，我覺得也是Go的最大亮點：Go編譯出來的程序，本身就只有一個單一的二進制文件，几乎無任何依賴，什么pip install、npm i根本不需要，拿了就能跑。你看，對你的OS一點污染都沒有，不想要了？直接刪文件就好了。
并且，理想情況下Go可以直接跨平台、跨架搆交叉編譯，一台Mac直接就能編譯出arm64的Linux的二進制文件——甚至都不用像C那樣安裝交叉編譯的toolchain。這一點就已經非常優秀了。
第二個原因是，Go的性能很好，非常接近C/C++，原生支持并發，自帶了很多網絡相關的標准庫。本來這個東西就是用來提高網站圖片的加載速度的，此時如果在因為語言的性能限制，導致速度反而變慢，這不就慘了嘛。因此，用Go來開發高性能網絡服務程序是非常適合的。
還有一個隱性原因，說出來怕讓人笑話，用Go拿來練手。
第二個問題，從使用者的角度上來說，我覺得是符合預期的。同樣也是一個單一的几乎無依賴的二進制文件嘛，用戶大概率是感受不出來什么差異的。
但是從開發者的角度來看，還是稍差些的：目前并沒有任何使用Go實現的WebP encoder，因此目前也只能使用CGO的方式來使用libwebp的部分代碼，這也使得Go的交叉編譯能力有些折扣。不過也還可以接受，問題不大。

記者：
請問各位認為WebP格式是否在未來將會成為Web圖片格式的主流甚至是世界圖片格式的主流呢？

@Nova:
我認為會，不過其實未來的方向并不一定需要是 WebP，我們做的是提供一個易用的橋梁，幫助站長（也包括我們自己）優化自己的站點。
@Benny：
高貴的蘋果已經在iOS14和macOS Big Sur中添加對WebP的支持了。尤其對於iOS來說，所有瀏覽器都是使用內建的Webkit，所以對於WebP來說最后一塊絆腳石已經開始有被解決的跡象了。所以假以時日，WebP應該會得到更好的發展。

記者：
博文中的Afterword中提到了《史蒂夫·喬布斯傳》中的一段話，請問各位認為這段話與開源運動之間是否存在某些聯系呢？

@Nova:
「我們很多人都想回饋社會，在這股洪流中再添上一筆。這是用我們的專長來表達的唯一方式——因為我們不會寫鮑勃·迪倫的歌或湯姆·斯托帕德的戲劇。我們試圖用我們僅有的天分去表達我們深層的感受，去表達我們對前人所有貢獻的感激，去為這股洪流加上一點兒什么。那就是推動我的力量。——《史蒂夫·喬布斯傳》」
同理，我自認為暫時沒有能力能像 Google 一樣做出一個規范，讓 Web 更快，也沒法像 Cloudflare 有一個龐大的網絡為眾多免費用戶提供 CDN，我們能做的是提供一個橋梁，讓盡可能多的用戶可以無痛地，快速地用「下一代圖片格式」來輸出站點內容，這就是我們能帶來的。

記者：目前許多學生開源項目的開端是同學們的學習過程&自娛自樂，有人認為這樣的代碼浪費了資源，因為其并沒有在某些領域起到了推動作用，只是一堆“死代碼”，請問各位是如何看待這樣的情況的呢？

@Nova：
我的想法是這樣的，學習過程和自娛自樂肯定沒問題，但是如果評估一個項目的好壞的話還是需要考慮這個項目是否解決了什么痛點。舉一個反例吧，目前網上有非常多的「博客平台」和「開源后台框架」，外觀都看上去非常花哨，Star 也會很多，但是如果我們稍微深究一下：這個項目是否有解決什么痛點，是否完成了其他同類著名項目中沒有做到的點，如果以上兩個問題都沒有一個非常明確的話回答的話，那的確只是一個（可能 Star 非常多的）「死代碼」而已。

WebP Server Go 的目的在於「在不改變 URL 的情況下對原圖進行轉換并輸出 WebP 格式的圖片」，這一點目前只有 Cloudflare 實現了類似的功能（國內有些 OSS 也有，但是還需要給圖片加 Parameter ，顯然不是一個「無侵入性」的方案），但是它們沒有開源，而且必須使用他們的服務，我們的是開源的。
我們相信在這個小方向上我們的確推動了一些，讓整個 Web 變得更快一些了。

@Benny：
如果說“開源”是把代碼push到GitHub的話，那么除了自娛自樂等目的之外，還有一個比較少用的目的：備份。
對於大部分人來說，“在某些領域推動發展”這個要求有點太難為人了，但是很多情況下，如果我開源的代碼，能夠幫助其他人，能夠解決一些實際的問題，那么還是多少有些存在的價值。“彼之砒霜，吾之蜜糖”，某些“死代碼”也許真能幫到某些不同層次的人呢。
寫代碼是熱愛，寫到世界充滿愛。我開源，是用愛發電的呀！

@Keshane:
開源項目還是要看是什么目的吧，也不能要求任何人都能夠在某些領域起推動作用吧。舉例來說，開源領域既有類似chromium這樣的大神級項目，也有非常多相似“XXX博客系統”這樣的項目，后者對整個行業的推動作用肯定比不上前者，但是后者依然能夠幫助到很多人。有許多類似的項目都沒有解決太多的痛點，但確實幫助了很多有需要的人，不然也不會有太多的star（買的除外），我認為只要不管項目如何，只要能夠幫助到他人，就不能稱作“死代碼”。

以下通信方式為學生開源年會的官方聯絡方式，敬請關注：