在我第一次安裝新電腦時經常下載的應用程式中有FileZilla，一個簡陋的開源FTP客戶端。對於我們這些誰經營自己的小網站，這是一個長期的主要網站管理員的工具箱。

儘管如此純粹的功能，我還是忍不住懷舊時使用FileZilla。它讓我想起了我還是個孩子的時候，我試著編寫HTML程式碼，這樣我就可以在自己的網站上釋出很酷的圖片和gif了。一旦程式碼穩定，就可以啟動FTP軟體並上傳到伺服器，這是釋出的最後一步。如今，大多數網站都可以完全在一個web瀏覽器中設計和維護，但我仍然手頭有FileZilla來修補我自己的專案。

FileZilla是怎麼來的？實際上是學校的專案。我們與開發人員timkosse討論了15年前他建立FileZilla的方式和原因。

所以filezilla實際上是作為一個學校專案開始的，對嗎？你是想解決你在現有軟體中遇到的問題，還是靈感來自其他地方？

是的，差不多15年前，我在學校的最後一年，在電腦科學課程中，它是作為一個小組專案開始的。我們正在尋找一些既不太瑣碎也不太大的東西來實現，並且可以並行工作。可悲的是，我已經不記得我們最終如何解決一個FTP客戶端的細節了。

你提出這個想法後，下一步是什麼？

弄清楚如何實現每個FTP客戶機需要的最基本的一組功能：連線到伺服器，獲取目錄列表，當然還有上傳和下載檔案。

透過GUI設計，我們確實模仿了我們所知的其他圖形FTP客戶機的基本佈局。對於支援的功能，我們使用了一些第三方FTP類。

專案正式結束後，我繼續工作，部分原因是我自己可以使用一個好的FTP客戶機。漸漸地，我添加了一些特性，並修複了出現的bug。在某種程度上，我還開始使用FileZilla伺服器來補充客戶機。

你是如何選擇目標平臺和忽略或等待的平臺的？

最初FileZilla僅適用於Windows，它是我們啟動專案時唯一有足夠經驗的平臺。然而，在某個時候，我想擴充套件到其他平臺，特別是Linux。不幸的是，由於最初選擇使用微軟的MFC作為GUI庫，支援其他平臺將意味著完全重寫。

2004年初，我終於決定從頭開始重寫FileZilla，因為舊的程式碼庫已經變得越來越難以維護，新增新的特性很有可能會破壞它。

經過一番研究，我最終確定了wxWidgets庫，並於2014年3月開始重寫，最終在三年半後釋出了FileZilla 3.0.0版本。我不僅嚴重低估了跨平臺開發的複雜性，在這段時間裡，我還必須維護舊版本，直到達到功能對等。此外，我在這段時間裡不斷改進FileZilla伺服器。儘管如此，重寫還是取得了成功。

你最大的障礙是什麼？你是如何剋服的？

它更像是一個無休止的收集不必要的減速，阻礙了我最。

FTP是一個相當古老的協議，有很多歷史和遺留功能。FTP的部分被詳細地指定，而其他部分則沒有指定。在FTP中，實現同一件事的手段往往不盡相同，不同的FTP軟體支援和使用的功能也不盡相同。

此外，FTP使用單獨的連線來控制命令和資料傳輸，這使得在防火牆和NAT路由器後面很難使用，這本身就是一個額外的挑戰。

這會導致一些有趣的問題：例如，伺服器可能無**確實現某個功能，或者伺服器前面的防火牆可能會阻塞某些命令。此外，FileZilla可能是唯一使用此命令的客戶機。因此，FileZilla不能用於與這樣的伺服器交換檔案。

幾乎每次我使用額外的FTP特性或更改FileZilla的操作方式時，都會發生類似的情況。在這些情況下，我花費了大量的時間和精力來確定問題的根本原因。當這種情況發生在其他開源FTP軟體中時，我通常會編寫一個補丁來修複這個問題。

不幸的是，這種情況經常發生在專有伺服器、防火牆和NAT路由器上，我自己也無能為力，所以各個供應商必須解決這個問題。正是在這一點上，我最大的障礙在於：如何說服他人問題出在第三方元件上，特別是考慮到它與其他FTP客戶機或FileZilla的早期版本一起工作的未知反駁？

雖然我可以在這種情況下實現變通方法，但它們通常會帶來高昂的成本和許多額外的複雜性。此外，根本問題仍然沒有得到解決。

因此，我做了一個重要的決定：如果它會損害安全性或效能，我將不實施任何變通方法。雖然FileZilla不需要伺服器來支援可選功能，但是如果伺服器說它支援特定的功能，那麼FileZilla反過來希望伺服器能夠正確地處理它。

當然，有時這對受影響的使用者來說是最不方便的，尤其是當伺服器或防火牆供應商不承認或不想解決問題時。不過，我堅信解決問題的根本原因是正確的。

人們在選擇ftp軟體時有很多選擇；在設計filezilla時，哪些特性對您很重要？

在決定在FileZilla中實現一個新特性之前，我先看看圖形FTP客戶機是否是執行正確任務的正確工具。實現一個更適合其他型別程式的特性沒有什麼價值。其中一個例子是自動化和指令碼傳輸，我認為這更適合於簡單的命令列客戶機。

在決定實現一個新特性之後，在FileZilla中有兩個主要的設計考慮來指導新特性的實現。

首先是可靠性。每個特性都需要像在所有可能的使用場景中宣傳的那樣工作。此外，我還將安全性視為可靠性的一個方面：安全漏洞可以被視為比預期做的更多的軟體。換言之，使用者可以依賴FileZilla做它想要做的事情，不多不少。

第二個方面是效能和可伸縮性。當然，FileZilla應該盡可能快，沒有人喜歡在一項任務上等待超過必要的時間。在實現一個特性時，我總是考慮如果有人把它用到極致會發生什麼。例如，大多數使用者可能只處理幾千個檔案，然而FileZilla被設計成處理包含數百萬個檔案的目錄，這些檔案的總容量為數TB。

在它超越了學術目的之後，“發射”對你來說是什麼樣的？我猜這是一個緩慢的雪球，隨著時間的推移越來越多的人採用了這個軟體。

是的，最初的版本非常安靜。我在SourceForge上註冊了一個新專案，設定了專案描述，上傳了第一個版本，並宣佈今天結束。

最終，第一批使用者試用了FileZilla併發送了有價值的反饋。我不斷改進FileZilla，而使用者群也隨著每個版本的釋出而不斷增長。我從來沒想過會有這麼大的成功，但它讓我有動力繼續這個專案。如果2001年有人告訴我，我將擁有數百萬使用者，我會說他瘋了。

有趣的事實：2001年的早期版本仍然在現代windows10機器上執行。

有沒有想過要把它賣掉或以某種方式賺錢？

我從來沒有考慮過賣FileZilla是一個可行的選擇。畢竟，由於FileZilla是免費的開源軟體，重新分發不僅是允許的，而且是鼓勵的。

不過，我正在參與SourceForge的DevShare合作計劃以創造收入。我知道有些使用者反對捆綁服務，所以我給了所有使用者選擇的自由，使用捆綁安裝程式是完全可選的。

你如何有效地處理使用者的請求和批評？

使用者反饋可以大致分為三類：問題報告、功能請求和一般幫助請求。

問題報告我馬上分類。如果它被證明是FileZilla中的一個bug，那麼它很可能在下一個版本中被修複。

我發現保持一致的產品願景是很重要的，所以特性請求的處理方式是不同的。許多特性將與產品願景正交，實現它們將很快使FileZilla脫離關註。這已經過濾掉了許多特性請求。剩下的部分將被劃分優先順序並歸檔到特性請求跟蹤器中，以便在某個時候實現它們。

至於一般的幫助請求，雖然我自己沒有時間回答每個這樣的請求，但是FileZilla論壇是使用者相互幫助的好地方。

現在，您如何在開發新功能和管理現有功能之間分配時間？

我總是希望在每一個新版本中都能兼顧這兩個方面。平均來說，我的開發時間的三分之二都花在了實現新特性上。

不過，最近我花了很多時間在架構改進、更新和清理大部分程式碼庫上。雖然FileZilla看起來仍然和以前一樣，但在引擎蓋下發生了很多變化。這不僅大大提高了FileZilla的效能，還應該使將來實現新特性更加容易。

你會給其他想從事類似專案的人什麼建議？

堅持並保持敏銳的產品視覺。儘早釋出並經常釋出，以找出哪些重點領域需要改進或可以擴充套件。最後但並非最不重要的一點，用你自己創造的。

在應用程式背後，我們可以從內部瞭解到一些我們最喜愛的應用程式是如何從創意到釋出（以及以後）的。有你想見的人嗎？給安迪發郵件。