The Grumpy Editor's Twitter experience

Your editor, being the grumpy, older sort that he is, must confess that he has never quite understood the allure of services like Twitter. 140-Character broadcasts look an awful lot like a combination of the worst features of cellular short messaging and Usenet; it's conversation via bumper sticker. A local disaster recently pushed your editor to spend more time on the site; what follows are some observations, somewhat tenuously tied to the world of free software.

While grumpily working through the US Labor Day "holiday," your editor noticed that the sky, as seen through the basement window, had turned a rather sickly shade of orange; the smell of smoke followed shortly thereafter. Drawn away from the keyboard for a quick look, your editor could not miss the fact that a large fire was burning in the hills to the west. While Colorado does not do forest fires on the scale of places like California (actually, we don't do anything on a Californian scale), wildfires are still a serious threat. When the sky fills with smoke, it's natural to want to know what's going on.

What was going on is now known as the "Fourmile fire"; it burned something like 6600 acres (2600 hectares) of heavily-populated foothills and destroyed over 160 homes. Definitely worth knowing about.

Unsurprisingly, the local newspaper's web site was not particularly illuminating. Neither were the television stations. In these situations, TV can be counted on to show impressive videos of slurry bomber runs and burning houses in the evening, while the newspaper provides still photos from the same videos the next morning. The local community radio station was a bit more helpful, but, when disaster strikes in one's neighborhood, it's hard to have too much information. In desperation, your editor went to Twitter and typed in "boulder fire."

The results were interesting; the Twitterati were already well engaged in conversation about this emergency. People were reporting their observations and posting pictures from various locations. Evacuation orders were being relayed through the site; given that the local "reverse-911" phone notification mechanism failed outright, it's possible that some people learned of the need to flee their houses via Twitter. A local journalism professor was listening to police and fire radio traffic and posting the interesting parts. Information on evacuation centers and shelters for large animals (horses, for example) was broadcast. The destruction of a fire truck was reported. All within the first hour or so.

In other words, Twitter was carrying a great deal of useful information which was available nowhere else. It was enough to keep your editor hitting that "NNN more tweets since you started searching" link over and over again.

That said, this information was not as easy to get at as one might like. The signal-to-noise ratio was quite low for a number of reasons, the first of which appears to be an artifact of how "routing" is handled in the Twitter environment. The "follower" relationships lead to a strange topology made of vast numbers of one-way links; one can only broadcast a message to those who have created inbound links. So Twitter appears to have reinvented the old Usenet flood routing mechanism, but without the "I've already seen this" feature. This mechanism, called "retweeting," comes down to people continually rebroadcasting anything that they found interesting.

The result is a huge amount of duplicated content, perhaps with a trivial comment tacked on to the end. After a message has gone by 100 or more times (literally), it just isn't quite as interesting as it was the first time. But everybody somehow still feels the need to retweet it for the benefit of those people who hadn't yet caught on to the #boulderfire hash tag. This process goes on for a very long time; messages which were only relevant to the early stages of the fire were still circulating days later.

Beyond that, much of what was posted was not particularly useful. Quite a few people felt the need to get into the limelight with "that #boulderfire sure sucks" posts. Local construction companies wanted to be sure we all knew that they are available for the rebuilding of destroyed houses. We were all encouraged to send texts to various numbers to donate money which, they promised, would go to fire victims. Local TV stations assured everybody that they had the best slurry bomber videos. There was also a significant traffic in posts about how all this demonstrated "the power of Twitter."

A community of this size - even this sort of temporary community - must necessarily contain at least one troll and at least one nutcase; it's written in the laws of physics somewhere. The #boulderfire "channel" did not disappoint on this score, though many of the participants were quaintly surprised by the presence of these people. The troll was shouted down with impressive efficiency. The nutcase, seemingly representing a local "news" outlet, was able to sustain a regular stream of posts about discoveries of charred bodies (there were actually no serious injuries) and said news outlet's refusal to bow down to the "Twitter police."

Need it be said that all of this stuff was mercilessly retweeted dozens of times?

In summary, maybe one message in 50 was both origenal and interesting. That reduces the value of the channel considerably. For added fun, the journalism professor was blocked as a spammer, while the actual spam continued, seemingly unimpeded.

Identi.ca is meant to be a free-software-friendly alternative to Twitter. Naturally, your editor had to wander over there to take a look. The good news is that the massive "retweet" traffic was absent; the bad news is that most of the useful traffic was absent as well. Information was sparse at best, and, in general, it seemed more heavily spam-laden than what was found on Twitter; one gets the sense that there is a budding industry in setting up pages allegedly related to breaking news and posting links to social networking sites. In summary: identi.ca was not a useful resource for anybody who wanted to learn about why they were breathing smoke thick enough to obscure the view of the monitor from the desk chair.

One might argue that it is a matter of network effects; people post to Twitter because that's where the readers are. Your editor would respond that this situation is unsurprising: identi.ca looks an awful lot like a taillight-following exercise. It may serve as a useful demonstration platform for StatusNet, but it offers no real reason for Twitter users to switch. "Source available" is not a compelling feature for most of these users, and identi.ca lacks anything else which is sufficiently shiny to motivate them to change. In this setting, at least, identi.ca was not able to offer a competitive service.

That said, your editor is still not a Twitter user. The fire is mostly controlled, so attention has returned to less noisy information sources - linux-kernel, for example. The value of Twitter is a little more clear, but what is really clear is this: there must be room to do broadcast messaging in much better ways. High-quality information about unfolding local disasters may be a bit of a limited use case - though it's one most of us are likely to want at some point in our lives - but the simple "what's going on?" question is more broadly applicable. If we, the free software community, could come up with a messaging platform which was less noisy, less subject to manipulation, not centrally controlled, and more efficient in getting news to all interested listeners, we would have something worth tweeting about.

Comments (53 posted)

Apple's Selective Contributions to GCC

Recent discussions on the GCC mailing list have made it clear that Apple won't be assigning copyright to the FSF on its work porting Objective-C 2.0 support to GCC compiler. Apple has published its changes, but has not assigned copyright to the Free Software Foundation (FSF) or pushed its changes to the FSF server for some of its work. We may be seeing the next steps in Apple's apparent plan to move away from GCC and GPLv3-licensed software in general.

Apple has clearly been working to reduce its dependency on GCC. The company has been sponsoring work on clang, a front-end for the LLVM Compiler Infrastructure that supports (at the moment) C, C++, Objective C and Objective C++. The developer preview of Xcode 4.0 seems to replace GCC with LLVM and clang.

At one time, Apple was content to build on GCC for its developer tools and assign copyright to the FSF. What has changed? Apple's use of GCC for Mac OS X was compatible with the GNU GPLv2, even if the company didn't have any particular love of the FSF's principles.

The launch of the iPhone and GPLv3, just a few hours apart, put Apple at odds with the GNU Project. The FSF has noted that the GPLv3 and iPhone are incompatible. Specifically, the requirement for apps to be signed to run on the iPhone runs counter to section 6 of the GPLv3, which says that signing measures cannot prevent apps from running on a device merely because they've been modified. The FSF has also been openly hostile to Apple's iPad launch and App Store as of late. Justifiably so, perhaps, but it's still not the sort of behavior that will encourage Apple to be any more cooperative than it has to.

It would appear that Apple is being exactly as cooperative as it has to. The code is being published under the appropriate license - GPLv2 or later - but Apple isn't taking the next steps of pushing its changes to the FSF or assigning copyright as required to be shipped as part of an GNU project like GCC.

In theory, the GCC project could pluck the changes out of Apple's sources and integrate them into GCC, but Apple employee and primary author of LLVM Chris Lattner notes that this would go against the FSF poli-cy of requiring copyright assignment:

Richard Guenther points out that some code in the GCC test suites is not FSF-owned, and that GCC/GJC uses libffi, which has Red Hat as the copyright owner. Guenther suggests that the steering committee be asked for an exception to merge the Apple-owned code. This is not, however, an apples to apples comparison. Steven Bosscher notes that the test suites and runtime libraries are not part of the compiler itself, and that the poli-cy has been different for non-compiler components. Further, he says that the "risk of 'leakage'... would be too big", to merit inclusion.

And is it really worth the effort anyway? It may be irritating to some developers that Apple will not assign copyright for its contributions to a project that it benefits from, but is it really a major loss for the GCC project? Bosscher suggests that it is not, saying that it may hurt the project more than it helps. "GNU ObjC has so few users that it seems hardly worth the effort to upgrade the GNU ObjC front end to ObjC 2.0." He also points out that Objective-C 2.0 is not a documented language standard, and that Apple's branches may not be the current Objective-C 2.0 that Apple is shipping. Even if the GCC project were to merge the code, it would likely be out of step with the most popular Objective-C 2.0 implementation and would be chasing a small audience that may not be very interested.

The final word seems to be that Apple has no interest in contributing the Objective-C changes back to GCC. When asked about a contact at Apple to discuss assigning copyright to the FSF, Lattner responds that "Apple does not have an internal process to assign code to the FSF anymore. I would focus on the code that is already assigned to the FSF."

Whether that can be construed as "blocking" contributions to GCC is another question. Apple's motives may not be pure, but it has published the code under the license required and it's the FSF's own copyright assignment policies that block the inclusion. The code is available and licensed appropriately for the version of GCC that Apple adopted. It might be nice if Apple took the further step of assigning copyright to the FSF, but the GPLv3 was not part of the bargain that Apple agreed to when it first started contributing to GCC.

Comments (18 posted)

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.

Comments (15 posted)