I recently started working with the Flask microframework for developing web applications in Python. Like a lot of open source software, the documentation isn't always great, but there's an active community. IRC's never been my thing, so when I had questions about Flask, my instinct was to turn to the mailing list. Flask's mailing list is hosted with a site called Librelist. Instead of using an existing, proven mailing list manager like GNU Mailman, Librelist uses its own idiosyncratic software. The trouble starts with the subscription process, where Librelist breaks with a tradition started nearly two decades ago with Majordomo and running all the way to modern software like Mailman and Google Groups: don't send commands (such as to subscribe or unsubscribe) to the list address. Instead, Librelist has you do just that: to subscribe to a Librelist mailing list, you send a message to the list address. Librelist discards the message, and responds with a confirmation message. Repurposing the list address for subscriptions is nonstandard, confusing, and needlessly breaks the habits people have developed from years of working with mailing lists.

Of course, many people get value out of a mailing list not by subscribing to the list, but rather by searching the archives, and discovering that someone's already encountered their issue (and hopefully solved it). But Librelist's archives aren't searchable. Instead, the strategy is to expose the archives as HTML, and let Google (or other Web search engines) index the content. But there are problems with that strategy. The first is that a Web crawler, like Googlebot, just isn't the same thing as a search engine designed for mailing lists—the index isn't updated in real-time to reflect new messages (and, depending on the speed at which Google updates their index, it could be quite some time before new pages appear in Google's index), and you can't narrow your search to text in message subjects, or messages by certain authors, or similar mailing-list-specific filters. The second is a usability problem: telling users who want to search a list's archives to "use Google" isn't very helpful; they'll have to first find the URL for the archives in question, then construct a query with the site: operator to restrict their search to that site, and hope that Google has indexed it recently.

Since there's no way to search the archives, you'll just have to browse through them until you find what you're looking for. The archive index page on the Flask site shows 15 topics per page; the number of topics per page is fixed, and you can only move forward or back one page at a time. At least the archive index page at Librelist shows all of the topics on one page. Both sites use the same interface for the threads themselves, which is a lot more usable with JavaScript disabled. With JavaScript enabled, the archive browser shows one message at a time; there's no button to move to the next message in the thread, nor to show the whole thread on one page (which is what you get with JavaScript disabled).

Finally, I'm skeptical of the premise of Librelist. The notion that "if Librelist.com ever 'goes rogue' then the entire kit can be forked and moved to another server" holds for conventional mailing list software like GNU Mailman, too. And suppose Librelist did 'go rogue' (whatever that means). Someone who sets up their own instance of the software on another server isn't going to have the subscriber lists, and they're not going to own the librelist.com domain. So, list subscribers are still going to have to resubscribe to the list at a new address, just as in any other mailing list migration. And if the goal is just to host mailing lists somewhere other than Google Groups, then there are good software packages for doing that, with sensible, refined user interfaces.

It's also important to discuss the issue of mailing list archives. A number of services exist solely for the purpose of archiving mailing lists, like MARC, Gmane, The Mail Archive, and others. These services are operated independently of the mailing lists themselves, and can be used to archive a list hosted just about anywhere. You can even set them up to archive a mailing list hosted on Google Groups; while I think the paranoid fear of Google Groups is unfounded, setting up external archiving for a Google Groups list provides a good safety net. This isn't so much an issue for Librelist itself, as it is for mailing list managers—if your mailing list doesn't have searchable archives, or if you're concerned about the quality or availability of your archives, then set up archiving for your list with a service like any of those mentioned above.

While there may be very real concerns about the openness of Google Groups and similar services, moving to a half-baked service like Librelist solely because it has the ideological purity of not being operated by Google and making the archives available by rsync even as it lacks basic features like a web interface for managing subscriptions and searchable archives strikes me as a rather poor idea, sacrificing basic usability for ideology. I'm all in favor of transparency, but it seems to me that the goal of a transparent mailing list host could easily be achieved without the idiosyncratic software.