I don't think the general public can distinguish between "stable" or "experimental" or "beta". From the point of view of most of them, if they can get it, it's ready.
There's nothing about free software that says developers need to expose every thing they do to random strangers. If they do, they ought to expect a great deal of misunderstanding and complaining because expectations that users are "educated" about software development are sure to be disabused.
Note that I am not, and haven't, suggested locking up development. I am, though, saying that testing ought to be in a controlled environment until the thing stands a better than even chance of not breaking. Sure, release early and often, yada, yada, yada. But, no one is keeping score on Obedience to Unexamined Truths, so don't release crap you know doesn't work just in the hopes that strangers will take the time to detail the specifics for you. If you do release crap, be prepared to take the repetitional hit.
No, it doesn't. Nothing is stopping KDE, or any other effort, from establishing a group, or groups, of testers and organizing a coherent, disciplined approach to testing. The source is open, yes. But, there is no requirement to put the source on public servers if you don't want it there.
In my experience, software testing is better done when you know the skills and backgrounds of the people doing the testing and can ask/direct them to test specific areas. E.g., if you already know X causes Y, you don't need people telling you Y is broken. You'd rather have competent testers exercising X.
Keep it "in house" until you have something good enough to be labeled a beta, in the legitimate sense that it used to mean.
Get your feedback and testing from a closed group.
I'm even reluctant to suggest releasing a beta, since so many people today seem ignorant of the purpose of a beta. Every time someone releases one people start to complain that it's "broken".
I suspect the ability for users to disable secure boot makes a legal challenge to this moot. At best, MS might be compelled to make secure boot opt in. I.e., compel users to enter firmware to enable it.
And I expect it to be a sales boon for Apple. People annoyed by this will go to the mall and buy Apple. They won't go home and try to install Linux.
No. Motherboard makers face the same requirement. And, as I understand it, this requirement does not apply to server hardware.
Whatever you think of MS and Red Hat, this is a problem tht every Linux distribution needs to address. Rhetoric about freedom and urging lawsuits won't change anything.
Users will be able to go into firmware and disable secure boot, but I don't think many will do that just to try Linux. They are much more likely to just go buy a Mac. Especially if there are initial problems when this is rolled out.
Folks who dual boot Linux and Windows could be really screwed because an unsigned bootloader will be seen by Windows as malware, with an MS update eventually coming down to disable it.
The Evening Standard is fine if your idea of news is is mostly celebrities and sports. If people didn't grab it to read on the train going home after work, they'd likely go under.
Buffett's right, of course. No business can survive without making a profit. I am skeptical, however, that local news is going to save the day. Why? Because people are not as interested as they say they are in local news. My local daily paper publishes a weekly section targeting my suburb. I don't see much news in it, but I do see a lot stories about clubs, schools, kids, and churches, I once had the chance to ask the editor why they went with that rather than hard news about town government, politics, etc. The answer: We print the stories that sell newspapers. The local news market is not a hard news market. It's a feel-good gossip market.
When a newspaper shrinks and fires newsroom staff, news production in that market drops and is not replaced by online sources. We are all more ignorant as the result, and it's an ignorance that's spreading.
I ran three versions of OS/2 on non-IBM hardware without tweaking any config files. Initial versions of the OS were tied too tightly to IBM hardware, but releases 3 and 4 ran on a wide variety of platforms.
Popularity over many years is a good criterion, but not, I think, the only one. For example, most of Agatha Christie's mysteries are more than 50 years old. While many of them are considered classics of their genre, few would consider them classic literature. Ditto the Holmes stories: Compelling reading for many for a century or more, but neither Conan Doyle or Christie demonstrate the technique or deal with the range of ideas or emotions I'd consider necessary to elevate a novel into "classic" status.
For example, I'd nominate Chimamanda Ngozi Adichie's "Half of a Yellow Sun" as a classic, even though lt was first published in 2006.
Besides, I knew that and bought cards with the allegedly correct chipsets.
But, the larger point is that two popular Linux distributions made false compatibility claims. I doubt it was deliberate. Most likely, someone tested one card with a chipset and issued a verdict that all cards with that chipset were compatible.
Just another example of how Linux often expects people to change their behavior in order to use the OS, rather than the other way around.
That's a common sentiment. But, why is it so unfortunate? What does a typical computer user gain from detailed technical knowledge? For most, that amounts to be able to work around the shortcomings of the OS. E.g., if a new peripheral doesn't work as advertised when plugged in, maybe they can do something about it.
I used Linux -- mostly Slackware --consistently for ten years on my desktop and as a server. A few years ago I switched to Apple after I ran through 3 wireless cards all touted -- by Ubuntu and/or Slackware -- as compatible. Now, I haven't written a script or pulled out vi in a long time, but I haven't completely forgotten everything I learned in those 10 years with Linux. But, and it's an important exception, I don't need that knowledge to successfully and happily use my Mac. That knowledge doesn't benefit me.
An OS that carries with it an expectation of shaky hardware support and a need for a steep user learning curve will always be confined to a tiny niche of the market. It's my impression that Ubuntu is aiming for more than that, that it very much wants "real world" users who don't, and won't, have any technical expertise.
Common knowledge only among a certain segment of Linux fans, not among the general public where Ubuntu ought to be focusing its efforts. When was the last time Ubuntu ran some ads targetting the folks at Bet Buy and Walmart?
Few members of the general public have any interest at all in Ubuntu's philosophy, no more interest than in their philosophy of the company that made their toaster. Virtuous thoughts do not compensate for software shortcomings, real or perceived.
And, sure, people ought to spend some time researching an OS, but that isn't going to happen. People don't understand tech specs or language about technical capabilities. They want an OS that runs the software and hardware they already own, looks better than their current OS, is subjectively fast, and doesn't crash.
>> I think you overstate the (mostly unfair IMO) perception that open source developers are unhelpful...
Yes, that could be seen as an overstatement if seen as encompassing all developers, which I certainly didn't intend to. I'm thinking primarily of forums, etc., where those kind of responses could easily come from non-coders who may or may not have any relationship to the project. Because they are on a site devoted to the project, however, someone from outside that community has no way of knowing.
>> I don't think it's hostile for an open source developer to tell you he isn't interested; after all, that's the only reason he's coding anything in the first place.
Of course not. But, someone who is unfamiliar with the customs of open source may easily assume that the developer is paid to code. It's a question of mis-matched expectations. Of course, some people are just overly demanding.
>> In open source software, the transaction changes.
I agree. But I think that effectively limits the market for open source to people who see the transaction from the developer's point of view. That's a rather small pool of people.
As you seem to have learned, most people see themselves as customers, not members of a community who take on an obligation to contribute something.
By defining people who use open source as, more or less, participants, open source circumscribes its acceptance. That's a valid approach, if all the implications are understood.
>> A user of a given piece of open source software is not a customer. They don't become a customer until money exchanges hands. This is why you see a lot of a "our users are beta testers" mindset with open-source software...
While I disagree with that. I think your approach to customer support is rational for an open source developer.
That said, I think open source would do well to treat every user as a customer, rather than as a user, which typically seems to be defined as a willing member of community. That's a legitimate view, but it assumes the user knows the rules of the game. It narrows the base of open software to people who know about or are interested in advancing the goals of that community.
1. Firefox does pay attention to interface and usability. (That encompasses more than the "gui".) They have the financial backing to do that. Presumably, GIMP does not. My point is twofold: First, Photoshop has a reputation for being hard to use, yet it's primary open source competitor is harder to use. Perhaps if the GIMP folks had the financial backing of Firefox, they'd improve the product. But, all that is irrelevant to a customer looking for software. The only thing that counts is what is displayed on screen. Are users supposed to be so enamored of the open source model that they overlook defects in its products?
2. I have to challenge your assertion that a typical open source project has "lots of coders".
3. You've missed the point on innovation. I'm not criticizing forks, per se. I'm arguing that forking an existing product does not really represent innovation. It represents a variation, perhaps an improvement, on an existing product.
4. And you missed the point on attitude to customers. Developers file bug reports, not customers. Setting up a bug tracking site is not providing adequate customer service. Effectively telling users to "go away" is not customer service. Customers want help getting something to work. More often than not, their problem is not caused by a bug. Asking "Can I/How do I do 'X' with this?" is not a bug report. BTW, Bank of America changed its web site based on a suggestion I made.
5. "Gets the job done" is fundamental but far from being enough to sell a product. Otherwise, the world would still be running Word Perfect 5.1 on 640k DOS machines.
Your reaction to my post highlights the primary reason open source fails to make substantial headway in the market. Rather than accept my comments at face value in a "the customer is always right" frame of mind, you choose to challenge me instead. It's really rather difficult to persuade someone to use your product when you keep telling him he's the problem.
Being free, in cost or in development model, is of little interest to me when I chooise software. I want the best software I can afford, and I can afford more than no cost.
Here's a short list:
1. Lack of attention to interface and usability design. This is not "eye candy". Consider: People think Photoshop is easier to use than Gimp. What does that tell you? (Responses that trash Photoshop users illustrate the problem.)
2. I get the impression that, apart from the corporate funded biggies, many open source projects are staffed by one or two people. That's not confidence-insipiring when I'm looking for software to use for years in the future.
3. Rushed updates often made to conform to an established schedule. If an update needs more time, don't release it.
4. Lack of innovation. Software innovation is really, really hard and no one does it well. However, open source software, more or less by intent, produces many slightly varied iterations of the same code. I.e., forks.
5. Hostile attitude to customers: One of the touted benefits of open source software is access online to developers and other cognoscenti for tech support. Although I suspect it happens with less frequency these days, too many open source users are met with hostile "code it yourself" or "I'm not interested in that..." responses when they ask for help with a problem. Online support forums should not run bugtracking software.That's a developer-only tool.
Slashdot Mirror
I don't think the general public can distinguish between "stable" or "experimental" or "beta". From the point of view of most of them, if they can get it, it's ready.
There's nothing about free software that says developers need to expose every thing they do to random strangers. If they do, they ought to expect a great deal of misunderstanding and complaining because expectations that users are "educated" about software development are sure to be disabused.
Note that I am not, and haven't, suggested locking up development. I am, though, saying that testing ought to be in a controlled environment until the thing stands a better than even chance of not breaking. Sure, release early and often, yada, yada, yada. But, no one is keeping score on Obedience to Unexamined Truths, so don't release crap you know doesn't work just in the hopes that strangers will take the time to detail the specifics for you. If you do release crap, be prepared to take the repetitional hit.
No, it doesn't. Nothing is stopping KDE, or any other effort, from establishing a group, or groups, of testers and organizing a coherent, disciplined approach to testing. The source is open, yes. But, there is no requirement to put the source on public servers if you don't want it there.
In my experience, software testing is better done when you know the skills and backgrounds of the people doing the testing and can ask/direct them to test specific areas. E.g., if you already know X causes Y, you don't need people telling you Y is broken. You'd rather have competent testers exercising X.
Keep it "in house" until you have something good enough to be labeled a beta, in the legitimate sense that it used to mean.
Get your feedback and testing from a closed group.
I'm even reluctant to suggest releasing a beta, since so many people today seem ignorant of the purpose of a beta. Every time someone releases one people start to complain that it's "broken".
The solution to releasing software that isn't ready for people to use is not to release it.
I suspect the ability for users to disable secure boot makes a legal challenge to this moot. At best, MS might be compelled to make secure boot opt in. I.e., compel users to enter firmware to enable it.
And I expect it to be a sales boon for Apple. People annoyed by this will go to the mall and buy Apple. They won't go home and try to install Linux.
No. Motherboard makers face the same requirement. And, as I understand it, this requirement does not apply to server hardware.
Whatever you think of MS and Red Hat, this is a problem tht every Linux distribution needs to address. Rhetoric about freedom and urging lawsuits won't change anything.
Users will be able to go into firmware and disable secure boot, but I don't think many will do that just to try Linux. They are much more likely to just go buy a Mac. Especially if there are initial problems when this is rolled out.
Folks who dual boot Linux and Windows could be really screwed because an unsigned bootloader will be seen by Windows as malware, with an MS update eventually coming down to disable it.
...when so many people are happy to do it for free.
The Evening Standard is fine if your idea of news is is mostly celebrities and sports. If people didn't grab it to read on the train going home after work, they'd likely go under.
Buffett's right, of course. No business can survive without making a profit. I am skeptical, however, that local news is going to save the day. Why? Because people are not as interested as they say they are in local news. My local daily paper publishes a weekly section targeting my suburb. I don't see much news in it, but I do see a lot stories about clubs, schools, kids, and churches, I once had the chance to ask the editor why they went with that rather than hard news about town government, politics, etc. The answer: We print the stories that sell newspapers. The local news market is not a hard news market. It's a feel-good gossip market.
When a newspaper shrinks and fires newsroom staff, news production in that market drops and is not replaced by online sources. We are all more ignorant as the result, and it's an ignorance that's spreading.
No one wants quirky and risky software anymore than they want quirky and risky airplanes. Software is not playtime for developers.
Pretty sure the little Kindle manual tells you that your notes and highlights are archived on Amazon's servers.
At least, mine did.
If you are paranoid about this, don't make highlights or notes. Not that most of you do, anyway.
I ran three versions of OS/2 on non-IBM hardware without tweaking any config files. Initial versions of the OS were tied too tightly to IBM hardware, but releases 3 and 4 ran on a wide variety of platforms.
Popularity over many years is a good criterion, but not, I think, the only one. For example, most of Agatha Christie's mysteries are more than 50 years old. While many of them are considered classics of their genre, few would consider them classic literature. Ditto the Holmes stories: Compelling reading for many for a century or more, but neither Conan Doyle or Christie demonstrate the technique or deal with the range of ideas or emotions I'd consider necessary to elevate a novel into "classic" status.
For example, I'd nominate Chimamanda Ngozi Adichie's "Half of a Yellow Sun" as a classic, even though lt was first published in 2006.
Hmmm...
That's just a rewording of the problem.
Besides, I knew that and bought cards with the allegedly correct chipsets.
But, the larger point is that two popular Linux distributions made false compatibility claims. I doubt it was deliberate. Most likely, someone tested one card with a chipset and issued a verdict that all cards with that chipset were compatible.
Just another example of how Linux often expects people to change their behavior in order to use the OS, rather than the other way around.
>>"That's an unfortunate truth."
That's a common sentiment. But, why is it so unfortunate? What does a typical computer user gain from detailed technical knowledge? For most, that amounts to be able to work around the shortcomings of the OS. E.g., if a new peripheral doesn't work as advertised when plugged in, maybe they can do something about it.
I used Linux -- mostly Slackware --consistently for ten years on my desktop and as a server. A few years ago I switched to Apple after I ran through 3 wireless cards all touted -- by Ubuntu and/or Slackware -- as compatible. Now, I haven't written a script or pulled out vi in a long time, but I haven't completely forgotten everything I learned in those 10 years with Linux. But, and it's an important exception, I don't need that knowledge to successfully and happily use my Mac. That knowledge doesn't benefit me.
An OS that carries with it an expectation of shaky hardware support and a need for a steep user learning curve will always be confined to a tiny niche of the market. It's my impression that Ubuntu is aiming for more than that, that it very much wants "real world" users who don't, and won't, have any technical expertise.
Common knowledge only among a certain segment of Linux fans, not among the general public where Ubuntu ought to be focusing its efforts. When was the last time Ubuntu ran some ads targetting the folks at Bet Buy and Walmart?
Few members of the general public have any interest at all in Ubuntu's philosophy, no more interest than in their philosophy of the company that made their toaster. Virtuous thoughts do not compensate for software shortcomings, real or perceived.
And, sure, people ought to spend some time researching an OS, but that isn't going to happen. People don't understand tech specs or language about technical capabilities. They want an OS that runs the software and hardware they already own, looks better than their current OS, is subjectively fast, and doesn't crash.
So... Linux is not ready for the real world?
>>". Canonical is also interrested in stable, long term release versions, called LTS."
And why should anyone in the real world know this?
>> I think you overstate the (mostly unfair IMO) perception that open source developers are unhelpful...
Yes, that could be seen as an overstatement if seen as encompassing all developers, which I certainly didn't intend to. I'm thinking primarily of forums, etc., where those kind of responses could easily come from non-coders who may or may not have any relationship to the project. Because they are on a site devoted to the project, however, someone from outside that community has no way of knowing.
>> I don't think it's hostile for an open source developer to tell you he isn't interested; after all, that's the only reason he's coding anything in the first place.
Of course not. But, someone who is unfamiliar with the customs of open source may easily assume that the developer is paid to code. It's a question of mis-matched expectations. Of course, some people are just overly demanding.
>> In open source software, the transaction changes.
I agree. But I think that effectively limits the market for open source to people who see the transaction from the developer's point of view. That's a rather small pool of people.
As you seem to have learned, most people see themselves as customers, not members of a community who take on an obligation to contribute something.
By defining people who use open source as, more or less, participants, open source circumscribes its acceptance. That's a valid approach, if all the implications are understood.
>> A user of a given piece of open source software is not a customer. They don't become a customer until money exchanges hands. This is why you see a lot of a "our users are beta testers" mindset with open-source software...
While I disagree with that. I think your approach to customer support is rational for an open source developer.
That said, I think open source would do well to treat every user as a customer, rather than as a user, which typically seems to be defined as a willing member of community. That's a legitimate view, but it assumes the user knows the rules of the game. It narrows the base of open software to people who know about or are interested in advancing the goals of that community.
Luke:
1. Firefox does pay attention to interface and usability. (That encompasses more than the "gui".) They have the financial backing to do that. Presumably, GIMP does not. My point is twofold: First, Photoshop has a reputation for being hard to use, yet it's primary open source competitor is harder to use. Perhaps if the GIMP folks had the financial backing of Firefox, they'd improve the product. But, all that is irrelevant to a customer looking for software. The only thing that counts is what is displayed on screen. Are users supposed to be so enamored of the open source model that they overlook defects in its products?
2. I have to challenge your assertion that a typical open source project has "lots of coders".
3. You've missed the point on innovation. I'm not criticizing forks, per se. I'm arguing that forking an existing product does not really represent innovation. It represents a variation, perhaps an improvement, on an existing product.
4. And you missed the point on attitude to customers. Developers file bug reports, not customers. Setting up a bug tracking site is not providing adequate customer service. Effectively telling users to "go away" is not customer service. Customers want help getting something to work. More often than not, their problem is not caused by a bug. Asking "Can I/How do I do 'X' with this?" is not a bug report. BTW, Bank of America changed its web site based on a suggestion I made.
5. "Gets the job done" is fundamental but far from being enough to sell a product. Otherwise, the world would still be running Word Perfect 5.1 on 640k DOS machines.
Your reaction to my post highlights the primary reason open source fails to make substantial headway in the market. Rather than accept my comments at face value in a "the customer is always right" frame of mind, you choose to challenge me instead. It's really rather difficult to persuade someone to use your product when you keep telling him he's the problem.
Being free, in cost or in development model, is of little interest to me when I chooise software. I want the best software I can afford, and I can afford more than no cost.
Here's a short list:
1. Lack of attention to interface and usability design. This is not "eye candy". Consider: People think Photoshop is easier to use than Gimp. What does that tell you? (Responses that trash Photoshop users illustrate the problem.)
2. I get the impression that, apart from the corporate funded biggies, many open source projects are staffed by one or two people. That's not confidence-insipiring when I'm looking for software to use for years in the future.
3. Rushed updates often made to conform to an established schedule. If an update needs more time, don't release it.
4. Lack of innovation. Software innovation is really, really hard and no one does it well. However, open source software, more or less by intent, produces many slightly varied iterations of the same code. I.e., forks.
5. Hostile attitude to customers: One of the touted benefits of open source software is access online to developers and other cognoscenti for tech support. Although I suspect it happens with less frequency these days, too many open source users are met with hostile "code it yourself" or "I'm not interested in that..." responses when they ask for help with a problem. Online support forums should not run bugtracking software.That's a developer-only tool.
Anyone who expects privacy on someone else's public web site is a fool.