Last night someone saw fit to spam our ticketing system with a comment appended to one ticket, and a new ticket submission with text identical to the preceding comment. These posts are fairly typical of the requests we see for the return of protocol icons, demonstrating the childishness of the requesters, and the typical unwillingness to consider anything beyond their own use case.
That being said, the post itself was not entirely out of line. I dislike someone advertising for a fork in our trackers, and so fully support rekkanoryo in promptly closing the ticket. The trackers, to be at all useful, must have a steady turn-around time. For this reason, Sean agreed with me to attempt a pair of bug closing releases to follow the current cycle. Leaving requests open for an indefinite period of time because someone might want to work on that request someday simply does not work. We tried that in the Source Forge feature request tracker, and watched as that tracker ballooned to a size that defied any attempt at organization or management. This means that a fork, by its very nature something we are not going to work on, must be removed from the tracker.
Still, forks and forking play an very significant role in open source. Though they can lead to confusion and fragmentation of the user base and developer pool, they can also allow for groups of developers who have real and significantly differing ideas on where a project should go to both achieve their desired ends. This is good. The primary freedom of open source is not the freedom from cost, but the freedom to shape software to do what you want. This freedom is never exercised without cost, but is available at all only by accepting the very different costs associated with open source, costs not in money, but in time and effort.
It is because my co-developers and I pay that time and effort that Pidgin is available to anyone, and it is because we have paid for it that we get the deciding say in where it will go. We are part of a community, but in any community rights and responsibilities are split, and in any successful community, rights are balanced by responsibilities. We owe the community regular releases, our best effort at fixing bugs, and an up-front openness about our goals and our limitations. The community owes us respect for the time and effort we put into the project. If we saw that respect, if people accepted that we might just know a little bit more about our own user base than they do, they would stand a much better chance at convincing us of the need for a given change. I am not asking that users grovel, just that they stop calling us idiots, and stop assuming that their own use case is necessarily the most common one.
At the end of the day, we will not, cannot, please all of our users. The changes we have made, controversial though they are, are not made in a vacuum. Many of them have been requested for years. In a few cases, they are changes that we were only gradually brought to believe were the correct course after years of requests and days if not weeks or in some cases months of debate and experimentation. It is in recognition of this reality that I return to my original topic, that forks play an important role in open source.
This idea is not a new one to this project. Several times in its history different groups have felt such strong disagreement with a decision that we (or our predecessors) have made that they have forked Pidgin (then Gaim) to meet their own needs. Though to date none of these efforts have survived for long, the possibility always remains that we have made a significant mistake, and some future fork will prove a success. This is the nature of open source, and I wish anyone attempting to take on the work of a successful open source project the best of luck. That previous attempts have failed I attribute to the overall correctness of our own vision of the needs of the community so far. Despite high initial energy levels, so far forks such as gaim-claws or opengaim have failed to create any momentum of their own, failed to prove worth the effort involved. In short, they have proved that there was in fact no need for the changes they proposed.
Today, a very small, but incredibly vocal group of users are attempting to insist that protocol icons in the buddy list are crucial. They do so for a variety of reasons, and their logic, where it even exists, often breaks down. The use of protocol icons to distinguish buddies across accounts is a very flawed system, necessarily subject to a relatively high degree of error, and substantially limited. One person inadvertently disproved their own attempted justification by attempting to say that you could use them to distinguish between buddies on the same protocol! Others are concerned that our current file transfer support differs in success rates across the various protocols, or that things like Direct IM are available only on one protocol. This argument too breaks down, with the realization that we are actively attempting to make this transparent for the user, with improved file transfer support, and improved buddy selection support.
Others have failed to fully take advantage of Pidgin's capabilities, and once they realize the power of the "contacts" pidgin supports, realize that most if not all of their desire for protocol icons is removed.
That being said, if this is in fact the first truly wrong call we have made, then it stands to reason that a fork would not only be appropriate, but would succeed. This is particularly true because with 2.0.0, and continuing with each release since, the core/ui split is complete, and libpurple is a reality.
Though many users have criticized us for spending time on this architectural change that has no immediate benefit to the user base, it was precisely our users who we had in mind as we pushed to complete it. Earlier I stated that one of the responsibilities of the developers of a given project is to openly admit their own limitations. We are limited. We are limited in the amount of time we can devote to the project, and we are limited in our ability to design an interface that is equally ideal for all subsets of our highly diverse user base. Though I believe this later limitation to be an unavoidable one, it is no less real. Given that Pidgin will never be the best interface for all users, it becomes critical that the vast amount of time and effort spent in figuring out and implementing support for AIM, Yahoo, MSN and other closed protocols not be wasted. Libpurple achieves that goal.
Users claim that they want the protocol icons. I call on them to put their money where their mouth is, by spending the time and effort necessary to become an open source programmer, and to create a libpurple based client that will blow Pidgin and Finch away, and raise the bar for a high quality instant messaging client ever higher. Many of us now involved in Pidgin and Finch started out with little or no programming experience, learning as we went from the existing code, from online tutorials, from text books we have purchased, and from our own mistakes. Nothing stops anyone else from doing the same thing, except, perhaps, the fact that just maybe there really is not any real demand or need for the changes so vocally being demanded.