Behind The App: The Story Of FileZilla

Among the applications I always download when first setting up a new computer is FileZilla, the humble, open source FTP client. For those of us who have run our own little websites it’s been a longtime staple of the webmaster’s toolbox.

Despite being so purely functional, I can’t help but feel nostalgic when using FileZilla. It reminds me of being a kid and trying to code HTML so that I could post cool images and GIFs on my very own website. And once the code was solid it was time to fire up the FTP software and upload to the server, the last step in publishing. Nowadays most sites can be entirely designed and maintained within a web browser, but I still keep FileZilla on hand to tinker with my own projects.

How did FileZilla come about? As a school project, actually. We spoke with developer Tim Kosse about how and why he created FileZilla some 15 years ago.

So FileZilla actually started as a school project, is that right? Were you trying to solve a problem you’d experienced with existing software, or did the inspiration come from somewhere else?

Yes, it started as a group project in the computer science course during my final year at school, almost 15 years ago. We were looking for something usable that was neither too trivial nor too big to implement and could be worked upon in parallel. Sadly I don’t remember the details anymore how we eventually settled on an FTP client.

After you came up with the idea, what was the next step?

Figuring out how to implementing the most basic set of features every FTP client needs: Connecting to a server, getting directory listings and of course uploading and downloading of files.

With the GUI design we did imitate the basic layout of other graphical FTP clients known to us. For the backed functionality we used some third-party FTP classes.

After the project’s official conclusion I continued working on it, in part because I could make use of a good FTP client myself. Gradually I added features and fixed the bugs as they surfaced. At some point I also started with FileZilla Server to complement the client.

How did you choose which platforms to target and which to ignore or wait on?

Initially FileZilla was for Windows only, it was the only platform we had sufficient experience with when we started the project. At some point however I wanted to extend onto other platforms and Linux in particular. Unfortunately due to the initial choice to use Microsoft’s MFC as GUI library, supporting other platforms would have meant a complete rewrite.

Early in 2004 I finally decided to rewrite FileZilla from scratch, [as] the old code base had become increasingly difficult to maintain and adding new features had a high chance of breaking things.

After some research I eventually settled on the wxWidgets library and started the rewrite in March 2014, culminating in the FileZilla 3.0.0 release ‘only’ three and a half years later. Not only had I severely underestimated the complexities of cross-platform development, during all this time I still had to maintain the old version until feature parity was reached. Furthermore I kept improving FileZilla Server during this time. Nonetheless, the rewrite has been a success.

What was your biggest roadblock and how did you overcome it?

It’s more like an endless collection of needless speed bumps that has hampered me most.

FTP is a rather old protocol with lots of history and legacy functionality. Parts of FTP are specified in great detail while other parts are being left unspecified. Not only are there often different means to achieve the same thing in FTP, different FTP software supports and uses different features.

In addition, FTP’s use of separate connections for control commands and data transfers makes it difficult to use behind firewalls and NAT routers, which is an additional challenge in its own right.

This leads to interesting problems: For example a server might not implement a feature correctly or a firewall in front of the server might choke on some commands. Further, FileZilla might be the only client that makes use of this command. As result, FileZilla cannot be used to exchange files with such a server.

Something like this happens almost every time I make use of an additional FTP feature or change the way FileZilla operates. In these situations I spend a lot of time and effort to determine the root cause of the problem. When this happens in other open-source FTP software I usually write a patch that fixes the issue.

Sadly it often happens with proprietary servers, firewalls and NAT routers where I can’t do anything myself to fix it, so the respective vendors have to solve the problem. It is at this precise point where my biggest roadblock lies: How to convince others that the problem is in a third-party component, especially in light of of uninformed counter-arguments that it works with other FTP clients or in a previous version of FileZilla?

While I could implement workarounds in such cases, they often come with a heavy cost and lots of added complexity. Furthermore, the underlying problem would remain unfixed.

Thus I made an important decision: I won’t implement any workarounds if it would compromise security or performance. While FileZilla doesn’t require a server to support optional features, if the server says it supports a particular feature then FileZilla in turn expects the server to handle it correctly.

Sure, at times this can be most inconvenient for affected users, especially if the server or firewall vendor doesn’t acknowledge or doesn’t want to fix the problem. Still, I strongly believe that solving the root cause of a problem is the correct thing to do.

People have a lot of options when choosing FTP software; what features were important for you when designing FileZilla?

Before deciding on implementing a new feature in FileZilla I look at whether a graphical FTP client is the right tool for the right task. There’s little value in implementing a feature that would be better suited to other types of programs. One such example would be automation and scripted transfers, I think that this would be a much better fit for a simple command-line client.

After having decided to implement a new feature, there are two primary design considerations guiding the implementation of the new feature in FileZilla.

The first is reliability. Each feature needs to work as advertised in all conceivable usage scenarios. In addition I consider security an aspect of reliability as well: A security vulnerability can be seen as software that does more than what it is intended to do. In other words, users can rely on FileZilla doing exactly what it is intended to do, no more, no less.

The second aspects is performance and scalability. Naturally FileZilla should be as fast as possible, nobody likes to wait longer than necessary on a task. When implementing a feature I always consider what happens if somebody would use it to the extreme. For example most users probably only deal with a couple thousand files, yet FileZilla has been designed to handle directories containing millions of files totaling several terabytes.

After it lived beyond its academic purpose, what was “launch” like for you? I’m guessing that it’s been kind of a slow snow ball, with more people adopting the software over time.

Yes, the initial release had been very quiet. I registered a new project on SourceForge, set the project description, uploaded the first release and called it a day.

Eventually the first users tried out FileZilla and sent valuable feedback. I kept improving FileZilla and in turn the user base kept growing with every release. I had never expected this much success, but it keeps me motivated to continue with the project. Had someone told me in 2001 that I would have millions of users, I would have called him crazy.

Fun fact: The early versions from 2001 still function on a modern Windows 10 machine.

Were there ever any thoughts of trying to sell it or monetise it somehow?

I’ve never considered selling FileZilla as a viable option. After all, with FileZilla being free open source software, redistribution is not only allowed, it is encouraged.

However I am participating in SourceForge’s DevShare partnership program to generate revenue. I understand that some users object to bundled offers, so I have given all users the freedom of choice, use of the bundled installer is entirely optional.

How do you handle user requests and criticisms effectively?

User feedback can be broadly classified into three categories: Problem reports, feature requests and generic requests for help.

Problem reports I triage immediately. If it turns out to be a bug in FileZilla it will likely be fixed in the next release.

I find it important to maintain a coherent product vision, so feature requests are dealt with differently. Many features would go orthogonal to the product vision, implementing them would quickly move FileZilla out of focus. This already filters out many feature requests. The remainder get prioritised and filed in the feature request tracker so that they can be implemented at some point.

As for generic help requests, while I do not have the time to answer each such request myself, the FileZilla forums are a good place for users to help each other.

Now, how do you split time between developing new features and managing existing ones?

I always aim to have a bit of both in every new release. On average I’d say that two thirds of my development time are spent to implement new features.

Lately however I have spent a lot of time on architectural improvements, modernising and cleaning up large portions of the code base. While FileZilla still looks the same as it always did, a lot has changed under the hood. Not only has this greatly improved the performance of FileZilla, it should also make it easier for new features to be implemented in the future.

What advice would you give to others that want to take on a similar project?

Be persistent and maintain a sharp product vision. Release early and release often to find out which of your focus areas need improvement or could be extended. Last but not least, use for yourself what you have created.

Lifehacker’s Behind the App series gives an inside look at how some of our favourite apps came to be — from idea to launch (and beyond).