on forks and forking
Posted by Luke Schierer under Pidgin | Permalink | | Leave A Comment
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.
6 Responses to “on forks and forking”
Leave a Reply
You must be logged in to post a comment.
I’m a tad confused, does “advertising a fork” mean they were asking other to fork it or were they saying, “we’ve forked it, join us url:here”?
If the latter, I’d be interested to know the URL (though I’m one of those who agrees with the protocol icon decision) . . .
BTW: the OpenID login box in your blog is black text on black
I’ll have to look into the OpenID stuff more.
They were calling for one, not actually posting any work or any url.
“That previous attempts have failed I attribute to the overall correctness of our own vision of the needs of the community so far.”
I randomly browsed over here from Google Talk’s website and then XMPP. I have to say that your statement above is rather bold, and illogical at best. The time, effort, and community building required to produce a successful open source project, while initially related to “correctness”, once established, no longer are tied to being “correct”. Pidgen is a perfect example. Since you have established the project, you no longer must do what is “correct”, and are free to fragment your community instead of finding a compromise. As you have noted though, community fragmentation is generally undesirable and hinders progress when it causes a project to lose critical mass.
You make an assumption that is not true: that in the past we looked for compromises to build community rather than doing what we felt to be correct. This has never been the case. It was not the case when we insisted that initial file transfer work must come in the form of patches. It was not the case when we decided (against much the same outcry you see now) that it was time to ditch gtk1.2. It was not the case with any of the other decisions we made around that time, such as removing the “edit buddy list” pane in favor of in-place editing, also a highly controversial change. Nor did we look for compromise when we introduced wysiwyg editing for IM, again a highly controversial move.
We have never let outcry or fears of fragmenting the user base stop us from doing the correct thing. My argument is that this disregard of consequences has not harmed us becuase we have in fact been correct. If previous instances of outcry have not proved to be fatal, I see no reason to believe this one will. Yes, there is always the chance that this time we are wrong, but that has always been the case.
“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”
Why proposing a fork when there are alternative open-source projects that already offer this feature? Instead of suggesting these people to create a fork it would be much better for the open-source world to send these complaining people to these projects. It is much easier to join an existing mature open-source project than to create a fork. If they create a fork, the failure rates will be much higher than if they join an existing open-source project. So, if you point these people to other open-source projects, the chances that they waste their “contributor resources” will be much lower.
As you first need to know some of these alternative projects in order to guide people to the right projects, I give you 2 projects that have this feature (in both clients this feature is configurable): * Psi: http://psi-im.org * Coccinella: http://coccinella.im/
(Note: I’m pretty sure there are more instant messaging clients with this feature, but these are the only 2 I know.)
I’ve not commented on the protocol icons yet, but I have stayed with GAIM and not upgraded to Pidgin because I do find a use for them.
The different protocols do not all work the same, at least as far as offline messaging. I need to know which of my contacts are on which protocol so I know what they are dealing with and why messages are sent in a particular way.
A simple color-coded system doesn’t work too well for me. This was the case when I still used Trillian. The way protocol icons were usually handled there was through a user-submitted skin.
“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…”
I’m a husband and father of 2. Being disabled, I do have some time on my hands, but I’m just struggling with simple HTML as it is!
“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.”
Please see what I said before. It’s been something that has consistently been convenient and useful for me. I’m not really sure what you’re trying to say.
I looked over Psi and Coccinella and had difficulty finding where it said protocol icons were supported.
Anyway, I’ve no problem trying to help create a plugin for protocol icons if that’s a viable solution, but see, not everyone using open source programs is ready to be a programmer. I’m sorry to hear that people have been childish, impatient, and rude in their demands to have them back– I hope I have stated my preferences intelligently and maturely.