I’ve been a member of our local Freecycle mailing list for a few years, successfully using it to offload and acquire various items, from a double futon bed to an mp3 player.

In 2006, Giles Turnbull blogged about Freecycle’s shortcomings, from a usability and webapp point of view. It boils down to “Freecycle is a great idea unsuited to living inside a mailing list once the size of the list is >100 people”. Giles’ proposed solution was a web app, and his post contains some pretty detailed design descriptions. I’m sure that there’s an interaction designer in Giles trying to get out

(There’s probably something interesting there about group psychology and Dunbar’s Number, but I’m more interested in finding a practical solution.)

Other people have tried to build Freecycle-like philosophy in a webapp form, e.g. SnaffleUp, but they (so far at least, but it’s early days) lack the one thing Freecycle has in spades: a critical mass of users. Oh, and a snappy brand.

What if, instead of building a Freecycle-like webapp in competition with Freecycle, an app were built on top of the existing mailing lists, teasing out all that lovely data and metadata and making it queryable, sliceable, diceable and geo-plottable?

There are three pieces of information pertinent to an item on Freecycle:

• what it is
• where it is
• whether it’s still available

There’s no API to Yahoo Groups at the moment, but it’s possible to get Freecycle mails sent to a mail account on a *nix box, where they could be parsed and inserted into a database for querying by item name, description or location. If we group items by sender, it should be possible to determine that when a “taken” follows an “offered” with the same/similar subject line, then that item has changed from being available to unavailable.

All of that data is present in a Freecycle email, but the inconsistent way in which people format their subject lines makes parsing out the item and location a bit of a challenge.

An ideal Freecycle subject line looks like this:

[BathFreecycle] OFFER: Cat basket (Combe Down, Bath)

However, they are often more like this:

[BathFreecycle] offered cat basket bath

(As an aside, Bath’s Freecycle list is a great test case, as the name of the city is also the name of an item. Supposing someone wrote “Offer: baby bath”, one would assume that they weren’t trying to offload their offspring but had merely omitted their location. Formalising this in the parser would be hard, if not impossible, such that it may have to be flagged for review by a human.)

A way around this would be to prime the parser with a list of possible locations. Once you remove the list name, the offer/wanted/taken/received prefix and the location, you’re left with the item.

The variability of people’s use of grammar, spelling and format (despite the fact that your messages are moderated until you’ve demonstrated that you can write a subject line properly) makes the subject parser the biggest challenge in implementing this solution.

All of this does raise the issue of increased ease of, and cross-group, querying. Already there are scammers on Freecycle lists, making bogus offers then directing people toward pyramid schemes and the like. Also, it’s seen as bad form to post the same item to more than one group simultaneously; having said that, it’s ok to subscribe to several lists (if you can keep up with the volume of email).

This geocoded database would make it much easier for people to snap up “big ticket” items, possibly to sell on (it happens at the moment). If Freecycle’s aim is purely to keep usable or servicable items out of landfill, does this really matter? Also, I can imagine the central Freecycle organisation not being happy if this “hack” were built on Freecycle outwith their blessing and control.

I know other people find Freecycle frustrating. Does this (very rough) outline of a solution sound like it makes sense?