New API docs

Up until today, fman's API documentation consisted of a very short list of available functions without any examples or explanations. In the past two weeks, the docs were finally fleshed out. They're very comprehensive now and provide lots of examples. Check them out!

Zip support in fman

fman 0.7.0 was just released. It is the first culmination of two months of hard work!

The major new feature is Zip file support in fman. You can use the new Pack command to create a Zip archive of the selected files:

fman's Pack command to create Zip archives

The new command can be launched with Alt+F5 (or Cmd+F5 on Mac). Or (as always) via the Command Palette.

Once you have a .zip file, you can open it like any directory:

fman displaying the contents of a Zip file

Copying, cutting, deleting files and many other operations are supported just as if the .zip file were a normal directory.

This release features a completely new file system backend for fman. It will make it possible for everyone to add new file systems (Dropbox, (S)FTP, ...) via fman's plugin API. The original goal was to make Zip support and the new API available in one release. But too much time has already passed since the last release (by fman's standards, anyway). So it's better to make this useful addition available to you, and release a new version with the enhanced API later.

The new file system backend enables many other small improvements and bug fixes. For a detailed overview please see the Changelog.

Broken plugins

As you can see in the right side of the above screenshot, the location for "inside" the Zip file is zip://.... This hints at the new file system backend. Every file and folder in fman is now identified by a URL. Previously, files were located by their path, say C:\test.txt. This has now become file://C:/test.txt.

This change was necessary to make fman support other file systems. But it breaks some plugins which don't yet know how to handle URLs. If you use plugins, you may have to update or remove some of them. To remove a plugin, you can write Remove plugin into the Command Palette to select the plugin which you wish to uninstall:

  • Remove plugin


More and more often, people take the time to email me that they really like fman:

Excellent product! Henning
I immediately jumped on getting the subscription for all your hard work. [...] I just love the product. I didn't think twice :) Santosh
Just wanted to say I appreciate the work you've put into fman. I think it's a really great product. I also appreciate the email updates. Cody
Great news, keep up the hard work Michael!
Nathaniel on the upcoming new file system implementation

fman is not yet financially viable. My girlfriend thinks I should work on something else. So do my marketing friends. I don't care. I deeply believe in fman's vision. Emails like the above tell me that I'm on the right tracks. Also, each license sold is a sign that fman is going in the right direction.

In a newsletter I sent out a few days ago, I explained that I'm still working hard on fman's new file system backend. It will for instance make it possible to implement ZIP support. I'm hoping for a first release in November. Once it is out, I will raise fman's prices to roughly 1.5x of what they are now. fman comes with an optional updates subscription. I also promised in the email to never raise its price for existing subscribers. So if you buy fman with upates now, you can eternally lock in the cheap price of $/€ 12 for updates when other people will be paying $/€ 17 or more. Such a good deal!

Updated Zen

Work is in full swing on the new file system implementation of fman. It will make it possible to implement ZIP file support, (S)FTP, etc. Best of all, it will allow you to add support for your own file systems via fman's scriptable plugin system. Until the new implementation is ready, I thought I'd update an item on the web site that has been on the back of my find for a while.

The Zen of fman is an opinionated list of principles that guide the file manager's design:

Looks matter.
Speed counts.
Extending must be easy.
Customisability is important.
But not at the expense of speed.
I/O is better asynchronous.
Updates should be transparent and continuous.
Development speed matters more than program size.

The last item

Development speed matters more than program size

holds true of fman, but has never quite been as "on-point" as the others. I've decided to replace it by:

Don't reinvent the wheel.

In a way, this principle encompasses the previous version. It says to use an existing solution if it exists. Such a solution usually includes more functionality than needed, thus unnecessarily increasing fman's program size. But at the same time, not having to create it from scratch saves a lot of development time.

(An argument could be made that static linking lets you have the best of both worlds by only including those parts of a library that are actually used. But fman is based on the Python programming language where that is less of an option.)

The benefit of the new principle is that it explains more decisions behind fman. For example, some other file managers have a built-in terminal, a built-in text editor, file viewer, music player, etc. Some users really like the "integrated feel" of such solutions. My gripe with them is that I could spend years programming a built-in terminal or a file viewer, and they would still never be as good as tools that have been on the market for many years. I think it's much more important to focus my efforts in those areas where fman is truly able to excel. Like scriptable file system support!

Since the last post, there have been five new releases of fman. As usual, you can check out the Changelog to see what's new.

fman 0.6.4

fman 0.6.4 is out. It fixes a few small bugs. For details, please see the Changelog.

The big project that's currently underway is to rewrite fman's backend for file handling from scratch. This will make it possible to add support for other file systems (ZIP files, FTP, etc. etc.). It will also enable me to fix some long-standing bugs in fman. It's a big task and will take a while. Stay tuned!

Live coding video of fman

fman 0.6.3 came out last week and I thought it would be fun to show you a video of how I release new versions. The video shows all steps of a release: Deciding which feature to implement, changing fman's source code and uploading the new version to fman's web site. Enjoy!

Third-best Windows Explorer replacement

MakeUseOf wrote an article about the best Windows Explorer alternatives. They chose fman as third-best! Thank you, MUO. Working hard to make it #1. A good example of this are the three new versions of fman released in the last week. For an overview of their improvements, please see the Changelog.

Dual pane file manager history

Do you remember Norton Commander?

It was one of the first dual-pane file managers – and probably the most influential one. John Socha created it in 1984, the year Apple famously launched the Macintosh:

John was 26 when he created NC. He had been commissioned to write a book about utility programs and needed an example. This "example" turned into a world-famous file manager. The reason it is called "Norton" is that John joined Peter Norton Computing and completed the first version there.

A fun fact about John is that he also invented screen savers. NC included one as well:

John works at Microsoft now. He even writes the odd blog post about jQuery.

Norton Commander set the tone for decades of file managers to come. One clone of NC that is still in use today is Midnight Commander:

Like most dual-pane file managers, it gets the shortcuts from Norton Commander: F5 for copying files, etc.

Midnight Commander was created in 1994 by Miguel de Icaza. Like John, Miguel made his mark on other areas of computing as well: He later co-founded the GNOME project(!)

On Windows, a clone of NC that is still popular is FAR:

Does the name FAR remind you of a popular archive format? That's not a coincidence: Its creator Eugene Roshal also invented RAR and WinRAR.

Even before FAR, the first dual-pane file managers with a GUI appeared. In 1993, Christian Ghisler released what would later become Total Commander for Windows:

TC was originally called "Windows Commander". You can guess what happened: Mr. Ghisler received a friendly letter from Microsoft asking him to change the name.

Since then, there have been many iterations on the same theme. (Last I counted there were 98 dual-pane FMs in existence.) However, I would argue that the niche has not seen much innovation in the last 20 years.

Sublime Text has shown that it is possible to revolutionise even old niches like text editors. Wouldn't it be great if we could have the same surge of innovation for file managers?

fman is my attempt to answer this question. It's a dual-pane file manager that combines the best ideas from Total Commander and Sublime Text. If you enjoyed reading this article, then maybe you would like to check it out!

Discuss this post on Hacker News.

Don't just use Stripe

In the beginning, fman used Stripe as its sole payment processor. This made it possible to buy fman by credit card. But people repeatedly wanted to pay with PayPal as well, because they don't want to give their payment details to a random site.

PayPal was integrated into fman's Purchase page last month. Since then, more than half of sales were processed by PayPal – even though it isn't the default option! This means that the blood, sweat and tears that went into setting up PayPal paid off.

If you are selling to consumers, I recommend offering PayPal as a payment option. If you don't want to spend days wrestling with PayPal's horrible APIs, I've heard that Braintree and FastSpring let you accept PayPal as well and are easier to set up. Good luck!

Back on track

After losing my laptop last month, I'm happy to report that fman is back on track: Version 0.5.3 is out. This release fixes the broken Arch Linux package and brings a few usability improvements. For instance, there is a new command for deleting files immediately instead of moving them to the Trash:

Most of the improvements were a direct result of user feedback. For a detailed overview, please see the Changelog.

It took a while to set fman's development environment back up. Two reasons: First, Dell make it incredibly difficult to buy a laptop. Second, fman's main development used to be on macOS; Now it will be on Linux. My new laptop (a Dell XPS) is gorgeous though:

Thankfully, fman is cross-platform and looks great on Ubuntu ;)

To the next release!

Lost laptop

I took the train in Austria (my home country) on Friday. I had to change trains once. Once I had made myself comfortable on the second train, I wanted to open my laptop to resume working.

Except I no longer had my laptop on me.

I had carried it in my hand to change trains. It slowly dawned on me that I must have misplaced it somehow. Stress.

I spoke with the conductor of my current train. He was kind enough to call the conductor of the other train I'd been on. Unfortunately, he said that the laptop wasn't there.

So I got off at the next stop an hour later to make my way back to the station where I had changed trains. One train going in the right direction was just leaving. I ran to catch it but missed it by 30 seconds.

I took the next train back. On the way, I tried to recollect where I'd last had the laptop. I had gone to a shop to buy a drink, but couldn't remember whether I'd still had the laptop there.

The manager of the shop was very friendly. He looked at the footage from the security camera and was able to see that I hadn't had the laptop on me when I entered the shop. Since I had gone to the shop straight after getting off the first train, that most likely meant that I had simply left the laptop on the first train. The fact that its conductor couldn't find it means (I think) that someone simply saw the unattended laptop, a nice MacBook Pro worth $1,500, and took it.

Now, after the weekend I was able to call lost and found. They again said that nobody had turned the laptop in. By now I think the chances I'll ever see it again are pretty much 0.

The good thing is that I have backups of everything. I won't have lost any data. But the thought that someone else has my data now (my Chrome sessions etc.) is pretty horrifying. I have to change all my passwords etc.

I'm working on borrowed a Microsoft Surface Pro in the meantime (thanks, Mum). It's actually a pretty decent machine with a nice screen. But its 4 GB of RAM are way too little to operate virtual machines, which are required for developing fman across OSs. So I ordered a new machine.

I looked at getting another MacBook, but the prices are just ridiculous. So, since I'd always wanted to try Linux as my main OS anyways, I've now ordered a Dell XPS 13". It's hailed as one of the (if not the) best Linux laptops. It's quite cool actually, because the laptop I lost was my first Mac. One of the reasons I switched from Windows was that I wanted to see what other OSs are like. Now I have a chance to learn about the OS that's still missing from my collection: Linux.

I have not decided on a Linux distribution yet. The XPS 13 comes pre-installed with Ubuntu but I may be looking for something more minimalistic. We will see.

If you have a laptop, I highly recommend you encrypt its local disk. I never thought this necessary, but now I know it is. Obviously, you also want to have regular backups of everything.

For fman, this is more an annoyance than the end of the world. Thank god I have good backups. It will take a few days until I'm fully up to speed again. But I promise I'll be back with a vengeance!

(It's funny actually - Due to my Austrian accent my friend in the UK always wanted me to say the classic Schwarzenegger line "I'll be back". Well, there you have it.)

PayPal for SaaS: 99 problems

Say you have a SaaS business. You're happily using Stripe to charge customers. But some people (particularly consumers) keep asking you to let them pay with PayPal; Either because they don't have a credit card or because they don't want to trust you with their data. That's bad news. What took you hours to set up in Stripe will now take you days with PayPal. This is the story of how you'll be spending those days.

First, you'll go to PayPal's Developer site. It's titled "PayPal Developer Experience". You will eventually find that the choice of the word "experience" is surprisingly accurate.

The Developer page presents you with a few options. None of them are actually what you want – but there is no way for you to realise that now. "Express Checkout" sounds good. "Braintree Direct" supposedly lets you "start accepting payments with just a snippet of code". Sounds great too! But you don't know who or what Braintree is, so decide to go with the former.

Express Checkout

PayPal's Express Checkout site says:

Express Checkout is a solution for merchants who currently accept credit card payments online and would like to add PayPal as a payment option.

Describes our requirement perfectly! So you read a few docs and find out that it's basically like Stripe's Checkout. It opens a popup where your customers can authorize the payment:

Except that unlike Stripe, which lets you open the popup whenever it makes sense in your checkout process, PayPal legally requires you to place this beauty of a button (or one of its close variants) on your page:

So with Express Checkout, you can't use your own buttons. You must use the ones provided by PayPal.

"Okay, no big deal", you think and create a first prototype. The examples provided by PayPal are all for single (ie. non-recurring) payments. To keep it simple and get the prototype up and running quickly, you decide to follow the examples for now and worry about recurring payments later.

Everything's a little more cumbersome than in Stripe. For instance: Stripe gives you two API keys, one for testing and one for production. Depending on which key you use, Stripe knows if it's a live payment. PayPal on the other hand always requires you to supply both keys and then set a special variable that indicates which one you want to use:

    env: 'production', // Or 'sandbox'
    client: {
        sandbox:    '...',
        production: '...'

This means that your test environment must know your production key and vice versa. I'm not huge on security but it doesn't sound great. And it's certainly more repetitive than it should be.

Another, maybe more serious security issue: PayPal suggests the following code for executing a payment:

      onAuthorize: function(data, actions) {
          return actions.payment.execute().then(function(payment) {
              // The payment is complete!
              // You can now show a confirmation message to the customer

Note that this all happens on the client. In other words, PayPal's onAuthorize callback makes you believe that the payment was successfully executed. But what if the customer simply executes the "success" JavaScript code manually? If you don't want to open yourself up to such "fake" purchases, your app must confirm each payment with PayPal's servers. The docs make no mention of that.

Anyways, you realise all that and after maybe two to three hours in total, your prototype happily processes payments in a test environment. Time to generalise it for recurring payments.

Except, it's not possible.

Express Checkout only supports one-time payments. It's not that PayPal can't do subscriptions or that the necessary calls would be that different from those for single payments. They're simply not implemented in the Express Checkout API. A few "experiences" the wiser, you're back to square one.


PayPal's REST API supports recurring payments. It too is more cumbersome to use than Stripe's. There are official Python bindings. That's nice. But they feel more like a computer-generated wrapper than a native implementation. Everything requires or returns dictionaries. For instance:

    "mode": "live", # sandbox or live
    "client_id": "...",
    "client_secret": "..."

Why not simply:

    client_secret: "..."

Okay, no big deal. Similarly: Did you spot the little inconsistency? For Express Checkout above, we had to supply the env: 'production' parameter to indicate whether we are in a testing environment. Now, the parameter is 'mode': 'live' – same meaning but different names. It's little things like this that keep you busy in the days you're wrestling with PayPal.

There a few more gems to complete the story. If you've seen enough of the creativity of PayPal's developers, skip to the Summary.

Executing a single payment via PayPal requires a surprising number of steps:

  1. Create a Payment object. You have to pass a dictionary with lots of arcane values.
  2. Call payment.create(). This contacts PayPal's servers and sets an approval_url hidden deep in a dictionary/list of the payment object. You can't just access this variable. You have to iterate over the list to see if the approval_url is actually there.
  3. Redirect the customer to the approval URL.
  4. After the customer has approved the payment, PayPal redirects her to a return_url which you specified when creating the Payment object. It doesn't seem to be mentioned in the docs, but PayPal appends ?token=... to the URL to let you identify the payment.
  5. Retrieve the payment via the token and call payment.execute().

Stripe can do the above in two steps. Why so complicated, PayPal?

It's even worse for subscriptions. You can't just say "Charge this customer $10 per month". You have to create a Billing Plan, which is like a template for a subscription contract. Then you have to create a Billing Agreement which references the Plan and is like a signed copy of the contract. Now suppose you want to offer varying discounts. You can't just store the amount to be paid in the Billing Plan, because it will differ for each customer. So you have to store it in the Billing Agreement. But then, what's the point of having a Billing Plan? It's not like it lets you say "now change the subscription price of all existing customers". Because Billing Plans can't be changed once they're active.

Think we're done? There's more. Error handling! Ideally, you'd like one way – and only one way – of finding out whether an error occurred. At least in the official Python SDK, PayPal forces you to handle errors in two different ways:

    agreement = BillingAgreement.execute(token)
except ConnectionError as e:
    # Handle connection error
if agreement.error:
    # Handle other errors.

Why, PayPal, why? Things like this take trial and error to figure out and are completely unnecessary.


It's no wonder that Stripe is so successful, given that PayPal takes an order of magnitude longer to set up. Where PayPal still has the edge is brand recognition and trust among consumers – deserved or not. If you are selling to consumers, it is likely that accepting PayPal will boost your sales. Otherwise, stay away from them. They're not deserving of your business.

One second faster on Mac!

fman 0.4.9 is out. It now starts one second faster on a 2014 MacBook Pro!

I wish I could say that this speed up was afforded by ingenuity and hard work. But no. It's more of a case of "be less stupid".

For lack of better options (or so I thought), I had developed a library to measure execution time in the Python programming language. I mentioned it in a thread on Hacker News. Another user pointed out that Python already has this functionality built-in. Playing around with it for two minutes unearthed a way to achieve the speedup. Nice!

To be fair, hardly any time has been spent on making fman faster so far. The main reason is that other things such features and bug fixes have been more important. There are certainly other low-hanging fruit for making fman faster. But all in due course! For now, enjoy the first stage of fman's improved performance :-)

Welcoming Andrew

Today, we're happy to announce that fman's team size has effectively doubled. Grand words for saying that the number of members grew from one to two 😄 Here we are talking on Skype, Andrew in the center and Michael in the top right:

Andrew initially found fman through a thread on Hacker News. Despite being one of hundreds of apps / products in that thread, fman immediately caught his eye. Seeing its potential, he got in touch. Several email and Skype conversations ensued, and today we officially start working together.

Andrew will focus on link building and marketing while Michael keeps developing the product. For you as an fman user, the increased team size means a more stable and faster growing product. So good news! :-)

"Get Info" on Mac

The "Get Info" dialog in Finder on Mac displays a file's properties:

Several people asked for this feature to be implemented in fman as well:

(By the way, this is a screenshot from fman's issue tracker. It now displays the number of votes for each issue. Everyone can vote on issues by leaving a 👍 on their description.)

The feature has just been released as part of fman 0.4.6: Simply press ⌘+I to open Finder's Get Info dialog for the selected files. This dialog is extremely powerful. The downside is that Finder needs to be brought to the front in order for you to see the window. It would be much nicer if this were not the case. But it's simply not possible. Some other file managers implement their own (less powerful) "Get Info" dialog for probably this reason. Maybe fman will do the same some day. Until then, you get a lot of power – at the hopefully not too large cost of an extra Cmd+Tab.

As always, any feedback you might have is highly appreciated. Just get in touch or share your thoughts / votes on the issue tracker :-)

Desktop app funnel optimization

The Metrics implementation introduced last month is providing the first insights. Of the people who download fman, only 50% actually install and start it. That sounds low, but seems to be in line with other desktop apps. Of the remaining 50%, only one fifth (10%) use fman more than once in the first week after download.

That makes it clear where work is needed: fman's onboarding needs to improve so more first-time users stick around.

Interestingly, this is not the conclusion you'd reach if you just listened to feedback from users. People ask for features, report bugs etc. But the vast majority of people never take the time to give feedback. They simply don't keep using fman.

That isn't to say that feedback from users isn't relevant. It is and has shaped fman as it is today tremendously. It's just that fman needs to get the basics right for sustained growth. Plus, improvements for first-time users benefit existing users as well.

Creating a novel product is a little like playing a computer game with various stages. fman has completed the MVP, traction, and initial sales levels. Now it's about growth. A good funnel is vital for this, and (I believe) more important than additional marketing right now. That will come at a later stage, in a level probably best called "scale".

If you are interested in fman's journey, follow me on Twitter. You may also want to check out fman, especially if you are a developer. It's a dual-pane file manager that lets you work with files much more efficiently than Finder on Mac or Explorer on Windows.

fman is out on Arch Linux

After many requests from users, fman is finally available on Arch Linux. Here's what it looks like on KDE:

The Arch implementation isn't just a shallow "here are the binaries" solution. Quite the opposite: fman fully integrates with pacman, Arch's package manager. This is especially important because Arch is a rolling-release distribution with a strong emphasis on continuous updates.

You can obtain fman from the Arch User Repository as follows:

git clone
cd fman
makepkg -si

A slightly faster alternative is to download the pre-built package and install it with:

pacman -U fman.pkg.tar.xz

To enable automatic updates for fman, you can use the following commands:

pacman-key --keyserver hkp:// -r 9CFAF7EB
pacman-key --lsign-key 9CFAF7EB
echo -e '\n[fman]\nServer =' \
  >> /etc/pacman.conf

A cool feature of the implementation is that it uses pacman's dependency mechanism for fetching (amongst others) the Qt library. If you are using Arch with KDE (and thus already have Qt), this means that no unnecessary libraries are installed.

Possibly an even greater advantage is that dependencies managed by pacman are guaranteed (or at least more likely) to work on your exact system. In particular, the new release fixes at least one bug that was caused by incompatibilities between fman's Qt version and the version present on recent KDE builds.

A pleasant surprise during the implementation was that fman had already been added to the Arch User Repository by an fman user, Dmitry Romanov. His listing was expanded for better integration into pacman. Further, it is now automatically updated whenever a new version of fman is released. Thank you for the original upload and for giving me write access to the package, Dmitry!

This was my first foray into the World of Arch Linux. Arch has a unique approach and it's been a very interesting experience. Nevertheless, I'm still new to it. If you feel I have made a mistake, please let me know.

Finally understanding Sublime Text's pricing

I've always wondered why Sublime Text is so expensive. Sure, it provides a lot of value. It's a fantastic piece of software. But for most individuals, 70$ is not nothing. Especially when you can cancel the sporadic "please buy me" dialog so easily.

That's the point! ST's real customers are not individuals like you and me. They're companies that don't care about 70$ and buy licenses in bulk. Think of banks. That's where the money lies.

I just got my ST license. But if I may put forward a suggestion to the Sublime team:

Have a sale: One day only. Licenses for $25 instead of $70.

That one sale will get individuals to buy and easily bring tens of thousands of dollars.

If you like Sublime Text, you may also be interested in fman. It's the first file manager that integrates ideas from Sublime Text.

How much money does fman make?

An interesting question, isn't it? ;-)

It may not be a good idea to write this post. The existing competition got wind of fman. Other people have started to create fman clones. This "negative attention" is the flip side of the interest fman is getting recently.

So why share sensitive numbers? This blog has always been very open. It shouldn't stop just because others are watching. Unless you are the competition, I think you are reading this because you want to follow fman's story. This post is for you.

This commitment to transparency is inspired by people like Pieter Levels. He's a young and very successful internet entrepreneur. In fact, he wrote about transparency just two weeks ago. He argues people appreciate it when you present yourself honestly, without creating an artificial "image" of yourself / your startup. He uses this video as an example:

It's a pretty good tune! And I bet you didn't expect to see a rap video on a file manager blog today ;-) Also very cool is that Pieter recently started using fman.

fman has sold 232 licenses so far. Some were sold in USD, others in EUR. At today's exchange rate, it would be $3199 before Stripe fees and taxes. I've so far spent 1382 hours working on fman. This puts my hourly wage (before fees and taxes) at a rumbling $2.31 per hour. 💪

If fman is to (sustainably) succeed, it needs to at least make the above x10 each year. Given that much of the sales happened during fman's time-limited launch, this will not be easy.

The motivation for the project is thus not money. (How would you feel if you earned $2.31 per hour?) It's my (almost fanatical) vision that there should be a better file manager.

You should support fman if you like it. It takes literally one minute. You get rid of the annoying nag screen and priority when it comes to feature requests: 23 of the 40 last changes were implemented for licensed users. Don't wait. Get a license now!

Why fman isn't open source

People sometimes ask why fman isn't open source. This post explains why.

fman aims to revolutionise the file manager niche like Sublime Text has disrupted text editors. This requires years of full-time development effort. I'm investing those years. But at some point, I need an income. The question is, can fman be open source and pay the bills? Here are some ideas:

Ask users to pay, even if fman is open source

I asked the author of a once very popular desktop app about this. He had open sourced his app a few years ago and told users that they still needed to pay. Revenue dropped by 90% over night. Now he gets a few code contributions here and there, but the majority of development is still performed by him. He can no longer afford to work on the project full-time.

Ask for donations

Very few creators are able to make a living from donations. This is likely not viable.

Fund development through Kickstarter

A few file manager projects tried this. Most failed to meet their funding targets. The few that did get funded never got very far.

Offer two editions: "Community" and "Pro"

The Community version could be open source. The problem is that "Pro" features in a file manager are not very cohesive. For example, users might be willing to pay for FTP and Dropbox support. But why force someone who only wants FTP to pay for Dropbox support? It doesn't make sense. Selling features individually is not an option either – see below.

Create a plugin "store"

Total Commander offers a plugin API. Even though there isn't a "store", there are a few commercial plugins (among thousands). Two of their developers told me that they weren't really making any money from their plugins. This may be because there isn't a proper market place. But it's too risky to base fman's sustainability entirely on this approach.

Offer subscription features

One such feature could be to sync your fman settings across machines. While nice, this feature alone would not create enough value to sustain fman.

Find a corporate sponsor

The sponsor would need to have an interest in the existence of an open source file manager. I don't know what that interest could be. But hey: If you are Microsoft and want to enter the niche, get in touch. ;-)

Because none of the above options are really viable, fman currently requires you to buy a license for regular use. You can evaluate it for free. It just greets you with a nag screen:

You can even see much of the source code: Most of fman's functionality is implemented in a plugin. The source code for this plugin is in your fman installation directory.

If you have other ideas of how fman could be monetised while making it open source, please let me know. I would love for fman to be open source. I just don't know how to do it sustainably.

Manage plugins inside fman

fman 0.3.9 is out. The main new feature is that you can now manage plugins inside fman!!!

To launch the new feature, open the Command Palette by pressing Ctrl+Shift+P (or ⌘-Shift-P on Mac). Enter "Install plugin":

  • Install plugin

fman will fetch all available plugins from GitHub and present them to you:

Press Enter and voilà! The plugin is downloaded and installed.

Similar commands were added for removing and listing the currently installed plugins. The latter ("List plugins") also lets you quickly jump to a plugin's directory.

Updated plugin directory structure

To accommodate the above feature, fman's plugin directory structure was slightly updated. It used to look as follows when you had a few plugins installed:

  • {data directory}
  • Plugins
    • OpeniTerm2
    • StatusBarExtended
    • ...
    • User

The User plugin was always loaded last. This let it overwrite the settings of all other plugins, and thus made it a good place to put your custom settings.

For the new feature, the question was: Where to put downloaded plugins? I didn't want to place them right next to (for instance) the User plugin because it would be too tempting to then go and edit the plugin files. This would cause problems when (in a later release) the plugin is updated: The modifications to its files would then be lost. The solution is a new directory structure:

  • {data directory}
  • Plugins
    • Third-party
      • OpeniTerm2
      • StatusBarExtended
      • ...
    • User
      • Settings

What used to be the User plugin is now the Settings plugin: This is again loaded last and thus the best place to put your settings files (eg. Key Bindings.json).

When you install a plugin via the above command, it is placed inside the Plugins/Third-party folder. You are not supposed to make changes to the contents of this folder.

Finally, if you want to develop your own plugin (and haven't put it on GitHub yet), you can place its directory in (say) Plugins/User/Your Plugin/.

When you update fman, your existing settings and plugins are automatically migrated to the new directory structure.

There were several other small improvements in this release. As usual, they are listed on the Changelog page. Enjoy!

Bug fixes and API improvements

fman 0.3.8 is out. It fixes several bugs that prevented fman from starting. As always, you can see a more detailed overview on the Changelog page :-)

The new version also improves fman's API: So far, custom commands had to extend DirectoryPaneCommand. As is explained in more detail on this page, a directory pane lists the contents of a directory:

A DirectoryPaneCommand lets you for example query which files are currently selected. This is for instance used by the Copy command (F5) to determine what to copy.

The slight problem was, not all custom commands actually need that much information. For example: The About command displays information about your copy of fman:

This command will never need to know which files are currently selected. What's more, only one "copy" of the command should reside in your computer's RAM. But DirectoryPaneCommands are always instantiated twice, once for each pane.

That's why ApplicationCommand was introduced. It's simply a more fitting abstraction for a certain kind of command. The upcoming feature that prompted this is a command that lets you install GitHub-hosted plugins from within fman. Here too, the command does not need to know what files are selected (and there should only be one "copy" of the command).

It will take a few more days to implement the new command. Stay tuned!

fman ❤️️ GitHub

So much has happened in the past three weeks. Six new versions of fman came out. 20 features and bug fixes were implemented. To let you see them, a Changelog page was added. With pretty pictures! Also, the Docs section was expanded to make it easier to configure fman. Suffice it to say, I've been waking up at 5am a lot.

As a startup CEO, I slept like a baby.
I woke up every 2 hours and cried.

Ben Horowitz

There is one thing that has come up numerous times since fman's inception: People want an issue tracker. Not just a public Trello board where you can vote on issues. A real issue tracker like GitHub's. Where you can submit bugs and request features, and maybe also talk about fman.

A few fman users in particular kept pestering me about this. (I'm looking at you, macosxguru 😉). It got to the point where I was afraid people were on the verge of starting their own issue tracker. This actually happened to Sublime Text, whose tracker is now run by the community.

So, from today onwards, fman's issue tracker will be hosted on GitHub. Use it to your heart's content to request features, file bugs and talk about fman. As on Trello, you can vote on features: Just give them a "thumbs-up" 👍 using the GitHub Reactions feature. The more votes an issue gets, the sooner it will be implemented. (I still have the previous number of votes from the Trello board, and will take them into account.)

The next release of fman will introduce another GitHub-related item: Making it possible to install plugins from GitHub, within fman. Stay tuned!

A third-party tutorial about fman

fman user Richard Guay has graciously written an extensive tutorial:

fman: The Extendable File Manager for Any System

It explains fman's most useful features and how you can write your own plugins. In the tutorial, Richard uses his own ProjectManager plugin as an example.

I must say at this point that Richard has been an absolute star in the fman community. He contributed many plugins (which you can find in the list of plugins) and provided invaluable feedback that guides fman in the right direction.

Thank you Richard! :-)

An apology to Linux users

In case you're here for the first time: fman is a file manager for power users. It launched last week. The launch exploded completely. fman made it into the top 10 on Product Hunt and was on the front page of Hacker News for 13 hours. 15,000 people saw it for the first time.

Despite the positive reception, several Linux users pointed out that fman had committed a complete no-go in the Linux world.

fman is young and many features you would consider basic are still missing. To let you receive these features as they come out, fman includes a mechanism for automatic updates. If you're interested in the details of this mechanism, please see this page.

On Linux, fman enables automatic updates by integrating with your system's package manager (eg. Synaptic/APT). That's good. But the no-go I committed was to also install a cron job that runs every day as root to check for updates to fman.

Linux users like to have complete control over their systems. They don't want any "shady" things to happen in the background. As a Windows and (recent) Mac user, this is what I failed to understand.

I just released version 0.3.1 of fman that removes the cron job on Linux and lets you update fman via Synaptic/APT at your own schedule. If you have version 0.3.0 of fman installed, remove it (including the cron job!) via sudo dpkg --purge fman. Then download and install the current version from the Download page. To verify that the cron job has been removed, see that /etc/cron.daily/fman does not exist.

fman's launch in review

Gosh. A lot happened in the last few days.

Maybe a little background first. fman, my file manager, has been in the works for slightly over a year. The first version came out seven months ago. Since then, fman has been in closed alpha, meaning that you had to leave your email on the home page to get access.

After last month's release, a few users asked "what's next?". On a whim, I replied "fman will leave closed alpha next month!". I had no idea what that would actually entail.

I've never really understood what it means to "launch". I mean, fman's web site has been online for a while. The new ("non-alpha") version wouldn't be radically different from previous releases (mainly because I like to release frequent, incremental updates). So what's the point?

One thing I knew was that I would have to start charging for fman at some point. A "launch" gave me a good excuse to say "fman was free to use while in closed alpha, but now I'd ask you to please get a license if you use it regularly." I charge for fman not to get rich (I don't think it's possible in that niche). But because I see it as the only way to sustain its vision.

In hindsight, I believe "launches" aren't really about products magically popping into existence out of thin air. Instead, I think they're mostly just marketing stunts.

On February 6 I announced that fman would leave closed alpha on March 1. That gave me 22 days to figure out a licensing scheme, code up a purchasing page, write a Licensing Agreement etc. Not a lot of time for all these tasks. But it forced me to focus on what's important and make sure I get something out the door.

I recently formed a mastermind group with a few friends who are also self-employed. The cool thing is, they're mostly marketers. They sell online courses like "how to stop smoking with hypnosis" or "how to win customers on Facebook". Totally not my alley (which is programming). But invaluable for me for learning about marketing.

Anyways, we meet up once every three months, discuss our businesses and set goals we want to reach by the next quarter. In our first meeting, I said I wanted to get to 200 closed alpha users. Big laughs all around. They said "dude, I can get you 1000 by tomorrow". So I said "okay! 250". This lead me to submit fman to BetaList, which actually did bring 1000 new closed alpha users.

The marketers highly recommended limiting the license sale in both time and quantity. It felt foreign to me at first. But, I did want people to make a decision. If you tell me "you can buy this now, or whenever" then it takes me forever. But if you say "hey, you have three days and it's the best deal you're ever going to get", then it's a no-brainer.

The reason why I wanted people to decide quickly is that I wanted to see "who's in". fman is a commercial project. As such, it needs to appeal to its paying users. Limiting the sale let me find out who these people are. I was later criticised for this (see below).

"Launch day" came, and my expectations weren't overly high. Leading up to the launch, I thought it would be really cool to get on Hacker News and Product Hunt. I strongly identify with the crowd on HN and had always dreamed about fman appearing there, especially because I feel that HN's target audience aligns very much with mine. But I didn't think I'd be able to make it to the front page. And sure enough – when I submitted fman to HN, it received some attention and encouraging feedback, but disappeared into oblivion pretty quickly.

Meanwhile, the "launch" to my existing users went well. From the closed alpha, I had a mailing list of a little over 1,200 people. I emailed them when the launch started. I sold 25 licenses in the first 12 hours, and another 25 or so in the 24 hours after that.

What was really interesting though was an email I had received in the night after the first launch day. It was from Daniel, a HN moderator. I had posted on HN with title "Launch HN: fman – file manager for programmers". He said the "Launch HN" prefix was reserved for YC startups. And! fman looked like a good post and he could put it in the second-chance pool. I hadn't known of this before. It artificially places a post on the front page for a few minutes. If people like it, it stays there. Otherwise, it falls off. Daniel asked when would be a good time for me so I can participate in the thread if comments appear.

I was previously interviewed about an older project of mine on Indie Hackers. Courtland from IH has a lot of experience with submitting stories to HN. He said at the time that Thursday and Sunday mornings around 11am PST are great, because there is little competition but still lots of traffic. As it was a Thursday, I told Daniel to make it 11am PST please – 8pm my local time.

Daniel didn't reply. So on Thursday late afternoon I went to Salsa class as usual with my girlfriend. (By the way: Especially if you're single, take a Salsa course. If you suck at dancing like me, practice beforehand. It will be appreciated ;) ) We got back at 7:30pm. Still no answer from Daniel so I sent him a quick email. He did reply this time and said fman would appear on the front page soon!

I didn't know what to expect. I thought fman would fall off after a few minutes. But it stayed there. Oh boy, did it stay there.

Encouraging comments started to pour in. My favourite one was:

The speed and efficiency of Norton Commander was amazing. Happy that people bring it into our century.

Andreas Klinger, CTO of Product Hunt

Traffic to surged. Within a few hours, the remaining 50 licenses were sold out.

That's when negative comments started to come in. People didn't understand why the number of licenses was limited. Several Linux users harshly criticised that fman installs a cron job that runs once a day and checks for updates. Both criticisms were warranted and I'm working on fixing them.

The biggest mistake

An influx of traffic like this is a huge opportunity. But how do you capture it? The answer is email. Let visitors subscribe to your newsletter. Many will gladly do it. I didn't have a sign-up form on the home page and thus missed the opportunity to reconnect with thousands of people who were keenly interested in fman. 😔

What's next

New licenses will be made available next week. I'll also get rid of the cron job on Linux. Then: Make paying users happy! :-)


  • 100 licenses sold (virtually all subscribed to updates)
  • 284 people on the waiting list
  • 13h+ on the front page of Hacker News
  • 183 points on Product Hunt (placing fman in the top 10 that day)
  • 3 hours of sleep the night fman was on HN
  • Up to 170 concurrent visitors
  • 14,500 visitors in total

Leaving closed alpha

Full-time work on fman started just over a year ago. Up until now, fman has been in closed alpha. This meant that you had to sign up to get access to it.

Today, fman is leaving closed alpha status :-) It has come a long way and is stable enough for general use. The download links (which used to be hidden from the public) are now available on the Download page.

Also starting today, fman will prompt you to please obtain a license:

Click the correct button to start fman as usual. The idea is to let you evaluate fman, but to remind you that for regular use a license is required.

The only chance to get the first licenses is from today until Friday (March 3).
Go to the (new) Purchase page to get yours. Licenses are ridiculously cheap right now. But only a limited number is available. Don't miss out! Because after Friday, it won't be possible (for a while) to get a license.

You may wonder why I'm not offering licenses after Friday. The reason is that I want to see "who's in". As a commercial project, fman needs to first and foremost appeal to its paying users. Limiting the license sale in both time and quantity lets me select for these awesome people.

In that spirit, March will be spent on making licensed users happy. So get a license and tell me what you want to see in fman ;-)

fman's new icon

fman has a new icon:

fman's development is very much driven by user feedback. There's a public list of requested features where you can vote on the improvements most important to you. Features are prioritised (roughly) according to the number of votes they receive.

fman's most requested feature for quite a while has been that it gets a proper app icon. Finally, in the new year 2017 I found time to look into this.

Because I absolutely, positively, most definitely suck at design (seriously), I decided to have the design created over at 99designs. In case you haven't heard of it before, 99designs lets you host a "design contest". You say what you need (eg. an icon) and how much you're willing to spend. Then designers come and submit design proposals. You have one week to ask for revisions. At the end, you pick a winner. The person whose design you picked gets the money, and you receive the rights to the design.

fman's contest didn't go exactly as planned. I thought I had this really cool idea: "fman" sounds a little like a superhero. So I advised the designers to come up with something along those lines. The first submissions weren't very good, but then there was one I really liked. It showed a confidently smiling "folder" with a face and a mask like a superhero. I thought it was a great way of conveying that fman was unique and superior to other file managers.

After a few more designs had been submitted, I held a Poll on 99designs. This feature gives you a shareable link under which others can vote (and leave feedback) on the designs submitted so far. Guess what? My supercool superhero unequivocally came last (with over 300 fman users voting!).

The design that came first in the poll had a slight problem: It featured the typical traffic lights buttons that are used on Mac to close/minimize/maximize a window. Several users suggested that it would be better if fman's icon were platform-independent (since fman is cross-platform as well).

Well, I forwarded this feedback to the designer and held another poll with three variants: The original and two platform-independent alternatives. Again, the original, "Mac-dependent" version clearly came first. I do agree that it's a nice design. And I don't think it's that big of a problem that it features Apple's traffic light buttons. So there we go :-)

One of the nice things about the icon is its simplicity. It's very clear, also at small sizes. Its colours and layout clearly resemble fman. I think it's rather memorable (or at least if you see it again, it's not difficult to remember that it stands for fman.) It may not be as artistic as my former preference. But I actually quite like it :-)

The icon was just released as part of fman't latest version 0.2.9. Enjoy! :-)

From 0 to 1000 users in a year

fman just got its 1000th closed alpha user!!11one. Time for a little recap.

(If you don't know fman: It's a cross-platform file manager that lets you work with files much more efficiently than Finder on Mac or Explorer on Windows.)

Full-time work on fman started in February 2016. I was on the Canary Islands at the time, making use of my location independence as a bootstrapping entrepreneur. Here's the view from the (awesome!) hostel I was staying at:

I was working from a nice little coworking space in Las Palmas, called CoworkingC:

My previous businesses were providing me with a modest but stable passive income and I was looking for my next project.

I had switched to Mac in 2014 after many years on Windows. One constant annoyance was that there was no good Mac alternative to Total Commander, the file manager I used to use on Windows. But also on Windows, TC was showing its age, especially when you compared it to more recent tools like Sublime Text or Atom.

That's why I decided to see if a modern, cross-platform file manager would be a viable next project. Before diving into any new project, I like to conduct thorough online research to see if there is already an existing solution – nothing is more wasteful than spending months implementing something, just to realise that it already exists. I found that there are already 94 file managers on the market:

Could I really make a dent in this space, given that my solution would be #95? I think so: Most existing solutions are for a single platform only. None of them incorporate the slick features and design of Atom or Sublime Text. And from personal experience I know that the existing tools for Mac in that space simply aren't very good.

After another month of research – what name to use (fman for "file manager", concise much like the product itself), which GUI technology to use etc. – the first commit was made:

It took another whopping three months to get this very first version to a state I was comfortable sharing: fman for OS X was released on July 18, 2016. It already looked pretty similar to what you see today:

Of course, it was still missing many essential features. But, the first user feedback started pouring in. So I created a public board on Trello to keep track of feature requests and let users vote on their favorites. The board has been a very valuable tool since then for deciding which features to focus on.

Not even a month later, fman came out on Windows. That a release for an entirely different operating system was possible so quickly was largely thanks to the fact that fman is based on the cross-platform GUI toolkit (Py)Qt.

As for Mac and later the Linux release, a large part of the effort for the Windows port went into implementing automatic updates. In my opinion, a modern app should be able to update itself automatically. And I mean automatically. I hate nothing more than apps prompting me "new updates available" when all I want to do is get some work done.

After several smaller releases, fman's first killer feature was implemented: GoTo on Steroids. It lets you jump to directories extremely quickly, without having to manually manage a list of favorites:

In the months that followed, it was great to see fman's user base expand. A user called GoTo on Steroids "literally the best thing since sliced bread". The first user-contributed plugins appeared (another feature that sets fman apart is its Python-based plugin API). fman was featured on BetaList. And a user submitted it to Product Hunt:

In November, fman was released for Linux, finally making it truly cross-platform. It looks quite gorgeous on Ubuntu:

And then there is today, the day fman reached 1000 users. It's been a very successful first year. But I'm still nowhere near my goal of total domination of the file manager niche. So stay tuned! Lots of good stuff is still to come :-)

(You can still sign up for fman's closed alpha by clicking on the "Request early access" button on the home page.)

Command Palette

fman 0.2.6 is out :-) The main new feature is the Command Palette:

It lets you quickly search through and run fman's commands. What's also useful is that it displays the shortcut next to each command. You can launch it in fman by pressing Ctrl+Shift+P (or Cmd+Shift+P on Mac).

The Command Palette perfectly complements several key UX decisions in fman. First, fman is very keyboard centric, which requires the user to remember a few shortcuts. The Command Palette makes it easy to learn/explore them. Second, as explained in the last post, fman doesn't have a menu. Instead, the Command Palette now exposes all features – and makes them easily discoverable. Finally, plugins can add items to the Command Palette, and thus extend fman's functionality.

Implementing the Command Palette now has strategic reasons as well. fman is currently in closed alpha, meaning that users need to give their email address to get access to it. The goal for this quarter is to make fman public. This will bring a swath of new users. Some of these users will not have used a dual-pane file manager before, and thus won't know the standard shortcuts F5 for copying etc. The aim is for there to be a mini tutorial the first time fman is started, saying "Hey, all you need to remember is Ctrl+Shift+P for opening the Command Palette".

Coming up next is the second-most requested feature from fman's public feature list:

That's right, fman will finally get a proper app icon! I will launch a design contest on 99designs and ask for your vote once the first submissions have come in. Stay tuned!

Drag and Drop

fman 0.2.4 was just released. The main feature of this new version is drag and drop. It's for instance useful for dragging file attachments into Gmail's web interface.

The previous two releases (0.2.2 and 0.2.3) fixed several bugs, but also added a tiny new feature: Pressing F1 in fman now opens the Keyboard Shortcuts page. This feature and support for drag and drop were added because they were comparatively simple, yet received several votes on the feature requests list.

There was another feature on the list, which after some consideration was scrapped for now: A Help menu inside fman. fman currently doesn't have a menu bar, so adding a Help menu would have required adding this bar. Here's what it could have looked like on Windows:

The menu bar would have taken up a lot of space. It would have changed fman's layout. It would have made fman less beautiful. What's more, menus are (in my opinion) a horrible way of organising features. How much time of your life have you spent browsing through app menus, searching for items that you knew should probably be there, but you didn't know where exactly? I get very impatient every time I have to do this.

So fman won't have any menus. Instead, it will offer a keyboard shortcut (Ctrl/Cmd+Shift+P) that lets you search through all available commands similarly to how GoTo on Steroids lets you search through directories. This way, you don't have to manually browse any menus. You just type what you want to do and fman will suggest the appropriate action, which you can then select with Enter. If there is a keyboard shortcut that is bound to that action, then it should also be displayed so you can know the shortcut for the next time. This will be the main feature of the next release.

This will likely be the last update of 2016. If you are celebrating Christmas, then have a very merry festive season and a Happy New Year. See you in 2017!

fman 0.2.1: The command line

After last week's release of fman for Linux, today's update brings a small but useful feature: You can now start fman from the command line.

The feature works on all operating systems, but requires updating the PATH on Mac and Windows. Please see the new documentation page for details.

fman on Linux is out

After an intense month of development, I'm finally able to fulfill a promise made many times on this blog: fman is out on Linux!

If you are a member of the closed alpha program, then you should have already received the download link via email. If not, then you can still sign up via the "Request early access" button on the home page.

Currently supported are 64-bit Linux distributions based on Ubuntu 12.04 and higher. If you want support for a different Linux version, please let me know.

The default key bindings are the same as on Windows. For an overview, please see here.

Similarly to the previous Windows and Mac releases, considerable effort went into implementing automatic updates. The Linux implementation uses Ubuntu's package manager. By default, fman checks once a day if a new version is available. If yes, it is automatically installed. To force an update check right now, you can also use the following command in a Terminal:

sudo update-fman

The next weeks are devoted to ticking off as many points from fman's feature requests list as possible. Issues will be prioritised by how many votes they have received and by how easy they are to implement (so two trivial 3-point issues will be given preference over one hard 6-point issue):

After that, the next big step will be to (finally) make fman public. Given the already very positive reception of fman, I am hoping that this will truly make it explode in popularity. However, there is quite some work to do before then so I estimate that fman will only become public in (or at the end of) Q1 2017.

As always, I would love to hear any feedback you might have. If there's anything you would like to see or change in fman, please just get in touch!

fman is catching on

The Linux release of fman will come out any day now. Until then, I wanted to share some of the press / feedback fman has been getting recently:

GoTo on Steroids, the main feature of the last release, is a great success. Here's what one user wrote about it:

The new GoTo feature is literally the best thing since sliced bread! I love it :)

a happy fman user

What was also great to see was that several more people have written their own plugins. User kek91 for instance has open sourced several of his plugins:

  • ShowKeyBindings lets you quickly see the currently active key bindings.
  • StatusBarExtended makes fman show more information in the status bar, such as the number of files in the current directory.
  • ShowFileProperties displays information (such as total size) for all currently selected files.
  • ListPlugins displays a list of installed fman plugins.


Next, the vision is for fman to become the leading file manager worldwide. As such, it needs a proper web site. Here's what the home page used to look like:

In order to do fman's aspirations a little more justice, I fleshed out the home page. Here's a screenshot of what it looks like now. My favorite part is definitely the rocket.

The redesigned home page made it possible for fman to be featured on BetaList, a site that lets early adopters discover tomorrow's startups. fman was so popular among BetaList visitors that it even made it to the front page:

Being featured on BetaList brought fman from ~160 closed alpha users to nearly 500!

What was also cool was that a user submitted fman to Product Hunt:

I was a little worried that this early submission would prevent fman from having a proper launch on Product Hunt at a later stage. Thankfully, the Product Hunt team are so up to snuff that their community lead quickly said that it wouldn't be a problem.

And that's about it for now. The positive feedback is very encouraging and I hope there is still lots to come. Thank you for following along!

GoTo on Steroids

fman 0.1.7 is out. Without exaggeration, it is probably twice as useful as before.

The new killer feature is GoTo on Steroids. Press Ctrl/Cmd + P to get a dialog for quickly jumping to a directory. fman offers intelligent suggestions as you type, taking into account which folders you visit most often:

You can also directly enter the path to a directory. fman will suggest subdirectories as you type. Press Tab to auto-complete a suggestion and quickly jump to the next level of folders.

A limitation of the current implementation is that it only suggests directories you have already visited. Please don't be disappointed when you don't get very clever suggestions the first time you start the new version. It will get a lot more useful as fman learns which directories you visit most often.

After using GoTo on Steroids for only a few days, I would already find it hard to use fman without it. What's more, it's probably the first feature where fman truly outshines other file managers.

This is not all. Since the last blog post, there have also been several basic – and thus very useful! – improvements:

  • Toggle hidden files with Ctrl/Cmd + ..
  • Switch drives/volumes with Alt + F1.
  • Create new files with Shift + F4.
  • Open in other pane via Ctrl + Left/Right. This is useful in many situations, such as for instance when duplicating a file.
  • A slightly more beautiful UI.

Finally, the last blog post introduced fman's plugin system. It was great to see that several of you already wrote custom plugins. Being able to tailor fman to your needs via a vibrant plugin ecosystem will be another of its key strengths.

The plugin system has changed a little since the last release. But in return, fman now handles plugin/configuration errors much more gracefully:

Error in key bindings: Command 'foo' does not exist.

If you already have your own plugins and are now getting errors, please see the updated documentation. (In short, your .py files must now reside in a Python package, eg. My Plugin/​my_plugin/​ instead of My Plugin/​ The API has also changed a little.)

As usual, the new version is distributed via fman's auto-update mechanism. On Windows, this means that the next time you start fman, it should already be at the latest version. On OS X, you need to start and close fman once, leaving it running for a few seconds.

Custom shortcuts and plugins

fman 0.0.6 was just released, and it's freaking awesome.

The new release adds support for custom key bindings, fman's most-requested feature. It is especially useful on OS X: Up until now, you had to use the function keys F5 etc. to perform common tasks such as copying files. The problem is that you normally need to press Fn to get these keys on a Mac. It is possible to change this behaviour in OS X's Keyboard Preferences (which I recommend):

Use all F1, F2, etc. keys as standard function keys

However, if you don't want to (or cannot) change this setting, then you can now configure fman with your own preferred keyboard shortcuts. Please refer to this page to see how.

But that is not all: Do you remember the post about fman's core values?

Looks matter.
Speed counts.
Extending must be easy.
Customisability is important.
But not at the expense of speed.
I/O is better asynchronous.
Updates should be transparent and continuous.
Development speed matters more than program size.

Of the above points, Extending must be easy has been fman's weakest. Well, no longer! The new release adds support for writing your own plugins. One thing that's really cool about the implementation is that fman's own commands are all implemented in a plugin. This means that third-party plugins have access to an extremely powerful API that will get even better with time. For more information about plugins, please see the (new) documentation.

There are still a few more improvements I would like to implement before beginning work on the Linux version of fman. Stay tuned!

fman 0.0.3

Today marks the first time a new version of fman is released to existing users transparently via the auto-update mechanism. The new version includes a few bug fixes and an implementation of the most-requested feature so far: Support for copy/cut/paste via the standard keyboard shortcuts. On Windows, these are Ctrl+C, Ctrl+X and Ctrl+V, respectively. On OS X, as in Finder, you copy via Cmd+C, paste via Cmd+V and paste-cut via Cmd+Alt+V. Of course, the implementation works so that you can copy from Finder/Explorer and paste into fman and vice versa.

To get the new version on OS X, restart fman twice, leaving it running for a few seconds each time while it downloads and applies a 260 KB update file. On Windows, it can take a few hours until you automatically get the new version. fman displays the version number in the status bar at the bottom of the screen. If it says 0.0.3, then you have the latest one.

The release of the new version took a little longer than hoped, mostly because the auto-update functionality still required some work. Following fman's I dare say democratic approach to development, you can see on the public feature requests list what the next feature will be:

Sort directories by name/date, not just files

Next up are this (and possibly a few other) features, before work begins on the Linux version of fman. Stay tuned!

fman on Windows is out

The closed alpha of fman is finally available on Windows!

fman closed alpha screenshot Windows

If you are a member of the closed alpha program, then you should have already received the download link via email. If not, then you can still sign up via the "Request early access" button on the home page.


fman lets you quickly navigate directories and manipulate files. It offers the following keyboard shortcuts:

  • Type a file's name to jump to it.
  • Enter: Open file/directory
  • Backspace: Go up a directory
  • Tab: Switch from left to right side (or vice versa)
  • F5: Copy to the other side
  • F6: Move to the other side
  • Shift + F6: Rename
  • Space: Select multiple files
  • F4: Edit (with a text editor)
  • F7: New directory
  • F8: Delete
  • F9: Open terminal in current directory
  • F10 (new): Open native file manager (Explorer/Finder)
  • F11: Copy path to clipboard

OS X closed alpha statistics

The closed alpha of fman was first released for OS X one month ago to about 80 users (not all of them on OS X). fman checks for updates every time it starts. The update server receives several such pings a day, so at least some users are already using fman regularly. Not bad for a bare bones alpha version!

Windows implementation journey

When the closed alpha was released on OS X last month, there was already a prototype of fman for Windows. Bringing this prototype to alpha stage required quite a bit of work. It started with some necessary improvements for high DPI displays. Next came codesigning and auto-updating. StartSSL Class 2 certificates are used for codesigning. Automatic updates use Google Omaha, the auto-update technology behind desktop apps such as Chrome. For a technical introduction to Omaha, please see this previous blog post.

Next steps

fman still lacks many basic features. The next few weeks are devoted to adding them. There is a public list of feature requests where you can vote for the ones you think are most important. You can also suggest new features or report bugs by getting in touch. Have fun with fman!

Google Omaha Tutorial

Google Omaha is the open-source version of Google Update, the technology which keeps desktop apps such as Chrome up to date. Integrating Omaha into fman was difficult, so we wrote this tutorial to make it easier for others.

Read more

Codesigning and automatic updates for PyQt apps

This technical post is probably only of interest to PyQt developers.

Read post

fman is out on OS X!

The closed alpha of fman is finally available on the first platform: OS X. Here it is, in all its beauty:

If you have registered for the closed alpha, then you should have received an email with installation instructions. If you have not registered yet, then you can still join by clicking "Request early access" on the home page.

Features / Operation

fman is a dual pane file manager. It always shows the contents of two directories next to each other. Only one of the two sides is active at a time – in the above screenshot for example it's the left side. You navigate through the directory tree by pressing Backspace to go up, or by typing the first few characters of a file or directory followed by Enter to open it. By pressing Tab, you can switch from one side to the other.

The main benefit of dual pane file managers is speed. You usually operate them with the keyboard, which is extremely quick. The fact that you always see the contents of two directories makes it easy to copy or move files: You simply navigate to the file you want to copy on one side, then navigate to the directory you want to copy the file to on the other side and press a keyboard shortcut. You don't need to deal with multiple windows, or tediously click around in a directory structure with your mouse.

Here is a list of all currently implemented keyboard shortcuts:

  • Space: Select multiple files
  • F4: Edit (with a text editor)
  • F5: Copy
  • F6: Move
  • Shift + F6: Rename
  • F7: New directory
  • F8: Delete
  • F9: Open Terminal in current directory
  • F11: Copy path to clipboard

If you are a programmer and work with console commands a lot, then I believe you will find F9 and F11 especially useful. It is so much faster to navigate through directories with fman than with the cd / ls commands inside a terminal.

A final note for OS X: On MacBooks, the function keys F1-F12 can by default only be accessed if you press the Fn key at the same time. When you use fman a lot, you will likely find it a lot easier if you change this behaviour. The required option is under System Preferences / Keyboard / Use all F1, F2, etc. as standard function keys. Select this so you don't have to press Fn to get function key behaviour. You can then still get the keys' original features by pressing Fn. Finally, if you find that some of the function keys don't exhibit the behaviour described above but some window-related functionality, check if they are assigned to Mission Control features under System Preferences / Mission Control.

Automatic updates

This first release of fman is a minimum viable product (MVP). Its goal is to get something of value into your hands as quickly as possible. Many features are still missing and will be implemented in the coming months. There is an auto-update functionality so you can get these features, as well as bug fixes and performance improvements, without having to constantly reinstall fman. When you start fman, it checks in the background whether a new version is available. If yes, it downloads a small patch file (usually less than 200KB). The patch is then installed when you close fman. These tasks are only performed while fman is running. There is no "background service" that hogs your system resources. As explained in The Zen of a file manager, the entire process is carefully designed to "just work" without ever getting in your way.

Share your feedback

A big advantage of the lightweight auto-update mechanism is that it enables me to rapidly implement any suggestions you might have. I hope you will already find fman useful (I know I do). But it is intentionally basic so I can get your feedback and act on it. If you ever see anything in fman that you think should be improved, please just let me know! You can always find my details on the Contact page.


The main next steps are to get fman into the hands of Windows and Linux users. Closed alpha members will receive an email address when this is done (did I mention that you can still sign up?). Other than that, the focus in the following weeks is on implementing immediate user requests and bug fixes. Thanks for following along, and see you soon!

Update July 20: There is now a public Trello board with a list of requested features.


The release of fman's first closed alpha is taking longer than hoped, but that is not to say that there has been no progress. Since the last post, fman has successfully been ported to Windows and Linux from OS X. The only tasks that remain before the closed alpha can be released are to implement an auto-update functionality (so you can get bug fixes / improvements instantly) and to package fman for the various operating systems. The latter involves codesigning the distributables so your OS recognises them as safe and doesn't show warnings "This software is not trusted". Codesigning and auto-updating in conjunction are unfortunately a bit painful. But we'll get there!

In the meantime, there has been a small update to the web site. On the home page you can now see the latest surce code commits made to fman!

Latest commits
  • Update post-commit script to show latest commit on

    mherrmann committed on Jul 01, 2016

  • Fix a typo in Info.plist file.

    mherrmann committed on Jun 29, 2016

This gives you more insight into fman's development (and in particular, how actively it is being developed). What's more, it enables:

fman's Open Source Promise

Some users of Sublime Text have complained that if its creator ever stopped working on it, they would be stuck in an ecosystem that is no longer being maintained. fman makes the following promise to address this issue:

If no commit is made to fman in more than 6 months, then it will be open sourced under a BSD license.

When you obtain a license, this means that if development on fman ever stops, you will be free to extend and keep using it. If you also have a subscription for updates, then the promise means that you either get regular updates or can use fman for free. Finally, if you develop plugins for fman, then the promise guarantees that your work won't become obsolete. (In case I am unable to release the source code, my family knows how to do it.)

Let's hope that the next post will be about the release of fman's closed alpha!

fman's business strategy

The closed alpha of fman is slowly coming along. The current prototype runs on OS X and looks as in the screenshot on the home page. It supports basic keyboard commands (F4 for editing files, F5 for copying, F6 for moving, F7 for creating a directory, F8/DEL for deleting, F9 for opening a terminal). Porting it to Windows started this week. It already runs there, but isn't yet as visually appealing as on OS X. (If you want to sign up for the closed alpha, that's still possible on the home page.)

Until the closed alpha is ready, I thought I'd share fman's business strategy with you, and how I arrived at it.

First things first, fman is a commercial project. Its goal is to create the most awesome file manager in existence. The resources required to do this are paid for by people who buy fman. This ensures that you get software of the highest quality and lets me devote years of my life to developing it.

Can fman be open source while being a commercial project? There are a few ways it could be monetized:

  1. Tell users that they need to pay for fman, even though it is open source.
  2. Offer a plugin store similar to Apple's and Google's app stores. Allow plugin developers to publish paid apps through it. Take a cut of payments. Also develop and publish own paid apps.
  3. Offer a subscription service that augments the deskop app. For instance, a functionality that lets users log in inside fman with their email address to have their settings synced across devices.

Regarding 1., I spoke with the author of a very popular desktop app who open sourced it a few years ago, but told users that they still needed to pay for it. His revenue dropped 90% over night. He does get a few source code contributions, but the main development is still performed by him. He no longer makes a living off the project.

2. Total Commander on Windows offers a plugin API. Even though there isn't a "store", there are a few commercial plugins (among thousands). Two of their developers told me that they weren't really making any money from their plugins. This may be because there isn't a proper market place for plugins in Total Commander. But it's too risky to base fman's sustainability entirely on this approach.

3. A "sync across devices" feature, while nice, probably wouldn't create enough value to sustain fman. It's still a feature that (at least paying) users should have access to, though.

If you know of an ingenious other way to monetize fman while making it open source, please do get in touch. I would love to make fman open source, I just don't know how to do it sustainably.

License scheme

Update March 3, 2017: The licensing scheme was improved following feedback from fman's users. Please see the licensing page for details.

You can evaluate fman for free. However, for extended use a license must be purchased. Prices will initially be as follows:

Per year Forever
For personal use $/€ 10 $/€ 39
For professional use $/€ 25 $/€ 79

Updates are included for the respective time period. You can use a license on as many computers and operating systems as you like. Best of all, if you convince your employer to buy a professional license then you get a personal license for free. So if you're smart about it then you don't even have to pay for fman yourself ;-)

Two things Sublime Text has been criticised for are that it is closed source and has a low Bus factor: If the creator Jon Skinner is hit by a bus then all users are stuck in an ecosystem that is no longer maintained. Sublime Text has also been criticised for slow development with no releases for extended periods of time and lack of communication with the outside world about what is going on. I have two ideas how these issues can be addressed. You'll be able to read more about them in an upcoming post.

Picking technologies for a desktop app in 2016

When developing a new desktop application, the most important choices from a technological point of view are which programming language(s) and GUI framework to use. fman's combination needs to tick the following boxes:

  • Cross-platform (Windows, Mac, Linux)
  • Good performance
  • Support for custom styles
  • Simple for users to extend via plugins
  • Fast development

What's interesting is that the choices of programming language and GUI toolkit influence each other. For instance, if you pick Electron as the GUI toolkit (/platform) then you must use JavaScript.

Speaking of Electron, it's a very exciting field at the moment. For those of you who don't know it, it's a platform for developing desktop applications that use Chrome's rendering engine for their GUI. Electron-based apps basically launch a (trimmed-down) version of Chrome on start-up, and then use JavaScript/Node.js to do everything you couldn't normally do with a browser, like accessing files or other system resources. Their GUIs are writen in HTML / CSS, just as on a web page, with lots of JavaScript.

Electron is the foundation for Github's Atom text editor, and Microsoft's alternative Visual Studio Code. Both of these tools have gorgeous GUIs. The fact that Electron apps are based on web technologies which are very widely known among developers has huge advantages for their extensibility (or "hackability" as Github calls it). A good indicator of this is that Atom already has about the same number of plugins written for it by users as Sublime Text, even though it has only been around for 2 and not 9 years. (Granted, Github's community also plays a large role in this, but it's impressive nevertheless.)

The weak point of Electron is performance, in particular startup time. Electron apps essentially launch a browser on start-up. On my late 2014 machine, this takes more than a second. On my older machine from 2010, it's close to five(!) seconds. There are attempts by the Electron community to solve this, but none that would seem to bring startup time significantly below one second. A workaround would be to always leave fman running in the background, but enough applications already do this and fman has no right to hog your system's resources this way. So, while it would be great to be able to use Electron for all its advantages, fman's focus on speed does not allow it.

At the other end of the performance spectrum is writing a custom GUI toolkit in C/C++. This is the approach taken by Sublime Text. Its performance is amazing and one of the main reasons why many people haven't switched to Atom. A drawback of this approach is that developing in C/C++ takes a lot more time than in higher-level languages. And creating a new GUI toolkit is also not something to be taken on lightly, especially when you think of all the things you have to deal with (blinking carets, scrollbars, font rendering, ...).

So, it makes sense to use an existing GUI framework. fman's emphasis on a beautiful UI requires a lot of custom styles, which rules out native widgets and libraries like wx. The most prominent framework that remains is Qt, and this is what fman uses. Some people have warned that Qt apps typically don't feel truly native. But, it is possible to customize the look and feel far enough to overcome this and make the fact that it's not fully native transparent to the user.

In the short time since fman's development started, basing it on Qt has already yielded enormous benefits. The current state of fman is a prototype that looks as in the screenshot on the home page. It launches instantly even on my old machine and can be used to navigate, copy and move files and directories. Imagine how far you would have gotten in a month developing your own GUI framework in C++! I think I would still be stuck on the build system ;-)

This leaves us to pick a language. The official Qt bindings are written in C++. Unfortunately, C++ is a horribly unproductive language (at least for me). A popular alternative in recent years is Go. Go is "only" two to four times slower than C, but easier to use and offers perks like a very small memory footprint or the fact that it compiles to single, self-contained executables. A drawback of Go is that it could not (easily) be used for fman's plugin API since it is not an interpreted language (so plugin developers would have to recompile their code after each change). What's also a disadvantage of Go when it comes to managing files is that its Unicode support is apparently not very user-friendly. All in all, It appears that Go is (currently) better suited for server-side apps where performance and memory footprint are critical.

Enter Python. After 15 years of programming, Python is by far the most productive language I have encountered. The standard libraries are awesome. So many people use it that you can just Google for a problem and usually find a ready-made solution. A good example of this are the Qt bindings (PyQt), which were developed by a third party. Python is also interpreted, so when you develop a plugin for fman, you can simply change your code and see the effects immediately. Its Unicode support (as of version 3) is great which means that you don't have to worry about bits, bytes or encodings. Finally, Python is extremely easy to learn. Even if you haven't used it before you will be able to pick it up immediately. It has made me a much more productive programmer and I am confident it can do the same for you.

No choice is without trade-offs and so also Python has its drawbacks. The main one is that it is extremely slow in comparison with eg. C/C++. fman manages this by only using Python for the "business logic" / plugins and performing computationally expensive tasks such as rendering through Qt / C++. Still, the amount of time spent by fman in Python code is something to keep a close eye on.

When Apple launched the App Store, a friend of mine from college made £50,000 (the equivalent of $100,000 at the time) writing apps over the summer. fman will have a package manager for installing plugins and may also allow you to charge for the plugins you develop. Some people have said that they would prefer a compiled language in this case, since Python's interpreted nature would essentially give everyone who has a plugin access to its source code.

While it is true that it is possible to reconstruct the source code from a Python application with near 100% accuracy, it also needs to be said that compilation is not obfuscation. For example, most Java programs can be decompiled with near-perfect accuracy. The solution in both cases is to use an obfuscator. For Python, there is a good obfuscator by Bitboost, which produces code that is virtually impossible to deconstruct.

In summary, fman uses Python and Qt via the bindings provided by PyQt. To see what it looks like, click the button below.

In the next post, you can read about some of the business strategy behind fman.

Update, one year later: I'm still happy with PyQt. If you are considering using it, I have created a GitHub Wiki that summarizes the things I have learned so far and should let you get over some of the road bumps I encountered much more quickly.

Appendix: Rejected GUI frameworks

This post picks Qt because it is "the most prominent" GUI framework fulfilling fman's requirements. Some readers have asked why it was chosen over other alternatives. The striking argument remains that Qt is what most people seem to use, which has a lot of advantages eg. when it comes to documentation on the net or language bindings. If you need to pick a GUI framework, you may be interested in the following list of alternatives, and why none of them was picked over Qt:

JavaFX / Swing
Can only be run in a Java virtual machine, which takes too long to start up.
Seems to be the second-most popular alternative to Qt. Supposedly it works best on Linux. Since most of fman's users are on Windows / OS X however, this would not be an advantage.
Very limited support for custom styles.
Old and stable with support for custom styles, but much less popular than Qt.
Windows Forms
Not cross-platform.

The Zen of a file manager

When you run the statement import this in Python, you get an opinionated list of principles that guide the programming language's design. Much in the same spirit, here are the core values driving fman:

Looks matter.
Speed counts.
Extending must be easy.
Customisability is important.
But not at the expense of speed.
I/O is better asynchronous.
Updates should be transparent and continuous.
Development speed matters more than program size.

fman is fast, beautiful and extensible. It's also customisable, but you can't change it completely. The reason for this is that customisability costs performance. For example, the Atom text editor is very adaptable but suffers from severe performance issues.

The next point on the list – that I/O should never block the GUI – is obvious for a file manager. The item that follows is more interesting: Have you ever really needed to get something done and the app / OS interrupts you for some updates? You don't care. Manual updates are also tedious. fman addresses this by updating itself in the background similarly to Google Chrome. It does so without unnecessarily straining your system's resources or bandwidth.

Finally, program size – both on disk and in RAM – affects your workflow much less than some extra polish in the other areas mentioned above. Sublime Text for instance is very efficient on resources but has been criticised for its slow development. Part of the reason for this is likely that it is developed in C++ with a custom UI toolkit. All else being equal, fman therefore prefers ready made solutions, even if this increases its size.

The next post explains how these principles affect fman's technology stack. Stay tuned!

Update October 6, 2017: The last Zen item was replaced by a more powerful statement. See the new blog post for details.

Introducing fman

Do you know the feeling when you just can't get an idea out of your head? Especially when you're confronted with it every day?

When I switched to Mac after 20 years on Windows, the one thing I missed most was Total Commander. Every time I had to use Finder (or Explorer, for that matter) I felt so slow in my workflow. It probably doesn't matter much when you don't work with files a lot. But if you do, it becomes a real pain point.

Of course there are alternative file managers for other platforms. But none of them make you really go wow. And even Total Commander is showing its age when it comes to user interface or plugin system. In the age of Sublime Text and Atom, I think we want more than closed, single-platform software. We want speed, a beautiful interface and a vibrant plugin ecosystem that can be accessed right from within the application.

This project realizes the idea that there can be a better file manager. I am dedicating the next years of my life to bring you, dear visitor, the file manager you will hopefully not be able to live without.