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:
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.
Very few creators are able to make a living from donations. This is likely not viable.
A few file manager projects tried this. Most failed to meet their funding targets. The few that did get funded never got very far.
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.
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.
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.
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.
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
⌘-Shift-P on Mac). Enter "Install
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.
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:
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
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:
What used to be the
User plugin is now the
plugin: This is again loaded last and thus the best place to put your
settings files (eg.
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)
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!
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 :-)
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
DirectoryPaneCommands are always instantiated twice,
once for each pane.
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!
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.
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!
fman user Richard Guay has graciously written an extensive tutorial:
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! :-)
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.
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.
Traffic to fman.io 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.
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. 😔
New licenses will be made available next week. I'll also get rid of the cron job on Linux. Then: Make paying users happy! :-)
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
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 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! :-)
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.)
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!
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
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!
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.
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:
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!
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 :)
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:
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!
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:
Ctrl/Cmd + ..
Alt + F1.
Shift + F4.
Ctrl + Left/Right. This is useful in many situations, such as for instance when duplicating a file.
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:
If you already have your own plugins and are now getting errors, please see
(In short, your
.py files must now reside in a Python package,
My Plugin/my_plugin/__init__.py instead of
My Plugin/my_plugin.py. 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.
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
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):
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?
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!
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,
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:
Next up are this (and possibly a few other) features, before work begins on the Linux version of fman. Stay tuned!
The closed alpha of fman is finally available on 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:
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!
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.
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 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.
This technical post is probably only of interest to PyQt developers.
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.
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:
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
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.
This first release of fman is a minimum viable product. 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.
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!
This gives you more insight into fman's development (and in particular, how actively it is being developed). What's more, it enables:
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!
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:
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.
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:
|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.
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:
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.
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:
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:
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!
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.