As your editor reviewed his 2010 predictions, the thought that often came
to mind was "obvious" or "boring." Making obvious predictions may be a way
to boost your editor's sense of omniscience (said omniscience,
unfortunately, only being acknowledged by your editor's dog), but it takes
away some of the fun. So, this time around, an attempt has been made to go
just a little further afield. With luck, it will make for some fun in
December when it is time to come back and laugh at how bad these guesses
The LibreOffice fork will take off, taking most of the
wind out of OpenOffice's sails by the end of the year. StarOffice may
continue as a commercial product, but its user base will be small.
LibreOffice will improve considerably in this time but, your editor
confidently predicts, it will still be too big and still really annoying to
The Mageia and IllumOS forks will fare less well. The Mageia folks
have seemingly been mostly concerned with lengthy discussions about the
layout of the package repositories so far; no release is in sight. More to
the point, though, it seems that the rumors of Mandriva's demise may have
been a little exaggerated. IllumOS looks like it may lack a critical mass
of developers, and some of the most committed people appear to not get
along very well. It's not at all clear that anything derived from Solaris
will have relevance in the free software world for long.
MeeGo will be a surprisingly big success. Android is increasingly
looking like the Windows of the handset world - a universal operating
environment which turns the hardware into a boring, low-margin commodity
product. Manufacturers will be keen to see a competitor which allows them
to differentiate themselves and to limit Google's control.
Along those same lines, it will be a make-or-break year for WebOS,
which has yet to make a lot of waves under HP's management. Should the
system be released on (relatively) open handsets, it may yet surprise us.
Google will take its place as a major kernel contributor. Google is
already a massive contributor of code to the community, of course, even if
its "throw it over the wall" style does not suit everybody. Over the
course of the last year, though, your editor has noticed an increase in
Google engineers showing up at conferences and discussing the company's
needs. Google folk are increasingly being allowed (and encouraged) to come
out and play, and everybody will benefit from that.
ChromeOS will struggle this year. The need for another "thin
terminal" system is not entirely clear, especially once ChromeOS users
discover that they can get a real Linux-based operating system on the
same hardware. That "real" system may be a netbook-oriented distribution,
or it may be some form of Android. Either way, it only takes one must-have
application to drive users toward a distribution which is oriented toward
the installation of local applications.
We will see huge legal and technical battles as governments and
corporations try to restrict what can be done on the net. Futile attempts
to shut down sites like Wikileaks or to stop those who would demonstrate
the weakness of the cellular network can only lead to an increase in
repressive actions worldwide. Efforts by network providers to increase
revenues will have similar effects. It will be a tumultuous year.
Targeted attacks will increase; Stuxnet, said by some to have
destroyed 1000 centrifuges in Iran, is only the beginning. Security will
be a bigger deal, and Linux will benefit from an increased emphasis on
security. That said, alas, it would not be surprising to see a successful
Stuxnet-like attack against Linux-based systems this year.
A free driver for an embedded graphics chipset will be released by a
previously recalcitrant vendor. Embedded graphics is currently one of the
most problematic areas for free support, but the commercial pressures will
prove to be strong enough to motivate at least one vendor to open up. It
is a pattern we have seen many times in the past.
At the distribution level, the tension between providing stability and
providing current software will increase. Fedora has already had
significant amounts of internal strife around this issue; at the other end,
users of stable "enterprise" distributions often find themselves needing
something newer. In 2010, we saw Oracle basing an enterprise distribution
on a newer kernel; in 2011, we'll see more attempts to provide the best of
openSUSE will change in response to the above-mentioned pressures
and others; by the end of the year we may see ultra-stable and leading-edge
variants of openSUSE alongside the current "just right" distribution. What
will happen to Novell and SUSE under Attachmate is hard to predict, but
openSUSE will continue to thrive regardless.
Business models based on control of the code will fade in prominence
over the course of the year. It will become clear that "open core"
programs, while being free software, do not generate the sort of community
that truly brings code to life. Projects requiring copyright assignment
will increasingly be seen in the same light - especially those projects
which are owned by for-profit corporations. Neither open core nor
copyright assignment will go away in 2011, but developers - who already
favor more open and diversely-owned projects - will shy away from them.
Need we conclude by saying that Linux and free software will finish the
year stronger than ever? That was clear in late 1997 when LWN was in the
planning stages, and it hasn't changed since. This year will certainly
have its ups and downs, but our community will find itself in great shape
at the other end.
Comments (33 posted)
The Mozilla Foundation released "beta 1" of its upcoming revision to the Mozilla Public License (MPL) last month — the license's first update in more than a decade. Mozilla first set out to shorten, simplify, and modernize the MPL in March of 2010, developing the preliminary revisions based on feedback from its own license compliance team and talks with the Free Software Foundation (FSF) and Open Source Initiative (OSI). MPL 2.0 Beta 1 is open for public comment, which the project hopes to incorporate into a final release candidate in the coming months.
Rewriting in public
The current MPL is at version 1.1, which debuted in 1999. Back at the beginning of the update effort, Mozilla defined a set of issues it wanted to address in the new revision. These started with simplifying both the language of the license as well as its requirements; common terminology in software licensing has changed over the last ten years, and downstream MPL users found several of the notification and re-licensing requirements confusing or difficult. Although the MPL is specific to Mozilla, and derivative licenses could alter jurisdiction-specific terms, Mozilla's global developer community reportedly had trouble with US-centric copyright- and contract-law language, necessitating some globalization work.
Perhaps the most far-reaching changes to the MPL are those that affect its compatibility with the other top-tier FLOSS licenses: namely the GPL, LGPL, and the Apache license, which is a popular choice for web-oriented projects. In addition to Mozilla itself, some high-profile projects use derivatives of the existing MPL, including Sun's Common Development and Distribution License (CDDL), the Yahoo Public License, and several individual projects, such as Erlang and SugarCRM.
Mozilla made it clear at the outset that it was committed to remaining
an open source
license as defined by the OSI and both a copyleft and free software license
as defined by the FSF. However, the project also stated clearly that it
would not be considering two potential changes: moving from the existing
"weak copyleft" to a "strong copyleft," and incorporating a
Software-as-a-Service (SaaS) clause à la the AGPL. Mozilla reasoned that the former change would radically impact the way Mozilla projects function, and the latter — although an important issue — is controversial enough that it would overshadow the work of updating and modernizing the rest of the license.
The first "alpha" draft of MPL 2.0 was released in July, written by Mozilla's MPL team, and was followed by two more alphas in September and October. Although the initial feedback mechanism was the MPL-Update mailing list, beginning with alpha 2 an HTML version of the license was published at the web-annotation site co-ment.com so that interested parties could mark up and comment on specific lines and phrases. Using that system, interested parties can add comments to a shared version of the the current revision, which will be reviewed by the project team.
The co-ment.com utility is very easy to work with, although it allows
any user to attach a name and email address to their mark-up without
address verification — so be wary if you spot suspiciously-exuberant
cheers attributed to key FSF officials (for the record, I did submit four
grammatical comments under the username "n8willis" just to see how it
worked). Mozilla notes that co-ment.com itself was inspired by the FSF's
annotation tool used in the GPLv3 comment process. It seems a bit
ironic that Mozilla chose to utilize a closed-source tool rather than
the original — although FSF's own description of the tool as
"daunting-to-install" suggests one simple explanation.
The MPL 2.0 alphas were low-profile announcements, but the December beta
was the subject of a blog
announcement by Mozilla's Mitchell Baker, soliciting comments from the
public at large. The draft license is available as plain
and is accompanied by a discussion
document [PDF] that includes justifications for the major changes, plus a full diff between beta 1 and alpha 3 and a full diff between beta 1 and MPL version 1.1.
The terms they are a-changin'
Most of the changes, naturally, took place between MPL 1.1 and the alphas, though 2.0 beta 1 brought its share of tweaks. The new license is approximately 38% shorter (2289 words, down from 3702), thanks to the removal of several definitions in section 1 and some redundant language, plus the consolidation of several sections (such as independent references to requirements that persist in future versions of the MPL). The substantive changes begin with the removal of all instances of the terms "Original Software" and "Initial Developer." These terms were used in MPL 1.1 to make distinctions between the creator of an MPL-licensed work and subsequent contributors; now all "Contributors" and "Contributions" are treated equally.
There are also simplifications in section 3 about distributing executables. MPL 1.1 spends some time discussing the differences between distributing source code and executables, enumerating rules about placing source code on the same physical media as executables, and honoring written offers. The 2.0 beta dispenses with most of that in favor of a much shorter "You must inform third-party recipients of the Executable form how they can obtain a copy of such Source Code form by reasonable means, at no more than a nominal charge." In a related change, section 1 also abbreviates the older version's discussion of what constitutes "source code" — calling it the "form of the work preferred for making modifications." This is meant to simplify debate over things like scripting languages, where the line between executable and source becomes fuzzy.
The beta also simplifies the notification process required of derivative
software makers in section 3 considerably. MPL 1.1 required them describe
any changes that they made to the MPL source code, to inform their users of
all third-party intellectual property claims they were aware of that
pertained to the code, and to document API changes that would be affected
by patent claims. In several places it even specified that these
notifications must be done in a file named LEGAL.The revised section 3.1 states that source distribution
requires you to "inform recipients that the Covered Software is
governed by the terms of this License, and how they can obtain a copy of
this License." Section 3.2 says that executable distribution
requires you to make the source available as described in 3.1, and
"inform third-party recipients of the Executable form how they can
obtain a copy of such Source Code form by reasonable means, at no more
than a nominal charge." Reasonable means and nominal charge are
not explicitly defined.
Section 5.2 is the "patent defense" clause, stating that initiating litigation (against any entity) involving a patent claim against the software terminates the license. This section was rewritten so that its language was compatible with the Apache license, closing a much-lamented inconsistency between the two. It also explicitly excludes several types of defensive litigation (such as seeking a declaratory judgment) from triggering the termination clause, and clarifies some grace-period language pertaining to restoring someone's right to redistribute the software if they come back into compliance with the license.
The globalization improvements are found in the "Miscellaneous" section, section 8. While the MPL 1.1 specified that litigation about the license could only be brought in the Northern District of California, the new license requires it to be brought in "the courts of a jurisdiction wherein the defendant maintains its principal place of business and such litigation shall be governed by laws of that jurisdiction" — which is seen as simplifying the situation for third-party code contributors.
Section 9 updates and clarifies the Mozilla Foundation as the sole steward of the MPL, removing all lingering mention of Netscape Corporation, and simplifies the language dealing with creating new licenses based on the MPL (essentially, references to Mozilla must be removed and the name of the license changed).
Compatibility with the FSF's license portfolio is dealt with in a new manner in section 10. While MPL 1.1 touched on other licenses only in a "Multiple Licensed Code" section which permitted the Initial Developer to provide a license choice, MPL 2.0 beta 1 allows anyone to designate their own contributions as "Compatible Software" with the GPL (2.0 or later), LGPL (2.1 or later), or AGPL (3.0 or later). Section 10.3 further specifies that developers may distribute a combined, derivative work based on MPL 2.0 code under one of those licenses, provided that they make their own contributions available under the MPL.
These requirements attempt to deal with one of the Mozilla community's unique sticking points, the "single-license fork". The problem occurs when a project builds on top of Mozilla code (which is tri-licensed under the MPL, GPL, or LGPL), but only releases modifications under one of the non-MPL licenses, thus effectively cutting it off from use by other tri-licensed Mozilla projects.
The revised MPL will probably only have a direct impact on two distinct
sets of users: contributors to official Mozilla projects that live in
non-US jurisdictions, and developers of outside, derivative projects. The
former group benefits from the clearer language around copyrights and
patents along with the generalized rules about litigation and jurisdiction.
The latter group gets a mixed bag; better compatibility with GPL and Apache
licensed works is a definite plus, while those players not interested in
licensing their contributions under the MPL may not like the closing of the single-license fork loophole.
On the other hand, the reorganization and simplification of the license text benefits everyone. Ten years is a long time in this industry, and although most people's understanding of the issues and terms used in the MPL has not changed in that time, Mozilla has learned from experience that some of the requirements and clauses were not having the desired effect. The principle example of this is MPL 1.1's section 3.3 — the requirement that downstream redistributors describe all modifications made to the original code and include a statement telling users that the files have been modified from their original forms. Mozilla admits in practice this requirement is usually ignored, and in the era of distributed version control it adds little value.
It will be interesting to see how many of the changes proposed for MPL 2.0 are adopted by downstream licenses. Some, particularly those from projects that build on the Mozilla codebase like Celtx, will likely release new versions of their own licenses to maintain language compatibility.
It's less clear what will happen to the corporate controlled licenses like CDDL. CDDL has entertained proposed revisions on its own development path since its creation, and few if any of Sun's CDDL-licensed products interact with official Mozilla code. It is interesting to note, however, that several of the changes made to CDDL from MPL 1.1 are also incorporated in MPL 2.0 beta 1: use of the term "Software" instead of "Code," elimination of several definitions, and simplifying the distribution requirement language.
On that subject, however, it is also interesting that the CDDL's authors chose to widen the definition of distribution so that it includes application service providers, while Mozilla chose not address network applications at all. The project clearly needs to do so at some point, not just because of its stated commitment to the open web philosophy, but because it develops several high-profile web applications itself: Bugzilla, Bonsai, Tinderbox, Skywriter, Firefox Sync, and the Mozilla Labs Raindrop experiment.
Looking at the comments and the mailing list, there does not appear to be much call from the public as a whole for Mozilla to take a stronger copyleft stance. To review, MPL is regarded by the FSF as a "weak" copyleft because it uses a "per file" copyleft model. In other words, if you make changes to a source file, the modified file must be released under the MPL. But you can link the original MPL-ed software to other code that is published under any license at all (including a proprietary one). In contrast, the LGPL regards linking two applications or libraries as triggering the LGPL's license on the combined work.
Luis Villa, who has spearheaded the public comment and feedback process
for MPL, says that the final MPL 2.0 is a "'release when ready'
old-school open source process" that may involve another beta before
any release candidate version is published, if there are enough comments or
questions. The comment system for beta 1 remains open to the public until
the team decides otherwise, as does the MPL-Update mailing list. Finally,
for those with comments they wish to share away from the public's prying
eyes, Mozilla has also established a "private feedback" email address.
Licenses are rarely regarded as exciting and cool, but as everyone in the FOSS universe knows, they constitute the backbone of what keeps free software free and open source open. Of the major licenses in use today, MPL is the second oldest in terms of when it was last updated — only the minimal and unrestrictive MIT/X11 license has gone longer without a refresh. Opportunities to participate in the license-drafting process are rare — so if you have a concern, the time to speak up is now.
Comments (16 posted)
Like many people, I get almost all of my news online. To get it quickly
and efficiently, I use a newsreader to skim the RSS or Atom feeds from
sites (like LWN) that I find useful. Until recently, I'd been using Google
Reader as the best option to manage and read my feeds — but after
hearing about the Mutt of
newsreaders, I decided to skim the open source options for news reading to see if I could make the switch.
The first on my list was Newsbeuter. The name is a play on "Wildbeuter," which is German for "hunter-gatherer," which seems apt enough for how one forages for information today. Newsbeuter is a text-based newsreader that bears more than a passing resemblance to Mutt, not just in appearance but also in configurability. I also found it interesting because it offered synchronization with Google Reader — meaning that it should be a simple thing to maintain my existing feeds without any real hassle.
The 2.3 release of Newsbeuter was released in June, so I compiled that and set to work. Note that 2.3 is packaged for Fedora, but not for Ubuntu which still carries the 2.2 release. That release has some issues with Google Reader sync, so if you're on Ubuntu or an Ubuntu-derived distribution and want Reader support you'll need to compile from source. Note that Newsbeuter also supports Bloglines, but I don't have an active Bloglines account.
I started with my Google Reader account and found that Newsbeuter works as advertised — albeit with a bit of work. The release notes for Newsbeuter say that it supports not only syncing with Google Reader, but also the sharing and starring features in Reader. If you share an article in Google Reader it can be seen by any of the people "following" your account (an attempt by Google to dip into social networking). Starred articles are saved for later. These work, but it requires editing the Newsbeuter configuration file and setting up "flags" for starring and saving. Newsbeuter doesn't support commenting on articles through Google Reader, however, but truly dedicated users can follow this guide by Aaron Toponce to use Newsbeuter and Mutt to add comments to items shared through Google Reader.
The display for Newsbeuter is much like Mutt — when you open Newsbeuter, all the feeds are displayed in a long list that includes the number of articles available and how many are read/unread. You drill down by feed or using tags (more on that shortly) to sort the feeds or articles you want to display. Everything, of course, is keyboard-driven and once you have the keystrokes down you can skim through feeds very quickly and efficiently. Even when managing hundreds of feeds and syncing with Google Reader, Newsbeuter was always speedy.
Want to save something for later? Newsbeuter will save any article as a text file, with URLs from the article saved as footnotes in the feed. If you've used Mutt, Pine, or another text-based mail reader, Newsbeuter will feel quite familiar.
Newsbeuter does more than just fetch, display, and save feeds, of course. It has advanced features that let users filter, tag, bookmark, and even script interactions with their RSS feeds. You can set up tags for one or more feeds and use those tags to show (or not) specific lists of feeds. This is done automatically if you're importing feeds from Google Reader — Newsbeuter sets up tags for each folder (if any) that you have used to organize feeds in Google Reader.
Newsbeuter supports a "killfile" for feeds, so users can weed out specific topics. This works by feed or across all feeds. For example, you could set up a killfile to ignore any articles from LWN's RSS feed that contains the name of a distribution that you don't care about.
It also supports "query feeds," which are special feeds created from running a query on one or more feeds. This is a filter that is created from the cache of downloaded articles. For instance, you could set up a query feed that shows only unread articles, or groups the articles from two or more feeds. Queries and other filters can be built using the filter language for Newsbeuter, which is fairly expressive.
Since Newsbeuter is a text program, it leaves something to be desired in displaying feeds that feature much in the way of graphics. Since I subscribe to several picture of the day feeds, such as the Astronomy Picture of the Day feed, I needed to find a way to open certain items in a regular browser. Newsbeuter, of course, has a command to open feeds in an external browser — and this can be configured to work with any browser from Lynx to Firefox.
Newsbeuter even features a limited command mode so users can modify Newsbeuter's configuration on the fly, save articles, and jump through article feeds.
In short, Newsbeuter can be configured every which way from Sunday. The color scheme, how feeds are displayed, how articles are bookmarked or saved for later — it's one of the most flexible feed readers that you'll encounter. It's also one that requires a certain amount of dedication — configuring Newsbeuter to work just right can take quite a lot of experimentation. Like Mutt, this pays heavy dividends for users who spend a great deal of time skimming feeds. For casual users, Newsbeuter is probably overkill.
For podcast fans, Newsbeuter also includes a podcast manager called Podbeuter. It handles downloading podcasts and can be configured to pass podcasts on to helper programs to play the podcasts. Not being a podcast fan, this isn't something I've made extensive use of, but it's a vital feature for many users.
Newsbeuter source is available from Github, and is under an MIT/X license. If you're compiling from source, it requires Structured Terminal Forms Language/Library (STFL), SQLite 3.5 or newer, libcurl, and several other dependencies that might not be available by default.
Aggregation and mail readers
Newsbeuter, like Mutt, is swift, efficient, and highly configurable. But Newsbeuter isn't actually integrated with Mutt. For users who want to tie feeds into their mail client, Linux offers quite a few RSS/Atom-friendly mailers.
For users who want to tie feed reading with their email, Evolution, Thunderbird, and Claws Mail can all handle the task. Thunderbird has built-in support for feeds, whereas Evolution and Claws Mail require a plugin to be able to consume RSS. Claws actually requires two plugins for feeds if you want to render HTML properly, as Claws doesn't handle HTML without enabling an HTML viewer in addition to the RSSyl feed plugin.
For processing RSS feeds, Thunderbird seemed to handle importing and fetching feeds faster than Claws or Evolution. Evolution was by far the slowest to import the feed list I exported from Google Reader. As for reading feeds, it's really a matter of taste — and if you choose to read feeds from within the mail client, it's probably because you've already settled on a mail client. The main complaint I had with Thunderbird was that it didn't respect the folder hierarchy when importing my feed list from Google — it choose to import more than 100 feeds into separate folders for each feed, rather than recognizing the folder organization that was set up in Google Reader.
Aside from GUI mail clients with aggregation features, you'll find quite a few standalone GUI clients as well. The offerings are far too numerous to describe each in depth, but some of the most popular are Blam, Liferea, Akregator, and RSSOwl.
Blam is part of the GNOME Project, and ideal for users who want a minimalist approach to feed reading. It provides all the basics that users would need to manage and read a set of feeds — but that's about it. For instance, unlike many readers, Blam has no way to save an entry for later use. It also is limited to one entry at a time — most GUI readers allow the user to open multiple entries in new tabs or a new window. It's a decent choice for users who have just a handful of feeds, and don't want to save feeds for later, but if configurability is desirable, Blam isn't the best choice.
Liferea is a more flexible GTK-based option. It offers several modes to view feeds, a tabbed interface (to view multiple entries/feeds) and integrates with external services to bookmark items from feeds that users would like to save for later or share on social services. Liferea supports everything from Delicious to Twitter, and quite a few more.
Another bonus for Liferea is integration with Bloglines and Google Reader. You can manage feeds locally, or just hook Liferea into a Google Reader or Bloglines account and go. Its rendering of Google Reader feeds is another story. Liferea ignores folders, so all Google Reader feeds are displayed as a flat list. Liferea also gets bogged down a bit when handling hundreds of feeds — so it may not be the best choice for power users who have a long list of feeds to manage. When using Liferea connected to my Google Reader account it was very boggy, and had problems parsing some of the feeds.
Akregator is a full-featured feed reader that integrates with the Kontact suite for KDE, or runs as a standalone application. Like Liferea, it supports several views and has a tabbed interface. It's fast and doesn't choke on a large set of feeds. It doesn't offer integration with online newsreaders, but it does import Google Reader's OPML export properly — that is, if you have feeds organized by folders, Akregator recognizes and creates those folders when importing feeds. You can save feeds in Akregator by marking them "important," but it doesn't really give any way to export an entry.
RSSOwl is a multi-platform newsreader based on Eclipse. Unlike Liferea, Blam, and Akregator, it's not packaged with most major distributions — so if you want to give RSSOwl a shot you'll need to get it from the RSSOwl site. The project does offer Linux-specific packages, so it's not hard to install. Since it's based on Eclipse, you'll also need to have a Java Runtime Environment (JRE) to use it.
While RSSOwl doesn't support Google Reader integration, it will import feeds directly from Google Reader without requiring you to export an OPML file. You'll need to provide your username and password, and RSSOwl provides an import wizard that gives the option of importing one, some, or all feeds from Google Reader. It also has a tutorial that runs on startup to walk through all of its features. Overall, it's a very well-polished application. In addition to reading and saving feeds, it supports saved searches — so you can create a special feed that consists of results for a search against one or more feeds. So, for example, you could create a special feed from a search for "Linus" against LWN's RSS feed and check that daily for kernel updates.
RSSOwl also has features to help discover new sources of news that might be of interest. Go to Tools -> "Find new Feeds" and enter a search term. RSSOwl turns up a list of feeds, and their descriptions, that you can opt to subscribe to. The quality of the results vary, of course. A search for "Linux kernel" turned up everything from Greg Kroah-Hartman's blog to some relatively obscure feeds of comments related to posts about Linux on some random Web sites. If Blam is a minimal feed reader, RSSOwl is a maximal reader — very capable, but a bit complex. If you spend a lot of time in the feed reader, it's worth spending the time to learn. The only real complaints I have about RSSOwl are that it doesn't actually sync with Google Reader, and that its sharing features are a bit primitive. When sending to Twitter, for instance, it just opens Twitter and pastes the URL for the original news item in the update form. It'd be nice if it included the post title and shortened the URL.
Finally, it's worth noting that RSSOwl is probably the best documented of all the options — not only does it have extensive help, but it also has a fairly useful tutorial that is displayed on first run that explains its features.
Or you could just turn your Web browser into a newsreader. Firefox, of course, has native support for feeds as "live bookmarks." For users who have a few beloved feeds or a select few that they'd like to keep close tabs on, the live bookmarks are useful. This simply creates a folder of virtual bookmarks that link to entries from an RSS or Atom feed. Firefox simply lists the headline/title for each feed and then opens the source in the browser — so it's not much faster than just going to the site directly.
The Sage extension for Firefox turns Firefox into a full-blown feed reader. Sage has its own stylesheet, so all feeds look alike when using Sage, even though Firefox would be fully capable of displaying the full site. The Sage stylesheet can be modified, though, so users can tweak the output to their liking.
Feeds are displayed as a set of folders in the left-hand side of the Firefox window, much like the Bookmark or History sidebar. Note that only one sidebar can be in use at a time. Overall, Sage is a usable reader and handy for Firefox die-hards who just want to keep track of a few feeds. Sage will handle larger numbers of feeds, of course, but it becomes a bit unwieldy.
The other downside to Sage is that it's not necessarily available for
the latest releases of Firefox. It tracks the stable releases OK, but Sage
is not up to date for the Firefox 4.0 betas. Since I usually track the
latest Firefox betas, it means that Sage is not an option.
Your very own Planet
Another way to go is to create your own Web site from a set of feeds, or
create a "Planet" site for sharing a set of feeds so people can easily
browse all the posts from news feeds specific to a project. This was made
popular with the original Planet
feed reader. It uses Feed Parser
to consume feeds and a templating engine to produce static pages. However, Planet's development seems to have slowed considerably — if not entirely stopped. The last updates in Jeff Waugh's repository are dated early 2007.
Development seems to have carried on, somewhat quietly, with Planet Venus. It's not reflected on the Planet site at all, but digging through the mailing lists one finds development has continued under the name Venus or Planet Venus. Venus is "a radical refactoring of Planet 2.0," and development discussions continue on the old Planet mailing lists.
Another popular, and currently maintained, project is the RSS Aggregator Without Delusions of Grandeur, or rawdog. Like Planet and Venus, rawdog takes feeds and creates a static "river of news" that's suitable for a single user to keep track of her favorite feeds, or for publishing a planet Web site. Planet KDE, for instance, is based on rawdog.
The downside to Planet, Venus, and rawdog, is that they require the user to configure not just the aggregator software, but also to maintain a Web server. For publishing a project planet this is not particularly onerous, but for personal use it's overkill for most users. The planet-type aggregators are also a bit less flexible in terms of adding feeds, and they tend to be sensitive to malformed feeds. Whereas Thunderbird or Newsbeuter might just skip over a feed with errors or unrecognized elements, planet type aggregators tend to choke on malformed feeds and unrecognized elements.
It's safe to say that any Linux user will be able to find at least one feed reader that fits their needs. Even with all the newsreaders mentioned here, this isn't a comprehensive list of newsreader alternatives. Which one is best? That depends almost entirely on the user. Most any of the newsreaders would be adequate for users with a small (less than, say, 50) collection of feeds. But if you spend a fair amount of time skimming feeds for work or pleasure, a couple of newsreaders stand out.
Newsbeuter is the best for those who prefer keyboard-driven, text-based options. It's flexible, fast, and pays dividends for users who are willing to spend the time customizing it to fit their feed-reading habits. For those who prefer GUI apps, RSSOwl is the application with the most features and flexibility. Users who don't want to maintain a separate application for newsfeeds should look at Thunderbird.
It's interesting to note, though, that of all the options available none are really a competitor to Google Reader itself. Though one can find several Web-based aggregators that will build static "river of news"-style pages out of a feed collection, I couldn't find any real Web-based clients that allow feed management via the browser, or the same kind of feed organization (folders) and navigation that Reader offers. The closest option here would probably be Sage, for users who want to handle all their reading via the browser.
That aside, Linux users are not hurting for choice. The crop of newsreaders for Linux is plentiful, you only need to decide how you'd like to manage feeds and then select from several excellent options.
Comments (35 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Default "secrets"; New vulnerabilities in eclipse, evince, gif2png, kernel,...
- Kernel: Linux kernel compatibility for FreeBSD?; The trouble with firmware; Who wrote 2.6.37
- Distributions: Openwall Linux 3.0; Mandriva 2010.2; news from Debian, Fedora, openSUSE, ...
- Development: VirtualBox 4.0; Bombono, Gnucash, KDE, LDTP,...
- Announcements: Crowdfunding; Protecode Joins LF; lots of articles; conf.KDE.in; ...