Beta-testing SparkleShare

Open source enthusiasts who have avoided the popular Dropbox file synchronization service now have one more alternative. The SparkleShare project released its first beta last week, initially for Linux users only, but with most of the feature set already in place. The result is not an exact clone of Dropbox, but it may prove to be more useful for many in the free and open source software circle.

The beta release was announced on September 4th by lead developer Hylke Bons. SparkleShare comes in a source code package only, and although Windows and Mac OS X front-ends are said to be in the works, the code only runs on Linux at the moment. The application is split into two parts — a backend that handles file transfer and synchronization, and a front end that communicates with it over D-Bus. The current front-end is tied in to the GNOME desktop, including a panel icon, notification messages, and right-click context menu extensions for the Nautilus file manager.

The project's blog describes SparkleShare as a replacement for Dropbox, but considering the varied use cases that exist for Dropbox, such a description needs further examination. SparkleShare is specifically designed to enable teams of remote users to share and collaborate together on documents; it is not simply a single-user remote backup service. Nor does it handle concurrent editing; SparkleShare's model keeps a local copy of each shared folder on each team member's hard disk, and sends an updated version of each file to a central storage location when it is saved. It uses Git as its remote storage engine. The current release includes point-and-click support for Gitorious, GitHub, and the GNOME project's repository. An important side effect to note is that SparkleShare is not suitable for storing private data; all files synchronized through one of these public Git-hosting services is accessible to anyone.

The choice to use Git as a storage-and-synchronization service reveals something else about SparkleShare: although it is not intended to serve as a complete distributed version control system (DVCS), it is designed to coexist with one. Specifically, SparkleShare is designed to help user interface (UI), user experience (UX), and graphic design teams to collaborate remotely with each other, and to help them collaborate on projects with software developers. The concept grew out of GNOME's London UX Hackfest in March of 2010. The team is spread around the globe, and wanted an open source alternative to Dropbox — but one that would make it easier to merge their work with that of GNOME coders.

Test-drive

The beta release is designated 0.2 beta 1, and is provided as a tar archive for Linux desktops running GNOME. It is written primarily in Mono, a choice Bons tacitly admits may irritate some people (in the FAQ, he explains the use of Mono with "Because I hate freedom."). Other build dependencies also include NDesk development packages for DBus support, and Nautilus Python bindings. Runtime dependencies include Git itself and OpenSSH. Compilation is the standard ./configure, make, make install three-step.

Once installed, the SparkleShare service can be started from the command line (sparkleshare start) or from the GNOME menu. When launched, SparkleShare adds a notification area icon to the GNOME panel that holds shortcuts to each configured shared folder and a "sync remote folder" button. At first run, it also creates a SparkleShare folder in $HOME.

Before SparkleShare can be used, however, you must connect it to one or more shared Git projects on one of the supported services. The first-run screen allows you to select the service you wish to use and specify the remote project name used; it identifies the user account associated with the service by auto-generating an SSH key in the background using the full name reported by the operating system for the active user account.

The online documentation provides step-by-step instructions for Gitorius and GitHub — presumably those using GNOME Git or their own public Git repository will be able to figure out the steps through extrapolation. If you do not already have one, you must register an account at GitHub or Gitorious through the services' web sites and set up a project. You must then find and copy the auto-generated SparkleShare SSH public key and paste it into the Git-hosting service's account settings page in order to authorize access. SparkleShare allows you to link each individual project that you set up to a separate folder within your local SparkleShare folder — so you can mix and match project folders from different services and you are not required to use SparkleShare for every project that you host at one of the supported sites.

As of today, setup is not entirely point-and-click. It would be nice to allow users to register new accounts at one of the supported Git-hosting sites from within the SparkleShare client; more importantly, it would be nice to simplify the SSH public key configuration process (which requires a terminal window) and to allow users to create a new Git project (shared folder) from within SparkleShare, as this is likely to be a repeated process.

Once configured, however, SparkleShare is simple to use. Files copied to the ~/SparkleShare/someproject/ folder are preserved locally and silently mirrored to the Git-hosting service in the background. You can check the logs online to see timestamped commits and pushes, and when a file is updated remotely by another share user, a notification bubble announces it on the desktop, complete with the user's name and Gravatar image. You can even open old revisions of a file by right-clicking it in Nautilus; SparkleShare adds a "Get Earlier Version" menu that tags old revisions by who committed the last change.

0.2 is a small number

There are a few minor nuisances in SparkleShare, starting with its decision to bury its launcher in GNOME's hopelessly overcrowded "Internet" application menu. Partly this is the fault of the Freedesktop.org menu specification for creating such a generic catch-all category, but SparkleShare is a file-access tool, so it really belongs in GNOME's file access menu. GNOME's file access menu has its own problems; it is the logical choice for accessing the increasing number of online file services, including Ubuntu One, Dropbox, various cloud offerings, and so on, yet all are buried in different locations in the application menu hierarchy. Considering that GNOME also burdens its file access menu with the vague and awkward "Places" moniker (which will also prove confusing when Zeitgeist's geolocation support lands), it is understandable that no application installs a launcher there, but the end result is that users have to hunt around to find their online storage.

The interface for adding a project is also in need of some tweaking. SparkleShare works only with Git, which uses the terms "repository" and "project," both of which SparkleShare refers to as "folders." The goal of the application is to make the remote service function as a local folder inside Nautilus, but using different terminology — particularly in the setup process — is unnecessary user confusion.

Finally, although SparkleShare is designed to enable team collaboration, you currently must manually change the ownership of a Gitorious project folder to a "team" at Gitorious's web site, and add collaborators one at a time via the web interface in order to share with other Gitorious or GitHub users. As with new account registration, rolling some of this functionality into the SparkleShare GUI would help, particularly for the non-developer target audience.

There is still a long way to go before SparkleShare reaches 1.0. Windows and Mac OS X binaries are already prominently advertised as part of the roadmap. In comment threads on his blog, Bons has discussed graphical KDE client support as well as supporting other DVCS options as possible new features. There are critics who argue that Git is a poor choice for sharing large binary files, to which Bons replies that all DVCSes are poor at that task. A stand-alone "SparkleShare server" has also been requested, which Bons says he is looking into.

Exactly what such a server would entail is not specified; presumably it involves a different feature set than a public Git repository's, but whether that means simpler remote access, private data, or something else, has not yet been explained. Along the same lines, simply providing instructions on setting up a compatible Git repository would be a helpful interim step — although "on my own server" is a setup option, it is not clear what configuration options are required.

As a collaboration tool for designers on technical projects, SparkleShare already offers all of the necessary functionality. A team working on a large GitHub- or Gitorious-hosted project can set up a folder for design work (images, vector graphics, documentation, etc.) and enable its designers to keep in sync with its software developers; that is a big win.

On the other hand, it needs to be understood that SparkleShare is not a one-stop "Dropbox replacement." People use Dropbox for a wide range of purposes (including remote backups, access to profile information from multiple desktops, and even remote scripting), some of which are a terrible fit for SparkleShare. Remember that all files stored in SparkleShare are world-readable through public Git repository services — not a good fit for your private keyring. It is also not designed to easily publish large files for public access; although GitHub and Gitorious allow HTTP access to any file, they do not offer a simple "share this" URL for emailing or microblogging a file to others. But do not let any of those use-case mismatches discourage you from trying SparkleShare for its intended purpose; it is already clearly a better option than the proprietary Dropbox for those who care about free software.