Mr. Edward Lucas of the Daily Mail in the United Kingdom brings us frightening news of a strong tendency back towards invasive and pervasive government.¹ Looking at the activities of a state sponsored youth group, the author makes comparisons to Hitler’s rise to power and the Hitler youth.

While the bulk of the article focuses on this comparison, the top few paragraphs talk about one of the odder aspects of the youth group. Apparently, the Kremlin is very concerned about Russia’s demographics and, unlike many other European countries, is trying to do something about it. The summer camp features mass weddings and procreation is strongly encouraged, attempting to offset population losses projected to drop by a million a year in the next decade.

They put up a flier advertising their group as “a forum for people of Faith to express their views on the contemporary issues of the day,” operating “with respect for the natural family, marriage and family values.” They said they opposed efforts “to redefine the natural family and marriage,” and noted that California law acknowledged marriage as “the union of a man and a woman.”

And then they got in trouble.

A lesbian co-worker complained to the city that the flier made her feel “targeted” and “excluded.” A supervisor quickly pulled it down for violating city rules against “discrimination,” and announced that the women could only advertise their group’s existence if it removed “verbiage that could be offensive to gay people” — like marriage, natural family, family values and union of a man and a woman.¹

This is not fiction; it is political correctness taken to its logical conclusion. It is political correctness with the full force of law, one that has been held up by the Ninth Circuit Court. While that is the most overturned Circuit court, it is still uncertain if the United States Supreme Court will take the case. So for now at least, the law of the land on the west coast is that it is perfectly legal to deny people any right to participate in the political process, so long as those people are Christians.

For as Mr. Kaufman says, if we cannot talk about our positions, we can hardly expect to achieve anything.

Thanks to Lauren’s patience, I finished Harry Potter tonight. I am well pleased with the series, though I am not at all clear on whose child his whose.

There exists an elementary school that has a “reading time” for its third-grade students, in which they may read a book of their choosing. One child chose to read the Bible, and was told by the school that he may not.¹ Unfortunately, I cannot honestly express surprise that this series of events happened in the United States. Fortunately, the school in question backed down after receiving a letter from the Thomas More Law Center reminding them that such activity has been repeatedly protected by the United States Supreme Court.

“The problem with science is not that the naturalistic approach might occasionally be inadequate. The problem is that science would never know any better. This is science’s blind spot. When problems are encountered, theological naturalism assumes that the correct naturalistic solution has not been found. Non-natural phenomena will be interpreted as natural, regardless of how implausible the story becomes….” – Cornelius G. Hunter, Science’s Blind Spot: Unseen Religion of Scientific Naturalism, Brazos Press, 2007, pg. 44-45

I tried using gnucash the last 3 months, trying to reduce my dependence on commercial software. I am a proponent of open source, so I figured I should be using it where it is available. I really tried. I got used to using expense accounts for categories, even though it means I have to jump through hoops to see how much I have spent in the last month, or in the last year, or this year so far. I actually liked the way it handled my real accounts, credit cards, checking, so on.

I gave up on it though, for two reasons.

1)Its budgeting tools are vastly inferior to Quicken’s. This is actually very important to me. My primary reason for using either program is to create a budget, see how well I am following it, and seeing where that budget has room to give, so that I can get a firmer idea on how much money I have available. I still have not figured out how in the world it is generating its numbers when I tell it to estimate amounts for various categories. Its “budget report” is utterly horrid. It gives you a list of each month, how much is budgeted that month, and how much you have actually spent. If there is a way to get the columns to be colored, so that it is easier to figure out which two columns go to gether, I cannot find it. If you could get the rows colored, so that you can follow a row across the year, that would be even better. As it stands, I have now reached July, and cannot see both the row names and the month’s values in the same screen. This makes it very hard to use. Moreover, it handles each category separately. The developers consider this a feature, because the different categories might be different currencies. Well and good, but when I charge something to Auto:fuel I expect to see that I have less money available for the rest of the month in Auto, not just Auto:fuel, and it is totally bogus that I can budget more in Auto:fuel than exists in all of Auto. Which brings me back to setting up that budget. Once I estimate the values, get some sensible values and some off the wall ones, I try to go through and make sense of it. I have to update all sorts of cells manually, on a per-month basis, keeping track of things like “I just added $10 to Auto:fuel, make sure I add it to Auto also.” The month by month thing is not so bad. It can make havoc of a budget report when your tax return arrives in a different month than last year’s, but that’s fine. It lets me have more fine grained control for things like birthdays and Christmas, and other once a year events like car registration and inspection. But again, I need it to handle more for me, and I would really like it to estimate reliably.

2)It is not stable. This is not so much a problem on linux, though sometimes I have to wait longer for an update on my debian unstable install, but I am primarily using it from OSX right now. And when it starts to crash, and the responce I get from the macports people is “report this upstream, because though clearly an error in the macports library stuff, I do not hit this and maybe some random user who cares enough about gnucash to be on its user list has,” I realize that this product is not ready for normal people. I get a massive amount of mail every day. I do not need or want to be on a “user list” for every program I use. Open source programs should Just Work. While its acceptable to have someone read the man page, or its help file, or even its online docs and FAQ, it is not reasonable to expect them to subscribe to a mailing list because the next upgrade might break all over the place.

When we in pidgin have a broken release, I sometimes get frustrated that people do not even check the most recently submitted 10 bugs to realize there are 5 duplicate tickets already. But I do not blame them for coming and submitting bugs in the first place. This is why we have been known to release updates in very short order when a release breaks for significant numbers of users. A program should at very least still run after the upgrade.

When I submit bugs to debian and redhat, and as I am reading bugs from those distributions and ubuntu, I do not ask those users to submit bugs directly to us. They are going to their distribution’s bug trackers because that is where they obtained pidgin. This is a good thing, because the distribution has a real role to play, making sure that the programs it packages actually work with the other packages they distribute. So when gtk2 does not compile against cairo if I enable quartz, I do not like it when the macports people say “well, upstream changed cairo, and we can’t be bothered to make gtk2 match it until they do, so it will just be broken for a while.” Similarly, when gnucash cannot launch because of an error in the jpeg library, I do not want to have to find and subscribe to the gnucash mailing list because the macports maintainer cannot be bothered to help me figure out what is wrong.

This, I think, is what is wrong with the various source based distributions, be it macports, fink, gentoo, or whatever. They allow so much flexibility on what ends up on the system, that the maintainer has no clue what your system actually looks like, and so no basis from which to help you track down why things break. While debian does not allow you the flexibility to compile vim with our without multibyte support, or gnucash with or without quotes (whatever it means to compile it without quotes), at least when there is a problem, the maintainer knows where to look.

Someone I know from the Pidgin project asked that I install an openid plugin. I am not adverse to the idea, as it should not overly expose me to spam, and so I did some google searching. I found wpopenid on sourceforge, and installed it. It was a pain to get working though, and it is still not working in an ideal state. I cannot figure out how to get it to realize that I have gmp installed on the system. I am not even 100% sure that I do have gmp installed on the system in a way php5 can recognize. Still, I believe it should work.

“If you’re killing mosquitoes to save people from the West Nile virus, you can count on secular environmentalists to lay down in front of the vapor truck, claiming some potential side effect that might result from the spray, but if birth control deforms fish — backed by the proof of an EPA study — and threatens the drinking supply, mum will be the word.” – George Harden¹

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.