Behind the Appendix: the History of FileZilla
Among the applications I always download when setting up a new computer for the first time is FileZilla , a humble open source FTP client. For those of us with our own small websites, it has long been a staple webmaster tool.
Despite being so purely functional, I can’t help but feel nostalgic when using FileZilla. It reminds me that I was a kid trying to code HTML to put cool images and GIFs on my own website. And once the code was ready, it was time to fire up the FTP software and upload it to the server, the last step in publishing. Most sites nowadays can be fully developed and maintained in a web browser, but I still keep FileZilla close at hand to tinker with my own projects.
How did FileZilla come about? Actually, like a school project. We spoke with developer Tim Cosse about how and why he created FileZilla about 15 years ago.
So FileZilla started out as a school project, right? Have you tried to solve a problem you’re having with existing software, or did the inspiration come from somewhere else?
Yes, it started as a group project for a computer science course in my last year at school, almost 15 years ago. We were looking for something useful that was neither too trivial nor too big to implement, and which could be worked on in parallel. Unfortunately, I no longer remember the details of how we ended up settling on the FTP client.
What was the next step after you came up with it?
Figuring out how to implement the most basic set of features every FTP client needs: connecting to a server, getting directory lists, and of course uploading and downloading files.
In our GUI design, we mimicked the basic structure of other graphical FTP clients we know of. We have used some third party FTP classes for the supported functionality.
After the official completion of the project, I continued to work on it, in part because I myself could use a good FTP client. Gradually, I added new features and fixed bugs as they appeared. At some point, I also started with FileZilla Server as a client add-on.
How did you choose which platforms to target and which to ignore or wait?
FileZilla was originally designed for Windows only, it was the only platform with which we had sufficient experience when we started the project. However, at some point, I wanted to expand to other platforms and, in particular, Linux. Unfortunately, due to Microsoft’s initial choice of MFC as the GUI library, supporting other platforms would mean a complete rewrite.
In early 2004, I finally decided to rewrite FileZilla from scratch, [because] old code was getting harder to maintain and adding new features might break something.
After some research, I eventually settled on the wxWidgets library and started rewriting it in March 2014, culminating in the release of FileZilla 3.0.0 “just” three and a half years later. Not only did I grossly underestimate the complexity of cross-platform development, but during this time I still had to maintain the old version until feature parity was achieved. Also, all this time I have continued to improve FileZilla Server. However, the rewrite was successful.
What was your biggest obstacle and how did you overcome it?
It’s more like the endless collection of unnecessary speed bumps that got in my way the most.
FTP is a fairly old protocol with a long history and legacy functionality. Parts of FTP are described in great detail, while other parts are not listed. Not only are there often different means to achieve the same thing in FTP, different FTP programs support and use different features.
In addition, the use of separate FTP connections for control commands and data transfers makes it difficult to use them behind firewalls and NAT routers, which is an additional problem in itself.
This leads to interesting problems: for example, the server might not implement a function correctly, or the firewall in front of the server might choke on some commands. Additionally, FileZilla may be the only client that uses this command. As a result, FileZilla cannot be used to share files with such a server.
Something like this happens almost every time I use the optional FTP feature or change the way FileZilla works. 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 problem.
Unfortunately, this often happens with proprietary servers, firewalls and NAT routers, where there is nothing I can do myself to fix this, so the respective vendors must address the issue. This is where my biggest hurdle lies: how to convince others that the problem is with a third-party component, especially in light of the ignorant counterarguments that it works with other FTP clients or a previous version of FileZilla. ?
While I could implement workarounds in such cases, they are often costly and complicated. Moreover, the main problem will remain unresolved.
Thus, I made an important decision: I will not use workarounds if it compromises security or performance. While FileZilla does not require the server to support additional features, if the server reports it supports a particular feature, FileZilla expects the server to handle it correctly.
Of course, this can sometimes be very inconvenient for the affected users, especially if the server or firewall vendor does not confirm or is unwilling to fix the problem. However, I strongly believe that solving the root cause of the problem is the right step.
People have many options when choosing FTP software; What features were important to you during the development of FileZilla?
Before deciding to implement a new feature in FileZilla, I check to see if a graphical FTP client is the right fit for the task. There is little point in implementing a function that would be better suited to other types of programs. One such example would be automation and scripting, I think it would be much better for a simple command line client.
After deciding to implement a new feature, there are two main design considerations that drive the implementation of a new feature in FileZilla.
The first is reliability. Each feature should work as stated in all possible use cases. Also, I think of security as an aspect of reliability: a security vulnerability can be thought of as software that does more than intended. In other words, users can count on FileZilla to do exactly what it was designed to do, no more, no less.
The second aspect is performance and scalability. Naturally, FileZilla should be as fast as possible, no one likes to wait longer for a task to complete. When implementing a function, I always think about what will happen if someone uses it to the extreme. For example, most users are probably only dealing with a couple thousand files, but FileZilla was designed to work with directories containing millions of files, several terabytes in size.
What was the “launch” like after it outgrew its academic goal? I guess it was kind of a slow snowball as more and more people are adopting the software over time.
Yes, the initial release was very quiet. I registered a new project on SourceForge, installed the project description, downloaded the first release, and exited.
In the end, early adopters gave FileZilla a try and provided valuable feedback. I kept improving FileZilla and in turn, the user base continued to grow with each release. I never expected such a success, but he supports me in continuing the project. If anyone told me in 2001 that I would have millions of users, I would call them crazy.
Fun Fact: Early versions of 2001 still run on a modern Windows 10 machine.
Have you ever thought about trying to somehow sell or monetize?
I’ve never considered selling FileZilla as a viable option. After all, since FileZilla is free and open source software, redistribution is not only permitted but encouraged.
However, I do participate in the SourceForge DevShare Affiliate Program to generate income. I understand that some users object to the combined offerings, so I have given all users the freedom to choose, using the bundled installer is optional.
How do you effectively deal with user inquiries and criticism?
User feedback can be roughly divided into three categories: problem reports, feature requests, and general help requests.
I sort the problem reports immediately. If this turns out to be a bug in FileZilla, it will probably be fixed in the next release.
I find it important to maintain a holistic product vision, so feature requests are handled differently. Many features will be orthogonal to the product’s vision, and implementation will quickly push FileZilla out of sight. This already filters out a lot of feature requests. The rest are given priority and entered into the feature request tracker so that they can be implemented at some point.
In terms of general requests for help, while I don’t have time to respond to every such request myself, the FileZilla forums are a good place for users to help each other.
Now how do you divide the time between developing new features and managing existing ones?
I always strive to have both in every new release. On average, I would say that two-thirds of my development time is spent introducing new features.
Recently, however, I’ve spent a lot of time making architectural improvements, modernizing and cleaning up large parts of the codebase. While FileZilla still looks the same as it always has, a lot has changed under the hood. This not only greatly improved FileZilla’s performance, but also made it easier to implement new features in the future.
What advice would you give to others looking to take on a similar project?
Be persistent and maintain a clear vision for the product. Release earlier and release more often to find out which of your priority areas need improvement or can be expanded. Last but not least, use what you have created for yourself.