Pidgin devs just don’t get it

Recently Casey Ho emerged from the Pidgin community doing many interesting things trying to gather feedback from the users, but what really got me interested was the new brainstorm based on Ubuntu’s brainstorm.

In a very short time it received hundreds of votes and very good feedback on Casey Ho’s blog. Apparently it was too convenient, and Pidgin devs didn’t like that.

Just like in a totalitarian rule, the brainstorm was quickly shut-down regardless of what users thought. Luke Schierer explained the reasons, which can be narrowed down to: developers whined about yet another place to receive feedback.

So, when users organize that doesn’t help to build a community, but a “clamoring mob of users”. Instead, feedback should be received in the usual way, which is slow, difficult and very restrictive; exactly how Pidgin devs like to work.

It looks like a rational response, except when you think about it for two seconds and ask yourself: what is the difference between a user and a dev? The official blessing of the Pidgin’s junta? X number of blessed patches?

The truth is that in functional open source communities, the line between devs and users is blurry; community members are both devs and users at the same time.

Let’s take an example:

About 4 years ago, voice and video was the most requested feature, but there was no way users could convince developers of that and it was clearly stated by the developers that voice and video would never be implemented, because Pidgin (at that time Gaim) was an instant messaging client, and just that.

However, some users did not accept that and started a friendly fork called gaim-vv which gained some support from the the core developers, but eventually was killed by some decisions by the main developer. Ubuntu Brainstorm made obvious that vv was the most requested feature by far, and eventually a proposal came to Google SoC, that’s how Maiku became a core developer.

It’s quite easy; users vote for features, some features are so relevant that some users decide to implement them, and if they like the development process they keep submitting patches until they are trusted and get commit access. Google SoC facilitates the process for some users.

But Pidgin devs are somehow unable to see that; what users want is irrelevant, only what devs want is relevant; therefore the brainstorm was a bad idea. And they still claim that user feedback is welcome.

I added a track trac ticket to add back the brainstorm section. You can vote there to fight back 😉

BTW. If they are so open to user feedback why all their blogs have comments closed except Casey Ho’s?


The ticket was changed from “Add a brainstorm section” to “Make trac provide various features like Brainstorm”, carrying out the 2 votes it already had, which is like to change “I want a cheetah” to “I want a falcon with features like a cheetah”, no, I want a “brainstorm section”; don’t put words on my mouth.

In a brainstorm, subjects can’t be changed precisely because of this reason, so the first thing to change in trac would be that, which doesn’t really make sense.


34 thoughts on “Pidgin devs just don’t get it

  1. I love how you completely neglected to mention that our current infastructure can NOT support brainstorm.

  2. Gary: that’s a lie, I saw it working, and I even voted for some ideas; therefore it can support it.

    There’s some speculation that your infrastructure won’t be able to support the load, but that’s just speculation.

    I can’t say the reason for removing the brainstorm is because of the load, because there was no reason given, it was just removed.

  3. it’s not a matter of it works with low traffic, it’s a matter of it working under HEAVY traffic if. It’s not speculation, like me an many other devs have said, we’re quite displeased that our new servers are vm’s as well. We are not on dedicated machines, we *ARE* sharing resources, when another node on the box steals resources we suffer, etc etc etc. If you really want to help, get us a REAL server.

  4. I do not respect your opinions, you have a toxic personality and I do not like interacting with you. Everything you do, you go out of your way to make controversy and start flamewars. Please go away. Thanks.

  5. Gary: have you actually experienced heavy load with brainstorm? if you haven’t, then you are speculating.

    speculation: the act or process of reasoning a priori from premises given or assumed.

    Kevin: I don’t care if you like me or not. The truth is that the brainstorm was shut-down without any reason given, I’m entitled to think that it was due to developers’ opposition, due to the discussion in the mailing list.

    If you bother to read the comments on Casey Ho’s posts, and mine, you’ll notice only positive comments from users for the brainstorm, and negative for the shut-down.

    So I just connected the dots: the brainstorm was shut-down due to developers’ opposition despite users liking it.

    I would gladly look for a resources (a real server) for the brainstorm, but that wasn’t even considered as a possibility.

    Have it ever occurred to you that among the hundreds of thousands of users some might be willing to provide a server for that? They are more than a “clamoring mob”, you know?

  6. So you would prefer users could submit feedback somewhere where it is almost guaranteed that it will be ignored, instead of provide feedback where developers might pay attention to it, in the place that users and developers actually are treated like equals, in trac?

    It’s also quite odd for someone that has explicitly walked away from involvement in pidgin development on a number of occasions to be so upset about this.

  7. You know, i was going to reply, but if history has taught me anything, you’ll get over you temper tantrum eventually, and criticize us on something else. At any rate, you are not worth the effort.

  8. Someone: developers and users are not equal in trac. Patches and comments from “users” are ignored quite often. And proof of the inequality is that my proposal was closed as a “won’t fix” without any reason at all. Only developers have the ability to do that, of course.

    Read Casey Ho’s post about shutting down the brainstorm.

    I’m not coming anywhere near Pidgin’s trac again – way too make gtfo-like comments or “give us code then talk” (and then they ignore the code).

    In many of these cases the code is even *right there*, waiting for review and inclusion.

  9. Someone: you are missing the point; users are developers.

    Having hundreds of users voting for a feature might make one of them think; hey, if I develop a patch for that it would surely be accepted and a lot of people would be happy!

    But if developers say: we don’t care how much you like brainstorm, you should use trac, that already is sending a negative message.

  10. Users are not developers, period. Users are contributors. How come the opinions of the developers don’t matter to you Felipe? Are we not users too?

    We also have to deal with the collection of information we obtain, so I think we have a right to make sure it’s coming in in a format we consider useful.

  11. Oh, and the truth is that Brainstorm was shut down with SEVERAL reasons given. You are just choosing to ignore them because it doesn’t fit your point. That is why I don’t like you, because you twist and contort everything we do to make it seem like we hate our users and you are their champion. You are not their champion, you just enjoy flame wars where you can cast yourself as the good guy fighting the evil monolithic Pidgin team.

    I want to protect our users from you.

  12. Kevin: if users = contributors, and contributors != developers, where do developers come from? Do they magically fall down from heaven?

    users -> contributors -> developers

    You can’t deny the fact that future developers are currently pure users. The fact that they go through a temporal stage you choose to call “contributor” is irrelevant.

    I want to narrow down the reasons because I want the thing implemented, you want to broaden them because you don’t want it. I diminished the infraestructure issue because I think the infraestructure is not set in stone. If there’s an issue with the infraestructure, perhaps the infraestructure should be changed.

    Impediments can be overcomed.

    And of course the opinion of developers do matter, but it’s not the only opinion that matters. The brainstorm site was closed without any consideration from the opinion of users. How can you say you take into consideration their opinion, if you aren’t even listened when they are clearly saying they like the brainstorm?

    Throwing ad-hominem attacks is not productive, BTW.

  13. Concerning Drupal and Brainstorm performance, I’d like to share my experience. I’m its author and I’m part of the team managing

    During the launch of Ubuntu Brainstorm, we faced some performance issues, for two days. Why? Because 1/ we didn’t activated Drupal caching and 2/ the launch of Brainstorm was *highly* popular (300,000 votes the first day, slashdotted, digged, wired).
    But after that, we set up the Drupal caching, then a Squid proxy (better than drupal caching), and things calmed down.
    We are now running well on a shared Xen host with a dozen of others virtual machines, at 3,000 votes a day, and dozens of thousands of unique visits/day.
    See for some graph of the evolution of user input quantity.

    I’ll probably comment later the Pidgin decision to shut down their Brainstorm, but that’s rather dissapointing.

  14. to me the issue of brainstorm is irrelevant. yes maybe drupal will hog server resources, we have yet to find out. what gets to me is that even on trac, user feedback is ignored. comments by certain devs are so negative it drives users away. its a far cry from what you see in large projects like ubuntu and firefox.

    apart from trillian, pidgin/gaim used to be the only kid on the block. now with digsby and empathy, i feel pidgin is going to just run itself into the ground. correct me if im wrong but empathy has already replaced pidgin as ubuntu’s default IM program. thats a big loss for pidgin. if you dont change the way you think you are going to get left behind. just read any high school business text.

    casey and felipe are trying to make a difference. a lot of the time devs disregard user feedback because “they have no idea what they are talking about, what they want or how to do it”. but there you are ignoring people like casey and felipe who have put in hard work into pidgin and actually know what they want and how to do it.

    its up to the devs to decide if all the time they put into pidgin was wasted when they find that no one but themselves use it anymore.

  15. In Brainstorm it IS allowed (and encouraged) that the developers enter, comment, and set ideas as CLOSED (won’t fix) .. or as DONE (fixed) whenever they want. I dont believe that brainstorm would be the marvelous solution you are searching for. Moreover, if developers really were like that, they could ignore feedback anyway… no matter if it was in trac, brainstorm or whatever place it was.

    Moreover.. I think that Trac is way more powerful than Brainstorm… for example, votes can be changed. So… if the topic of the idea is changed, then people can change it’s votes also. In Brainstorm, however, you are not able to change your vote in any way….

    This is free software. If there’s so much displeasement with pidgin developers then why not set up a different messenger that does something pidgin doesnt?
    I believe that the real reason why there’s no successful fork is because there’s nobody who can fully take care of this development, not even the developers. If the fork was made, I’m sure that the developers would be pleased to take back the changes to the pidgin trunk anyway, “patches welcome”.

  16. Ferk: I see, I hope in Ubuntu Brainstorm developers don’t close ideas as won’t fix without any discussion with the users, as Pidgin developers do on trac.

    I agree that not being able to change the vote in Brainstorm is annoying, but that’s something I think can be easily changed.

    Changing the subject is not idea IMHO because there will always be people that don’t have time to update their vote to the new subject, and their previous vote is immediately lost.

    I did start a fork, but I can’t possible maintain the whole Pidgin, I only forked the msn protocol. And no, my patches where not welcome, even though msn-pecan is clearly more stable and fast.

  17. Felipe: I understand users become contributors become developers, but trac is where developers work from, so I think it’s much more efficient to get everyone working from the same place. And as I stated in my mailing list email at devel, I think that having two separate places for discussion means that developers and patch writers working from Trac are going to miss out on ideas that could have been seen had they been posted to the ticket they were using to trac their issue. I don’t want to use Brainstorm because I want our feedback to be focused, not SCATTERED so it’s easier to manage and review.

    Your patches were not accepted in Pidgin because they were of questionable quality and often changed a lot of things that were not strictly described in your patch description making them harder to review.

    We encouraged you to make patches, but you were never willing to work with us to provide patches that didn’t require a lot of retooling. You refused to compromise if we didn’t agree a certain thing should be done a way we thought was better, and eventually we had to give up on trying to accept your patches.

    I said many times your dedicated to MSN was something we needed to try to take advantage of, but the people reviewing your patches repeatedly expressed concern that they didn’t see how we could have you be a valuable contributor if you wouldn’t work to make your patches meet the standards we requested.

    Now with your fork you can do whatever you like, and that’s fine. We’re happy to let you list it on our plugins page for those who feel our MSN plugin is unacceptable.

    Praveen: It’s true some ideas will be outright rejected, but, and we’ve said this before, there are some things we don’t want Pidgin to ever be. When this happens, we want users to switch to a client that is more appropriate and provides the features they want or need. We are not trying to sell Pidgin and collect users who would rather use something else, we are trying to satisfy ourselves (as users) and a core set of Pidgin fanatics who are moderately like-minded or enhance Pidgin with features that don’t interfere with the core fan-base of contributors. This means Pidgin is not for everyone and we’ve never said it should be. Casey’s work in some ways is trying to mislead users into making Pidgin out to be something it’s not, which is why we’re especially concerned. We feel MISLEADING users is way worse than telling them what we think.

    Everyone: We as developers don’t want a separate area called Brainstorm where people are posting ideas that are not being reviewed or considered. We want these things to go into trac so we can start filtering and discussing them immediately. A great deal of tickets in trac get marked as patches welcome or plugin suggested which is the very thing that everyone is saying we need Brainstorm to spur.

  18. Kevin:

    Take for example How exactly did I not work with you? It turns after someone (qulogic) took the time to review them they where OK, and applied, months later, after I gave up with the project.

    There are other examples where Richard Laager only criticized the code-style, and they where applied anyway, months later.

    You say “Your patches were not accepted in Pidgin because they were of questionable quality and often changed a lot of things that were not strictly described in your patch description making them harder to review.”

    a) my patches were accepted b) there where no comments on the quality, only code-style c) only changed what was described in the subject

    You didn’t review any of my patches, so I wonder why are you trying to defend the review. Anyway, that’s not relevant here, I don’t see the point of bringing this up.

    You say: “We as developers don’t want a separate area called Brainstorm where people are posting ideas that are not being reviewed or considered.”

    That’s exactly what I’m saying; if developers don’t want something, it doesn’t happen, there isn’t even a discussion with the users.

  19. The more important consideration is that by and large developers did not have a chance to debate this change before it happened, and there are other solutions we would prefer. We are still in charge and it’s important that what we want is being considered if the project is to function.

    We are okay with voting but we largely agree that Brainstorm is not a solution we are comfortable with. And there’s plenty of discussion on the mailing list about this, it’s just after the fact, instead of before, which is backwards.

    Hey, if you really want to run Brainstorm on some other server without our involvement, go ahead and periodically create tickets in trac based on what you see there, but we are not interested in maintaining a site that is expected to be ignored by us.

  20. As far as your patch information, I’m just relaying from what I had been told regarding why so many of your patches were delayed for so long. It’s true that I didn’t review them, MSN is not a component I care about at all and thus not my responsibility.

  21. Kevin: good, so the brainstorm is still open to discussion.

    Regarding the patches, that makes sense. Some toxic developers spread miss-information, and their word of course has more value than mine.

    It would be nice if you add AFAIK before saying the reason my patches where not welcome was because they didn’t meet your standards.

  22. Brainstorm is something we (developers) agree is bad because it creates a “seperate-but-equal” environment for submitting feedback and then we expressly indicate we are going to basically ignore it. I think that’s bad for users.

    I want to have this capability implemented in Trac so that it is part of the same feedback mechanism. Clearly trac will need some playing with to get some of it done, but I’d rather have submissions appear before the eyes of Luke and John as they come in and get directed to the eyes of the “responsible” Pidgin developer, so developers can comment as we go.

    Your MSN experiences and some of the other major closed tickets go before we started the policy of redirecting tickets to “patches needing improvement”, “patches welcome” and “plugin suggested” milestones. I think this, combined with voting on Trac tickets can do all that brainstorm does, but it also makes sure everything is under “one roof” and that developers will see items that belong to their components. There is certainly a need to make sure we are categorizing ideas that we would consider patches or plugins for appropriately in Trac rather than rejecting them.

    It’ll also mean that if a Plugin or patch writer is working on a solution and needs help from developers, he has a chance to find that help in his Trac ticket, and ideas from users and developers can be fed to him as he goes.

    Brainstorm is, based on the stated goals from Casey and the general arguments I’ve seen for the proponents of it, a plan to separate users from being able to be developers and contributors until they are directed separately to Trac, which is why I would really prefer this all be integrated into Trac.

    I closed your ticket wontfix because it does not fit into any of the “patches welcome” or “plugin suggested” categories as a web site change and because I think the Brainstorm ship has sailed. But we learned from Brainstorm that people like voting on things, so let’s focus on bringing the changes to Trac and try to find ways to produce some of the reports it can make. Perhaps as we work on those reports, we’ll make sure they ignore the “status” of tickets so that even though I closed your ticket, it’ll still show up and be able to be voted on. It’s not like a ticket we close goes away forever, and everyone involved still hears about it when you comment on it.

    I don’t think you’re going to get Brainstorm back, but we are not closing the door on the type of thing it could offer to the project.

    I believe there’s some talk already amongst the developers to begin playing with our test install of Trac to find out how to do this best.

  23. That’s a lot of words that explain why you don’t want a brainstorm, but that doesn’t change the fact that in this particular issue, you didn’t care about what users thought.

    Brainstorm will not happen, because developers don’t like it, period.

  24. The developers are the ones who have to deal with it. We should get some say in how we receive feedback, shouldn’t we?

    And you’re changing my answer in a simplistic inaccurate way.

    Yes, we care what users thought. We acknowledge that Brainstorm was of interest to users, but we don’t like Brainstorm, so we’re looking to compromise.

    Just because you don’t want to compromise, as you never do, doesn’t mean that other users won’t see the value in it… and our compromise will help ensure that developers are paying attention to the “brainstorms” that we get instead of ignoring them.

  25. Without diving into the whole debate too much, I’ll say this:

    A good developer should be able to have sympathy for users, but a good developer also shouldn’t follow every single suggestion.

  26. Kevin: You are not being empathic. It’s easy to say: we are listening to users, that’s why we add brainstorm features into trac. Is that what users want, is that what you assume they want, or is that the best they are ever gonna get?

    It’s like an invading country saying the invaded country don’t want to compromise; we understand you don’t want to be invaded, that’s why we are taking only half of your country; you should be happy we are not invading the whole country!

    It’s not about what you think users want, it’s about having a dialog. It doesn’t matter what you do in the name of “listening to users”, the fact is that you are not having a dialog. It’s that simple.

  27. Pingback: Flaming Birds at Counting Beans

  28. “It’s like an invading country saying the invaded country don’t want to compromise;”

    You are way off here, Felipe. The metaphor is totally screwed. Nobody forces you to use Pidgin. If you don’t like the way the developers do it, fine, stop using it. They don’t invade you.

    You know, with the visible “success” of tries to fork pidgin (funpidgin anyone?), it looks to me more like it is only a vocal minority who constantly disagrees with the way the project is run.

    I’d rather submit bugs or requests to trac than to put them in a system nobody of interest looks at.

  29. jmt: there are not perfect metaphors.

    The point is that the decision was taken by developers arguing “listening to users” but users never had a single word in that decision, and now I’m the bad guy because “I don’t want to compromise”.

    I just want developers to have a dialogue with the users.

    And no, I would argue that it’s the majority of users-possible-developers that disagrees with the “official” development team. It’s just that efforts to fork the coded have been badly organized in the past.

  30. jmt: oh, and when someone invades your country nobody forces you to stay either, if you don’t like it you can move to another country 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s