Network Administrator Professional Technical Resources US-OR-Portland Post A Job | Post A Resume

[ Thanks to Matej Urbancic for this link. ]

Some time ago I wrote about Krusader--the full featured twin panel file manager for Linux and KDE. After that I started poking for a GNOME file manager that could live on my non KDE-distro, since Krusader requires some kde libraries. I found a lot of candidates to fit the bill.

Some of them looked promising and are worth of a further attention, but my points about single enthusiasts and dispersed programming from the first article, got even stronger rationales.

I guess that no one can do anything about programmers wanting to work alone. Some programmers like to fork existing source and continue anew instead of contributing to original applications. There's nothing wrong with this, if we put aside the progress that two people can make over one.

What really got me wondering while reading through blogs, forums, and news sites was what makes a program a widespread success and what makes different programmers work together. And I asked myself when new users will be satisfied with new apps. To answer these questions, I decided to examine the most successful projects and articles posted on different Linux news sites.

Let's start with my last question. This one is kind of rhetorical and the answer is easily provable by looking at software forums: the user is never satisfied. More users equals more wishes and the result is a bloated app. Or is it?

Solutions for needed program changes and user-specific requests can be two different projects. The software developers try to compensate the users' never-ending desires by using two basic techniques that seem bloat-safe.

For instance, the developers of the Mozilla Project integrated "extensions" as the tools for adding extra features that are not bundled in application itself. The biggest advantage of extensions is their integrated look and feel of basic GUI and thus the impression of welded functionality and common development language that spreads the programming through the community.

The second technique is the integration of a plug-in system, which is supported by many different products. Total Commander, for example, took a similar approach with a plug-in system, but it is more robust and oriented towards combined functionality of different apps and TC, without compromising the speed and efficiency and support for different archive, file system, and lister types. Plug-ins add functionality relying on the main GUI and have defined action sets, while extensions generally are less restricted on their actions, and use modified, hidden or optional functionality.

Among Linux OFM's, Krusader took on an interesting script-based user actions system, which can set specific user actions to quick shortcut keys or icons. Krusader Krew promises that the most useful scripts will make it into the next release. They already support several external packers and some VFS. Packers are mainly standalone programs called from command-line, while VFS's are deeply integrated in KDE.

All file managers use plugin systems, but none have tried the extension approach. For the average user, a plugin does not describe everything it does, especially if its functions are numerous, as found in packers, so users are still bound to the command-line for harder tasks.

Extensions, on the other hand, can be more descriptive and can take a user-friendly approach.

The main problem with all file managers is specter of functionality. For example, all Krusader users move and copy their data, while advanced users also use multi rename tools--but only gurus will write useractions. An extension system could strip the main program of useraction GUI and add an easily installable useractions table for users wanting these features but lacking the knowledge to write them.

Skeptics can always look at Mozilla extensions to find that extensions are really doing well.

Let's move to the first question I posed. What makes an application widespread? First of all, the application must be known in the Internet world to gain on the critical user mass. Again, we can learn from the aggressive Spread the word marketing of Mozilla projects. User mass also increases program developers' mass and integrated extension or plugins programmers mass.

Secondly, the application must be good and useful--or at least be promising for the users to start following its development. The better the application, the more users.

Here I have to mention one little thing that must never be forgotten: users want to be able to customize everything. By everything, I mean everything!

This is the developer's problem. Satisfy functionality or appearance. Even though the appearance is the first and most noticeable part of a program, lacking functionality usually kills an app.

I also came across the so-called "screenshot test," where a blogger describes that by looking at the application's screens, one can get very good feeling for what the program is about, how the program works, and how good the software actually is. No need to actually download and compile. In addition, screenshots enhance instruction, which is very important for new users.

The third aspect to examine is development cycle for the application. Users treat software that does not evolve as obsolete and they replace it if an alternative is available. In the open source world the problem of OFMs is quite the opposite. There are tons of alternatives, but no leading project. On many software forums, one can see it getting crowded just before the promised release is scheduled. Extensions of a program can prolong the development cycle.

The fourth important aim is platform support. On Linux, this means desktop independence.

And the last aspect is already mentioned plug-in and extension system.

To answer what makes programmers work together, I can't give you an answer. The only thing that I found out to be universal is the "common goal." To translate this to file managers, one would have to make developers not think so guru or teach users to become programmers. There is really a lot of "one"-time contributions or using code from other open source projects. For the programmer to stick around and work with the group there must be a common interest.

Krusader Krew grew for five years to join eight contributors under one roof which demonstrates innovation, quality, and speed. Some other projects are still, under whole open source sky, managed by single person.

And what happened with finding that GNOME file manager? Well, I found three that are still developed and look ready for serious distribution: BF-commander, Tux-Commander, and Gnome Commander. The first two are both developed with Kylix 3 Open Edition.

For the time being, Krusader plus libs stays on top in my book.

Developers say that it's better to do it good under one desktop environment then poorly on many. Agreed! When the program reaches full maturity, it will probably have enough members to start its other desktop forks if alternatives fail to follow.

Related Story:
Community: Krusader: File Manager for Almost-Geeks(Dec 01, 2004)