In the last few days, with very little discussion among developers, an implementation of brainstorm was setup on the pidgin.im site. I would like to emphasize that taking this site down is not because we are indifferent to user feedback, nor actively ignoring it. Here, particularly, nothing could be further from the truth.
Our concern is two part. Firstly, the brainstorm site is built on top of drupal, which requires significant resources on the part of the server. We are concerned that under the load we have seen in the past, our servers will be unable to run drupal, and its existence, rather than furthering communication between our users and our developers, will in fact impede it, by bringing our website down entirely.
Secondly, our concern is that, like the forums we used to have on SourceForge, the brainstorm site will become a backwater of sorts, where users submit feedback yes, but also a site where that feedback goes largely unheard.
The brainstorm site, to be useful, will require a very active developer presence. Partly because proposing and voting on features does no good if developers do not see the votes, but for more mundane and fundamental reasons as well.
Already, in the couple days the site is been up, we see some problems. Duplicates here, as in the Trac tickets, are quite common, and quite frequently going unnoticed by the average user. Over time, duplicates like this will mean that the same idea will either have its votes split across so many different items that it will appear, falsely, relatively unpopular, or will be voted up so many times by the same user (once on each instance), that when it is noticed and merged, it will, equally falsely, appear disproportionately popular.
A separate concern of my own is that users seeing the brainstorm site, with its high emphasis on voting, will fail to take head of the note that it does not and will not significantly affect the direction development takes.
Open source developers work best, work at all in many cases, when they are given free reign to work on projects and subprojects that interest them,. If I, or anyone else, tried to tell our developers that they must drop everything and work on the 5 most popular ideas, most of them would quickly find that their free time could be more enjoyably spent on other projects. In an ideal world the ideas that most interest developers would closely mirror the desires of the larger community, but when users fail to step up, develop a trust relationship with others, and join in the development process, reality deviates from the ideal. In such cases, things of great importance to the larger community will languish.
The idea behind this voting system, as I see it, is to answer the question "What can I do to help?". When an idea is highly popular, but not yet being worked on, we as a community, if there is to be a community, and not just a clamoring mob of users, need to realize that help is needed to achieve that goal. A highly voted for idea should thus be seen as an open invitation for a patch, or more realistically, a series of patches, from someone who has never before worked with us, or who, having worked with us some in the past, is looking around for what to tackle next.
For this reason, along with my concerns about resources, I feel it to be very important that a voting system be integrated in with the normal development process. While this might somewhat increase the burden of submitting a new idea, most if not all of the ideas submitted so far reflect tickets already submitted in Trac. However, once an idea is submitted, having the voting integrated in with the development process will ensure that it is, in fact, feedback; that it is seen by those working with the Pidgin, Finch and libpurple code base.