Articles / fm3's fresh features: Taggi…

fm3's fresh features: Tagging

We'd like to highlight some of the aspects of the latest incarnation of in a few short articles. We hope to point out features you may have missed and share some of the reasoning behind our design decisions with our long-time users. We hope you enjoy the new site, and look forward to your thoughtfully-considered and kindly-worded comments and suggestions. In this installment: Tagging, and Trove No More.

When we launched the second version of freshmeat, we adopted the Trove software categorization system. Trove provided an extensive array of ways for authors to let freshmeat's readers know about their projects' development status, licensing, programming language, target audience, etc. It's been very helpful in letting everyone browse through categories and refine search results to find just what they want.

Trove on fm2

Unfortunately, no matter how thoroughly such a system is designed, it inevitably has to be updated as the software culture it supports changes and evolves. We've had to add many new Trove categories each year, and authors still have to shoehorn themselves into our predefined boxes.

For fm3, we're replacing Trove with freeform tags which authors can use as they please. We hope this will provide some futureproofing, allowing authors to create new categories as needed without having to lobby us to add this new operating system or that new mobile device.

Project release announcements can also have tags attached, letting authors provide more specific indications of a release's purpose than our fm2 "Release focus" of "Minor bugfixes", "Major feature enhancements", etc.

Example of tags

For users, the experience will be much the same. Tag filters will simply replace Trove filters. Users can filter undesired tags globally and refine search results to include or exclude certain tags. We hope that, as authors update their own categorizations, you'll begin to see more meaningful information as you use the site.

Tag filtering

One aspect of this change that gives us pause relates to licensing. Users like to have a clear idea of how a project is distributed before they invest time in researching it. With authors entering licensing information as tags, it may be harder to get a quick and definitive answer to this question. The type of license may be left out altogether, or different authors may use slightly different tags for the same license, making it difficult to filter in a reliable way. At the moment, we're thinking of continuing to provide a list of categories for licensing only. New licenses don't appear with such great frequency, and we could keep that one list up-to-date. Under this scheme, the license selected by the author would be converted to a tag, allowing the tagging/filtering system to be used for licensing while providing consistency across projects.

We realize that tagging is one of the biggest changes in fm3 and perhaps the one that will take the most getting used to. The current Trove categories will be imported as tags with their projects at the time of fm3's launch, so you'll have a better feel for how the new system will work at that time. For now, please continue experimenting with submitting tagged projects and releases on the beta site, and let us know how it's going.

Articles in this series:

(Haven't seen freshmeat3 yet? Sign up!)

Recent comments

14 Feb 2009 12:48 Avatar ed_avis

Re: Licensing

It's a mistake if that slips through.
It's our editorial policy that,
in general, a project's description
should not replicate information found
in its Trove categories (and soon, its

I wasn't aware of that. Taken strictly, this would forbid writing 'Sawfish is a window manager' if you also ticked the Trove category 'X11 / window manager', so there must be some latitude.

In general, English text describing a program's implementation is interesting to read and often useful. Sometimes a program's main feature is that it demonstrates a new algorithm or language. So there is no reason to forbid it outright, but end users trying to use Freshmeat as a software map aren't usually helped by it.

OTOH, having a single text box for all information (what it does, how it does it, why it was written that way, which project it was forked from, etc) does keep things simple.

13 Feb 2009 18:31 Avatar jeffcovey

Re: Licensing
Thanks for the suggestions on licenses, Ed!

> often the program descriptions read like

> 'X is a C++ program to manage your calendar'

> rather than 'X is a program to manage

> your calendar'.

It's a mistake if that slips through. It's our editorial policy that,

in general, a project's description should not replicate information found

in its Trove categories (and soon, its tags). There are many, many

descriptions still around from fm1, but we try to catch this on new




12 Feb 2009 19:52 Avatar cristof

Re: Licensing
I agree with the request. The license information has an important role when we search software to be used in companies and public administration. I haven't found a way to filter the projects by licensing information on the new freshmeat "incarnation".

12 Feb 2009 14:17 Avatar ed_avis

I think it would be a good idea to keep the licence information structured rather than free-form tags. If there is a list of licences, then each should be a checkbox so you can tick two or more of them: this would allow for dual licensing (e.g. GPLv2 or later, which allows GPLv3) and remove the need for special kludges like 'Perl licence'.

If a licence is not in the list, perhaps the user could enter the name of it, tick a couple of boxes for 'is it free' and 'is it GPL-compatible', and give a URL or of the licence text. After a quick review the site admins could add it to the list.

If I might add an unrelated wish: often the program descriptions read like 'X is a C++ program to manage your calendar' rather than 'X is a program to manage your calendar'. In other words functionality (of interest to a user deciding whether to try this program) gets mixed in with implementation details (of interest to someone wanting to hack on the code).

It might be better to have two description fields: in the first one you enter what the program does, and optionally in the second one you enter technical stuff which is important to developers but not visible to end users. For libraries and other packages not aimed at users directly, a single more technical description is fine.


Project Spotlight

Kigo Video Converter Ultimate for Mac

A tool for converting and editing videos.


Project Spotlight


An efficient tagger for MP3, Ogg/Vorbis, and FLAC files.