Yahoo has eyeballs, and lots of them. MS thinks they have an ad technology that could make them a lot of money, if only they had more eyeballs. Yahoo hasn't been the best at extracting ad revenue from those eyeballs (this is something Google excels at), and MS thinks it can do better.
Which is more valuable to society, a low profit company, or an empty building? A worker paying taxes, or a bum claiming benefits? It depends on what the money that would be paying to occupy the building or paying the salary of the now-unemployed worker is doing now. It's entirely possible that gutting an underperforming company and putting its money and resources in someone else's hands to do different, better work could easily offset the loss of the business and the people who become unemployed. Not saying it definitely would, but you ignore even the possibility.
Depends on your definition of "evil." I'd consider someone devoid of ethics to be evil. Of course, my definition of ethical behavior is just as subjective as the next guy's...
No, he wasn't. He was pointing out that doing good deeds does not automatically undo previous bad deeds. The severity of those bad deeds are irrelevant to the discussion at hand. Any analogy is going to be flawed in some way. Attack the ideas, not the manner in which they're presented (it's hard, sometimes, I admit).
It's become clear to me we're not talking about the same thing. I'll certainly acknowledge that, emotionally and politically, 'ownership' of Taiwan is far from clear-cut, and that mainland Chinese lay claim to Taiwan, and consider the Taiwan/ROC gov't to be illegitimate, just as many Taiwanese generally believe themselves to be independent of the mainland, or even still the sole legitimate gov't of both Taiwan and China.
All of that sucks and makes for a sticky situation, but that's not really what I'm talking about. In *reality*, Taiwan has its own government, and conducts its affairs with almost zero interference from the mainland. Sure, they have to be careful when they talk about international relations (but who doesn't?), but the overall functioning of Taiwan is fully in the hands of Taipei.
By that reasoning, I'd consider Taiwan a "country," regardless of whether or not that makes China happy. Taiwan's lack of recognisance with formal diplomatic relations by a large portion of the world is more a reflection of China's strong-arm tactics (and the West's desire to make China happy) than whether or not Taiwan is autonomous or not.
Anyhow, that's really the only point I was trying to make initially. Sorry if that wasn't clear.
Are you suggesting that stolen property becomes the property of the thief? I think that is entirely up to the owner, personally. It depends on how you define "stolen." One could make the argument that mainland China was "stolen" from the ROC's KMT when they fled to Taiwan. Also note that Taiwan had been a territory of Japan since 1895 (ceded to them by China), before the formation of the ROC in 1912, and *well* before the formation of the PRC. One could say that the ROC actually "stole" Taiwan from Japan, not China! Interestingly, after WWII, Japan released interest in Taiwan as a part of one of the post-surrender treaties, but didn't actually return it to China (instead returning Taiwan to the "people of Taiwan").
Could you find problems with this reasoning? Sure. But you can also find problems with the reasoning that Taiwan was somehow "stolen" from mainland China. So-called "theft" is irrelevant here. You yourself claim that the situation is much more complicated than that, and then try to simplify it down to owner vs. thief. Which is it?
How you define 'country'[1] is not relevant in this part of the world. How do you define Hong Kong, Macau, Tibet (up until recently)? It's westerner's trying to force their own European definitions onto this part of the world that is causing a lot of these problems (IMO). I don't think I buy that. I've spent time in both China (both city and rural) and Taipei. I have close friends who have either spent years in China or were born and raised in Taiwan. Sure, things are different there, culturally, economically, politically. People often have different attitudes and different ways of thinking of things. But to say the concept of a "country" (as we think of it) isn't relevant is just disingenuous. I imagine if, say, the US state of Texas decided to leave the US and be an independent nation, we'd see many of the same issues. Hell, if the US Civil War ended differently, I imagine there'd be much of the same resentment on both sides, with belief that the opposing government was illegitimate. (I occasionally wonder what things would be like if, instead of isolated on a small island, the Taiwanese gov't controlled half of the land of present-day China.)
People just need to get over themselves and realise that one rule and one form of gov't doesn't fit everyone's needs. I realise that can be even more difficult for the Chinese with their manic devotion to the idea of maintaining "face" and allowing your adversary, assuming you're on equal footing and respect them enough, to maintain face as well. But, this whole "One China" crap is just that: crap. At heart, the Chinese gov't only fears that they'll look bad in front of their citizens and the world were Taiwan to gain formal, internationally publicly recognised independence.
It's because China includes Taiwan, no matter who governs it. It's as simple as that. Sorry, but that makes no sense. The defining characteristic of sovereignty is that of government. China is China, and Taiwan is Taiwan, regardless of what the unificationists would like to believe. They have completely separate governments. Just because the PRC claims the ROC as its own (and, amusingly, the ROC also claims mainland China as its own), that doesn't change the facts.
It may not have the practical implications you seem to yearn for, but there is plenty of reasons to consider it true and they are all based on history, and fairly recent history too. The practical implications are all that matter, and the history is irrelevant. The only salient point is that of governmental influence over a particular parcel of land. These days, that's what defines a "country."
For starters, comparing the MacBook Air to basically any other laptop on the market is useless, as there really isn't anything else like it.
Regarding other Apple hardware, I recently was curious and specced a Vaio to as close as possible to a MacBook of the same size, and guess what I found? The Vaio was a little bit more expensive. The HW differences were that the Vaio had an integrated cellular modem and fingerprint scanner, and the extra cost seemed to about match the addition of those features. So you can say an Apple MacBook is equivalent in price to a Sony Vaio with the same specs.
Now, of course, if you take a MacBook Pro and try to spec a Dell XPS laptop similarly, you'll end up with a *much* less expensive Dell laptop. But then I can take the mid-range MacBook, and configure a Dell XPS to the same specs, and you get a Dell that's only $70 cheaper than the Apple. Not really a big difference.
The "problem" with Apple's pricing is that they tend to not sell low-end models. The Mac Mini was really the first departure from this. Their "medium-end" MacBooks and iMacs seem to be decently competitive price-wise with other brands, and their high-end Mac Pro and MacBook Pro models are indeed more expensive than most other similarly-specced laptops out there.
But really, to each their own. Apple still designs some of the nicest hardware out there. I haven't seen a laptop from Sony, Dell, Asus, LG... well, *anyone* that I like aesthetically as much as an Apple laptop. You're free to think that's stupid, just as I'm free to think it's stupid to *not* care about how it looks. If I choose to "throw away" my money for something that looks a little nicer, that's my choice. Otherwise, are you suggesting that the same thing should matter to everyone, and the same things should be irrelevant to everyone?
As an aside, buying last-gen Apple hardware used can often give you a nice price drop, and the hardware is just as good as a new one, albeit slightly slower.
i find it kind of ironic that the samba developers, rather than finding the code, and fixing it, coded a workaround instead. I don't. The Samba guys encountered an incorrect behavior based on user-space code. Who knows how long it would've taken to find the cause of the bug.
And even more important, they would have to code a workaround anyway, to unbreak older BSD systems running Samba.
They don't have to, of course, but it would make the process easier for all concerned. Say:
1. Company provides open source driver dump, which is buggy and not really suitable for end-user use.
2. Community cleans up driver and fixes numerous bugs, and packages the driver for end-users.
3. Community provides patches to fix those bugs to the company, but company ignores the patches.
4. Company releases a new version of the driver dump that fixes some bugs, adds support for new chipsets, adds more features (say, better HW acceleration that wasn't present in the old version), etc. But, the driver is still buggy in many of the old ways, and is still unsuitable for end-user use as-is.
5. Community has to painstakingly go through the new driver code base and merge all the old patches, many of which probably don't apply cleanly (or at all) anymore.
6. New bugs/deficiencies are found and fixed by the community. Company ignores this patch as well, and we're right back at step #3, but with a bigger patch set and more work for the next driver dump.
If the community could be truly independent, this wouldn't matter. After the first code dump, they could maintain their own version of the driver and mostly ignore future upstream releases (aside from cherry-picking useful stuff from time to time). But, without specs, it's very hard to add support for incomplete/missing features and new chipsets, so the community always has to work with the company for these things, which is made harder by the fact that the company doesn't really want to work with the community in a productive manner.
I think the point being made is that VIA has a long history of dragging its feet, going back on its promises to the OSS community, and providing much less than they say they will. Why should this time be any different? I wouldn't be surprised if they just got fed up with it all and are trying to provide enough to the community so they can just wash their hands of it and avoid any further bad PR.
It goes back to the fundamental question of who is your client though. If you are doing your piece of work for yourself, then you are your sole client, and everyone else can simply buzz off. If you are doing this for other people also, then they are as much a client as yourself, and they must be satisfied too. There's a sort of in-between state, too, though. Most of the code I write is because I personally want it. I GPL it (or whatever) because I like sharing, and maybe other people might find it useful. So in that sense it's "for other people," but only in a loose manner. If other people want new features, I'll be happy to code them if 1) I personally think I'd find it useful, or 2) it seems like a fun feature to hack on. I'm very very unlikely to add a feature that I personally don't want and will not enjoy writing the code for. If it's something that I don't think will be a big maintenance burden, I'd probably accept a patch from someone else.
What Pidgin is getting here is a very vocal disagreement, someone slamming the door and doing "their stuff" on their side. I don't think it's a service to the community to be so obnoxious personally. Agreed, totally. I find myself in a weird position of defending the situation as it is, but not wanting to defend the behavior of the Pidgin devs. (After seeing how they behave on IRC and on mailing lists, both in how they treat others and how I've been treated, I have zero interest in defending their behavior.) Some of them are very egotistical and tactless, and treat their users like shit. But their software is popular given its long history (and given the fact that, several years ago, it was really your only choice if you wanted a decent multi-protocol IM client), so everyone more or less puts up with them.
You are forgetting one simple thing, perhaps because you are used to the old days when people who used open source were pretty much all coders of some kind, these days, non-coding open source users are far far more numerous than ones that can code. True, the proportion has changed, but the raw number of people who can code should still be the same (well, should rise, actually). I guess I'll refine that: I'm not saying "for every 100 people who complain about a missing feature, there's only 1 person who writes a patch," I'm just saying "seems like there's only 1 person who writes a patch".
Meaning, the classic "fix it yourself" response might have been acceptable then, but now, it's basically saying, "shut up, loser user." Perhaps in some cases, yeah. But it can also mean "sorry, but your feature/bug isn't important to me right now, and I have other things to do, so if you want it fixed, you'll have to figure it out on your own." It sucks, but that's life. No one's trying to be mean or condescending. There are just a limited number of hours people have free to work on OSS, and you can't expect their priorities to always -- or even often -- align with the non-coding users.
Of course in the open-source world, code contributions are more highly prized than stuff that the average user can do, like testing the software in "real use" conditions, or even submitting a bug report. Sure, and I think that's how it should be. Testing and bug reporting are important, but they don't do all that much to help the developer get work done -- quite the opposite, really: they add work to the developer's plate. A working patch is the best: not only has someone tested and found a problem, but they've gone ahead and fixed it too! It's *incredibly* low-hanging fruit where the developer is concerned when trying to fix a bug.
Then, the goal of a piece of software is usually not to be self-centered but actually to follow what their clients are requiring. [...] If it sparks a minor revolution, I think developers should take notice. That's the thing though -- "requiring" doesn't exist when you're talking about unpaid OSS. The Pidgin developers don't lose revenues if they don't implement a feature their users want. The "minor revolution" of a fork in this case doesn't really hurt the Pidgin developers. In fact, it might end up *helping* them by getting more people involved with the code base (going under the reasonably safe assumption that the fork doesn't diverge to fundamental new directions).
If they have good arguments and if we can't defend ourselves against their arguments, then it means their way wins. ... because if you don't, game designers/programmers use a different engine, you lose money, and go out of business. If the Pidgin devs don't do what their users want, maybe they lose a few users. So what? Maybe they lose 60% of their users. So what? What you're saying makes complete and total sense for a company selling a software product, but doesn't necessarily apply to an OSS project with significant unpaid contributions.
Then, what you are telling me is basically (using inclusive "your", not attacking you, simply referring to the same hypothetical example you just gave) your code has become unmanageable, and adding a trivial function would mean potentially breaking many other things all around it. No, I'm saying that adding preferences don't have *zero* cost. They might have a very small cost -- assuming the code is well-architected and flexible enough to accommodate the requested feature. But that's never the extent of the cost -- testing, bugfixing, etc. can add quite a bit of time and effort, even if implementing the actual feature was trivial.
On the other hand, new features might have a large cost, and that might be because, yes, the code base is a total mess. But it also might be that the developer just didn't envision the need for that particular feature, and the existing architecture/infrastructure just isn't there or isn't easily usable for that particular unforseen use case. I wouldn't call it a design "flaw" per se (though in some cases it may be); it would be foolish to think that any software design can be general enough to be suitable for any possible feature.
If you cannot look at your code and tell it needs refactoring, maybe you got what people refer to as a "God Syndrome". Oh, agreed, definitely. It's just that the cost in refactoring (both in the actual implementation, and the testing and bug-fixing in the refactored version) might be much higher than the benefit you get for adding the feature that prompts the refactoring.
Only in a limited sense. On average, the contribution of any single user is many orders of magnitude lower than the contribution of the developer.
And you're also presupposing that the developer is writing the code and releasing it with the express purpose of gaining a large user base in order to get testing, ideas, and publicity. Many OSS developers write their software mainly because it scratches a personal itch, and release it to the public in the hopes that it will be useful. If it's not, well, sorry, but that's not the developer's problem.
All in all I agree open source developers need to be more open to change and ideas. and be more considerate that people are not attacking their work, but offering ideas and suggestions that their fan base might enjoy. I've been working on OSS, both as a maintainer and on-again off-again contributor, for a good 7 years now. I've seen some great constructive criticism from users that really makes me want to jump on the problem and help them immediately to see if I can change my software for the better based on their suggestions.
Unfortunately, this type of criticism tends to be in the minority. The majority tends to be somewhere in the middle: suggestions that may be perfectly valid, but are poorly thought out and tossed around with little regard for the fact that I've put hundreds of hours of time and effort into the software and have quite a bit of emotional attachment to it. Most of the time in these cases my gut reaction is somewhere between "sure, would be nice, let's file that away for later" and "you're acting like an insensitive dick and I just kinda want to ignore you."
Then there are a few ridiculous flamers who just want to tell you that your work sucks and that you must be some sort of retarded alien to think that your way of writing the software makes sense to any normal user. While it's easy to offer the advice to ignore these people, they can easily take the fun out of writing software and giving it away for free.
We recognize that they are donating their own time, os if they don't have time, then perhaps they could be more receptive to allowing others to join the project and add those requested features The problem is that most people *don't* recognise that we're donating our own time, or they display *very* little respect for that. And in general I do try to accept useful patches that add requested features, if I think the features have merit and the implementation is solid. But I find (in my experience, at least) that very very *very* few people actually put their time where their mouth is and write a patch.
If I build a house for someone and get them to sign a contract stating I have no responsibility as it's actual usability or quality, and then it leaks water from the first day and collapses on the second, I am morally and spiritually responsible, even if the contract or say "license" says I';m not legally. Where's BadAnalogyGuy when you need him...?
No they don't listen to their users. Did you somehow miss the part where I said "Personally I think the Pidgin devs haven't listened enough to their users"?
If you want better support for a protocol the core developers don't really use, you'll either have to a) find someone who does use it and cares enough about it to improve it, or b) pay someone to improve it. But protocol support isn't an issue of listening to users, really. Removing useful features and then ignoring users when they ask why... now that's a problem.
No, but sometimes it's hard to tell where to draw the line. If it's drawn a bit too conservatively, you might end up with a fork. But that doesn't mean that developers should add every requested feature just because a few possible features pissed off enough people that they forked.
These situations tend to resolve themselves, given time. If the fork gains enough popularity, either the Pidgin developers will cave and add the requested features, making the fork unnecessary, or Pidgin itself will become less used. Sure, it's possible that the fork could continue on for a while -- in that case, there's apparently enough interest in both approaches to make the extra time worthwhile. If the fork isn't worthwhile, it'll die, plain and simple.
It is such a small change to add the ability to resize this box; it doesn't hurt anyone, and obviously many people would like to have it. I'm sorry, but very few users actually understand what goes into adding a preference/option to software. It takes time to implement, sure. Sometimes the implementation is relatively easy. But then the option has to be tested -- on a whole, adding a single checkbox option doubles the number of possible configurations the application can have. The option has to be maintained -- code changes in and around what the option affects has to be able to deal with the option being either on or off. And related to that, the option has to be supported: in a perfect world, the option would be implemented correctly and work perfectly the first time, and subsequent code changes would never break it. In the real world, there are bugs, and someone has to answer questions about them when users run into problems. "It doesn't hurt anyone" is false: it hurts any developer or support person who has to deal with code related to it.
And I won't limit this to just users: programmers often fall into this trap as well when talking about other people's software. If you haven't worked on the code base in question yourself, you are not qualified to judge the work required to implement and support an additional option. That's really all there is to it.
These situations have a tendency of self-correcting. If the fork succeeds, then the reasons for the fork had merit, and the fork will either be folded back into mainline (see gcc/egcs), or the 'original' will die and the fork will go on (see xfree86/x.org). If the fork fails, then the fork fails. Some people have wasted their time, but it's their time to waste.
During the initial switch to 2.0, they removed all but the basic settings and said they'll put something back if people scream loudly for it. Yeah, that's quality customer service. Maybe not, but it's smart software development (especially when your time is limited and you aren't getting paid!). Every preference setting has a non-zero cost, both in implementing it (the road to 2.0 involved a lot of re-implementation due to the move to gtk 2.0 and the core/UI split), testing it, supporting it, and maintaining it. Often the implementation is the easy part, and the rest can be a huge time sink. If you can remove a lot of prefs and replace them with good behavior that doesn't need tweaking, that's great. If people still want finer control over some aspects, that's fine too.
Personally I think the Pidgin devs haven't listened enough to their users, but it's really up to them in the end. And if you go and look at Pidgin's prefs dialog, it is indeed still pretty clean -- at least much cleaner than the mess it was in the pre-2.0 days. I have my issues with Pidgin (and its developers), but overall I like 2.x much better than what came before.
Eh, I feel like this is probably more of a "straw that broke the camel's back." The Gaim/Pidgin user community has been on the wrong end of these arbitrary UI changes for years, and it's not surprising to me one bit that eventually people would just get pissed off enough to fork the project.
Long-term, though, I don't think it'll be a particularly viable fork, unless they avoid forking libpurple and actually take development of the GUI in a new, interesting direction. I'd actually like to see that -- it's very hard to use Pidgin on my Linux machines after using something as beautiful as Adium on MacOS X. A new IM client for Linux that uses libpurple as a base would be a great thing.
Slashdot Mirror
Yahoo has eyeballs, and lots of them. MS thinks they have an ad technology that could make them a lot of money, if only they had more eyeballs. Yahoo hasn't been the best at extracting ad revenue from those eyeballs (this is something Google excels at), and MS thinks it can do better.
Says who? (Not that I completely disagree with you...)
Depends on your definition of "evil." I'd consider someone devoid of ethics to be evil. Of course, my definition of ethical behavior is just as subjective as the next guy's...
No, he wasn't. He was pointing out that doing good deeds does not automatically undo previous bad deeds. The severity of those bad deeds are irrelevant to the discussion at hand. Any analogy is going to be flawed in some way. Attack the ideas, not the manner in which they're presented (it's hard, sometimes, I admit).
All of that sucks and makes for a sticky situation, but that's not really what I'm talking about. In *reality*, Taiwan has its own government, and conducts its affairs with almost zero interference from the mainland. Sure, they have to be careful when they talk about international relations (but who doesn't?), but the overall functioning of Taiwan is fully in the hands of Taipei.
By that reasoning, I'd consider Taiwan a "country," regardless of whether or not that makes China happy. Taiwan's lack of recognisance with formal diplomatic relations by a large portion of the world is more a reflection of China's strong-arm tactics (and the West's desire to make China happy) than whether or not Taiwan is autonomous or not.
Anyhow, that's really the only point I was trying to make initially. Sorry if that wasn't clear. Are you suggesting that stolen property becomes the property of the thief? I think that is entirely up to the owner, personally. It depends on how you define "stolen." One could make the argument that mainland China was "stolen" from the ROC's KMT when they fled to Taiwan. Also note that Taiwan had been a territory of Japan since 1895 (ceded to them by China), before the formation of the ROC in 1912, and *well* before the formation of the PRC. One could say that the ROC actually "stole" Taiwan from Japan, not China! Interestingly, after WWII, Japan released interest in Taiwan as a part of one of the post-surrender treaties, but didn't actually return it to China (instead returning Taiwan to the "people of Taiwan").
Could you find problems with this reasoning? Sure. But you can also find problems with the reasoning that Taiwan was somehow "stolen" from mainland China. So-called "theft" is irrelevant here. You yourself claim that the situation is much more complicated than that, and then try to simplify it down to owner vs. thief. Which is it? How you define 'country'[1] is not relevant in this part of the world. How do you define Hong Kong, Macau, Tibet (up until recently)? It's westerner's trying to force their own European definitions onto this part of the world that is causing a lot of these problems (IMO). I don't think I buy that. I've spent time in both China (both city and rural) and Taipei. I have close friends who have either spent years in China or were born and raised in Taiwan. Sure, things are different there, culturally, economically, politically. People often have different attitudes and different ways of thinking of things. But to say the concept of a "country" (as we think of it) isn't relevant is just disingenuous. I imagine if, say, the US state of Texas decided to leave the US and be an independent nation, we'd see many of the same issues. Hell, if the US Civil War ended differently, I imagine there'd be much of the same resentment on both sides, with belief that the opposing government was illegitimate. (I occasionally wonder what things would be like if, instead of isolated on a small island, the Taiwanese gov't controlled half of the land of present-day China.)
People just need to get over themselves and realise that one rule and one form of gov't doesn't fit everyone's needs. I realise that can be even more difficult for the Chinese with their manic devotion to the idea of maintaining "face" and allowing your adversary, assuming you're on equal footing and respect them enough, to maintain face as well. But, this whole "One China" crap is just that: crap. At heart, the Chinese gov't only fears that they'll look bad in front of their citizens and the world were Taiwan to gain formal, internationally publicly recognised independence.
For starters, comparing the MacBook Air to basically any other laptop on the market is useless, as there really isn't anything else like it.
Regarding other Apple hardware, I recently was curious and specced a Vaio to as close as possible to a MacBook of the same size, and guess what I found? The Vaio was a little bit more expensive. The HW differences were that the Vaio had an integrated cellular modem and fingerprint scanner, and the extra cost seemed to about match the addition of those features. So you can say an Apple MacBook is equivalent in price to a Sony Vaio with the same specs.
Now, of course, if you take a MacBook Pro and try to spec a Dell XPS laptop similarly, you'll end up with a *much* less expensive Dell laptop. But then I can take the mid-range MacBook, and configure a Dell XPS to the same specs, and you get a Dell that's only $70 cheaper than the Apple. Not really a big difference.
The "problem" with Apple's pricing is that they tend to not sell low-end models. The Mac Mini was really the first departure from this. Their "medium-end" MacBooks and iMacs seem to be decently competitive price-wise with other brands, and their high-end Mac Pro and MacBook Pro models are indeed more expensive than most other similarly-specced laptops out there.
But really, to each their own. Apple still designs some of the nicest hardware out there. I haven't seen a laptop from Sony, Dell, Asus, LG... well, *anyone* that I like aesthetically as much as an Apple laptop. You're free to think that's stupid, just as I'm free to think it's stupid to *not* care about how it looks. If I choose to "throw away" my money for something that looks a little nicer, that's my choice. Otherwise, are you suggesting that the same thing should matter to everyone, and the same things should be irrelevant to everyone?
As an aside, buying last-gen Apple hardware used can often give you a nice price drop, and the hardware is just as good as a new one, albeit slightly slower.
I've never heard anyone use it conversationally, though. I'm American, and I was just as confused as to what unit if time you were using.
And even more important, they would have to code a workaround anyway, to unbreak older BSD systems running Samba.
They don't have to, of course, but it would make the process easier for all concerned. Say:
1. Company provides open source driver dump, which is buggy and not really suitable for end-user use.
2. Community cleans up driver and fixes numerous bugs, and packages the driver for end-users.
3. Community provides patches to fix those bugs to the company, but company ignores the patches.
4. Company releases a new version of the driver dump that fixes some bugs, adds support for new chipsets, adds more features (say, better HW acceleration that wasn't present in the old version), etc. But, the driver is still buggy in many of the old ways, and is still unsuitable for end-user use as-is.
5. Community has to painstakingly go through the new driver code base and merge all the old patches, many of which probably don't apply cleanly (or at all) anymore.
6. New bugs/deficiencies are found and fixed by the community. Company ignores this patch as well, and we're right back at step #3, but with a bigger patch set and more work for the next driver dump.
If the community could be truly independent, this wouldn't matter. After the first code dump, they could maintain their own version of the driver and mostly ignore future upstream releases (aside from cherry-picking useful stuff from time to time). But, without specs, it's very hard to add support for incomplete/missing features and new chipsets, so the community always has to work with the company for these things, which is made harder by the fact that the company doesn't really want to work with the community in a productive manner.
I think the point being made is that VIA has a long history of dragging its feet, going back on its promises to the OSS community, and providing much less than they say they will. Why should this time be any different? I wouldn't be surprised if they just got fed up with it all and are trying to provide enough to the community so they can just wash their hands of it and avoid any further bad PR.
On the other hand, new features might have a large cost, and that might be because, yes, the code base is a total mess. But it also might be that the developer just didn't envision the need for that particular feature, and the existing architecture/infrastructure just isn't there or isn't easily usable for that particular unforseen use case. I wouldn't call it a design "flaw" per se (though in some cases it may be); it would be foolish to think that any software design can be general enough to be suitable for any possible feature. If you cannot look at your code and tell it needs refactoring, maybe you got what people refer to as a "God Syndrome". Oh, agreed, definitely. It's just that the cost in refactoring (both in the actual implementation, and the testing and bug-fixing in the refactored version) might be much higher than the benefit you get for adding the feature that prompts the refactoring.
Only in a limited sense. On average, the contribution of any single user is many orders of magnitude lower than the contribution of the developer.
And you're also presupposing that the developer is writing the code and releasing it with the express purpose of gaining a large user base in order to get testing, ideas, and publicity. Many OSS developers write their software mainly because it scratches a personal itch, and release it to the public in the hopes that it will be useful. If it's not, well, sorry, but that's not the developer's problem.
Unfortunately, this type of criticism tends to be in the minority. The majority tends to be somewhere in the middle: suggestions that may be perfectly valid, but are poorly thought out and tossed around with little regard for the fact that I've put hundreds of hours of time and effort into the software and have quite a bit of emotional attachment to it. Most of the time in these cases my gut reaction is somewhere between "sure, would be nice, let's file that away for later" and "you're acting like an insensitive dick and I just kinda want to ignore you."
Then there are a few ridiculous flamers who just want to tell you that your work sucks and that you must be some sort of retarded alien to think that your way of writing the software makes sense to any normal user. While it's easy to offer the advice to ignore these people, they can easily take the fun out of writing software and giving it away for free. We recognize that they are donating their own time, os if they don't have time, then perhaps they could be more receptive to allowing others to join the project and add those requested features The problem is that most people *don't* recognise that we're donating our own time, or they display *very* little respect for that. And in general I do try to accept useful patches that add requested features, if I think the features have merit and the implementation is solid. But I find (in my experience, at least) that very very *very* few people actually put their time where their mouth is and write a patch. If I build a house for someone and get them to sign a contract stating I have no responsibility as it's actual usability or quality, and then it leaks water from the first day and collapses on the second, I am morally and spiritually responsible, even if the contract or say "license" says I';m not legally. Where's BadAnalogyGuy when you need him...?
If you want better support for a protocol the core developers don't really use, you'll either have to a) find someone who does use it and cares enough about it to improve it, or b) pay someone to improve it. But protocol support isn't an issue of listening to users, really. Removing useful features and then ignoring users when they ask why... now that's a problem.
Who knows... I tend to ignore /. articles related to OSS that I work on. Raises my blood pressure too much, and it's generally not worth it.
No, but sometimes it's hard to tell where to draw the line. If it's drawn a bit too conservatively, you might end up with a fork. But that doesn't mean that developers should add every requested feature just because a few possible features pissed off enough people that they forked.
These situations tend to resolve themselves, given time. If the fork gains enough popularity, either the Pidgin developers will cave and add the requested features, making the fork unnecessary, or Pidgin itself will become less used. Sure, it's possible that the fork could continue on for a while -- in that case, there's apparently enough interest in both approaches to make the extra time worthwhile. If the fork isn't worthwhile, it'll die, plain and simple.
And I won't limit this to just users: programmers often fall into this trap as well when talking about other people's software. If you haven't worked on the code base in question yourself, you are not qualified to judge the work required to implement and support an additional option. That's really all there is to it.
These situations have a tendency of self-correcting. If the fork succeeds, then the reasons for the fork had merit, and the fork will either be folded back into mainline (see gcc/egcs), or the 'original' will die and the fork will go on (see xfree86/x.org). If the fork fails, then the fork fails. Some people have wasted their time, but it's their time to waste.
Personally I think the Pidgin devs haven't listened enough to their users, but it's really up to them in the end. And if you go and look at Pidgin's prefs dialog, it is indeed still pretty clean -- at least much cleaner than the mess it was in the pre-2.0 days. I have my issues with Pidgin (and its developers), but overall I like 2.x much better than what came before.
Eh, I feel like this is probably more of a "straw that broke the camel's back." The Gaim/Pidgin user community has been on the wrong end of these arbitrary UI changes for years, and it's not surprising to me one bit that eventually people would just get pissed off enough to fork the project.
Long-term, though, I don't think it'll be a particularly viable fork, unless they avoid forking libpurple and actually take development of the GUI in a new, interesting direction. I'd actually like to see that -- it's very hard to use Pidgin on my Linux machines after using something as beautiful as Adium on MacOS X. A new IM client for Linux that uses libpurple as a base would be a great thing.