Just because corporate interest have the power to get laws like this passed, this does not make it right or constitutional.
However, the fact that some guys wrote something down a few centuries before today's information technology was even dreamt of definitely makes what they wrote then the best principles for today's society to follow.
The blind faith with which some Americans worship their constitution is scary.
Since a free and informed press is viewed as a public good
Do you really believe that, as an absolute?
Consider what would happen if the press were effectively bought by politicians or big business in the absence of restrictions on spending. After all, they're free to print whatever they want, including whatever generates them the most advertising income, right?
What public good came of this disclosure? More generally, what public good comes from disclosing any business's trade secrets prematurely and thus damaging them (and all their investors -- that's your pension, boys and girls)?
A free and informed press is only a public good if it uses the information available to it responsibily and in the public interest. In this case, they have done neither.
Do you really not appreciate the difference between revealing information clearly in the public interest (which is defended by freedom of the press, 1st amendment rights in the US, etc.) and revealing any old information even if it should reasonably hav ebeen known to be obtained via illegal means?
Freedom of the press is not an absolute, nor is there any sort of superlaw that gives you a right to protect sources who you know damn well have broken the law. With rights come responsibilities, always. In this case there is no over-riding public interest, and there is a legitimate reason to want to track down the sources who are breaking the law and violating the trust of the people whose NDA they signed. Protecting the source is perverting the course of justice, pure and simple, and should carry all the penalties usually associated with such behaviour whether the protector claims to be a journalist or not.
Not so long ago, I was surprisingly refused credit. In fairness, that part wasn't Experian's fault; it was down to an automated address database that didn't recognise the correct form of my address and decided I didn't exist. However, during the follow-up enquiries with the credit card company who'd turned me down, I obtained a copy of my credit record from Experian. There were so many minor inaccuracies it was scary. The best bit was when, at 17:05 after speaking to someone there for five minutes (after about a half-hour on hold), I was asked "whether it really matters, because I'm supposed to go home at 5". I was speechless, and for me that's saying something.;-)
The really disturbing thing is that despite our actually pretty good data protection rules in the UK (the Data Protection Act does have some teeth, and thus far the Office of the Information Commissioner has proved to be very level-headed and apolitical in its actions) the entire credit and finance industry has basically managed to exempt itself. The credit agencies are allowed to keep files on me without my permission. Those files are obviously grossly inaccurate and poorly maintained, but if I lose out on something because of the bad information I have no recourse. (Well, I can add a "notice of correction" to the file after the fact, after getting a copy of my record at my own expense.) If a financial group turns you down for credit, they basically don't have to tell you anything, other than (a) whether an automated credit scoring system was used (in which case they do have to offer you a reassessment by a real human being) and (b) which credit reference agency/agencies they used.
Now, I'm not a big fan of credit in the first place. I always liked the advice to read "credit" as "debt": "3 years' interest free debt!", "I have a $50mil debt limit on my card!" etc. But in our society today, credit can be a useful tool when used judiciously, and if a market that is fundamental to the way our society currently works is to be allowed to regulate itself to the extent that it currently does, it has to be reasonable about fixing its mistakes. Otherwise, screw 'em, and let fly the lawsuits that everyone else would be subject to if they made the same sort of mistake with the same consequences.
FWIW, while the old <iostream.h> header was never standardised, AFAIK it always introduced the identifiers into the global namespace. That was one of the big problems, and one of the reasons for moving to the standardised <iostream> version.
I think perhaps we're talking at cross-purposes here.
I am not saying interoperability is bad, nor that open standards are not a useful safeguard in an uncertain world. I am simply saying that they are not as important as having software that does the job properly in the first place. Interoperability, open standards and easy extensibility are only means to an end, not ends in themselves.
I confess to not understanding your arguments about customisation of COTS either. No matter where someone gets their apps from, they have to trust a supplier sooner or later. From a business perspective it doesn't much matter whether that supplier is a megacorp or a consultant. No-one making the purchasing decisions in management is going to look at the code even if you've got it; this often-claimed advantage of open source software is more illusion than reality.
Similarly, in the real world people get new features added to COTS all the time without paying any consultants or having the source code. Despite all this potential for customisation and consultancy work that the F/OSS community likes to advertise, the dominant and best word processor is still Microsoft Word, and the best C++ IDE in the world is still Microsoft Visual Studio by a very long way. The extra resources Microsoft brings and its ability to listen to a wide customer base to assess the most important requirements for future versions are vital so they can add features people will pay for via upgrades. Despite all the talk of lock-in and incompatibility, they actually do offer worthwhile extra features in most new versions of their products, and that is why so many people continue to buy them (or don't, when they produce a turkey that doesn't really offer anything new that people want).
Can you name a single task that MS Word can't do, but some business has paid a consultant to develop as a custom feature for a F/OSS word processor? Just one thing, in the most popular type of application in the world? If you know one, how about ten? How about a hundred? You need this to be happening routinely to make your point about the flexibility of OSS and custom-development being an advantage over COTS software...
Sadly Mozilla doesn't have the luxury of running on "any decent compiler". While a good number of hosts use gcc 2.95 or cl.exe 12.x it has to support them.
Sorry, but that just doesn't make sense. Mozilla doesn't run on any compiler at all; it runs on different platforms. To run Moz on my system, I click the icon for mozilla.exe. I do happen to have GCC installed on my system, but it's completely unnecessary for running the application.
The only people who care about the compiler are those who are building the project themselves. Obviously YMMV, but if I were running the project, I'd rather help those developers who wanted to use modern language features to make their life easier than cater to a handful of people who for some reason want to compile from source but only using compilers nearly a decade out of date...
My professor told me never to use iostream like that.
Either you're a fairly obvious troll, or your professor is sadly ill-informed. In case it's the latter: the use of <iostream> (and other headers with no.h suffix) and the std namespace has been standardised for many years. The old <iostream.h> stuff doesn't always work the same way, and is officially deprecated.
I know some people disagree on this, but C and C++ are, in my eyes, not so useful as they once were.
I don't so much disagree as think it depends on your perspective. C and C++ both were, and both remain, excellent at what they were designed for: being a portable assembly language and being a powerful systems programming language for skilled programmers, respectively. They also have niche uses elsewhere, such as writing high-performance libraries that use a lot of maths (3D graphics, for example). The problems started when they became popular for other tasks -- notably application programming by non-expert developers -- because there wasn't a lot of choice. Today there is, and it's more important now to choose the right tool for the job.
That's because most programs for Linux are written with portability in mind, including the libraries.
Even the Linux kernel itself? I've never looked, so this is a genuine question, but a lot of people around here used to complain about the number of GCC-specific extensions the source code used.
It's not that Linux users don't want to pay for software
I'll bet you a lot of money it is.
Some people like F/OSS because of the open philosophy. Some people like it for the geek coolness factor. But an awful lot of people like it simply because it's free-as-in-beer.
There's a disturbing meme going through the industry that "COTS" (commercial, off-the-shelf) software can be sold without source code. That's bullshit.
Considering that the business model has been working successfully for years, it would appear that you are mistaken. What's more disturbing is the recent trend for open source fanboys to prioritise access to source code and/or immediate interoperability concerns ahead of getting software that actually does the job well.
Now, I'll grant you that any smart person buying a specialist product would at least want a clause in the support contract saying that if the supplier goes belly-up then the escrowed source gets opened. But neither forcing the opening of source before that point nor forcing it even at death for trivial software where there are plenty of alternatives available is a necessity, and that's got the COTS market covered on both counts.
And to even use STL would require enabling rtti & exception handling on Mozilla which would bloat the code by another 25%.
I'm afraid that information is also many years out of date. Overheads for unusued RTTI and EH support are almost zero in any decent C++ compiler today.
For example, the STL that ships with VC98 is atrociously inefficient and non-compatible.
In their defence, it was also written before the standard was finished, so some of it was a "best guess". If the next version of VC++ hadn't taken so long to appear, everyone would just have upgraded after a few months and thought nothing of it. The VC++.Net 2002 release had the twin advantages of actually having a standard to work to, and an extra 4 years of development work behind it, so it's not really surprising that it's better...
That's a fallacy. Windows hasn't had anything resembling a consistent look and feel since Windows 3.1, if even then.
While what you say is true to an extent, I think you're ignoring a valid point. Sure, Microsoft plays fast and loose with its own apps, particularly the menu, toolbar and open/save dialogs. Others tailor the interface somewhat as well. But the vast majority of the conventions -- the things an average user will just assume to work -- are the same in pretty much all native Windows apps. A right-click brings up a context menu. You save your work by going to File->Save, and you'll find the Open, Print and Exit commands in the same place. The max/min/restore buttons are at the top-right of the window if applicable. And so it goes.
Some variations on the theme work very well. I was impressed with the simple but effective variation Firefox has adopted for its "find" feature, for example. Others suck: after my first experience using the GIMP on Windows, when it insisted on trying to use completely unfamiliar UI conventions, I gave up.
But the bottom line is that most native Windows apps do have a high level of UI consistency, and if you're going to vary the theme, it should be for a clear reason (such as the Firefox feature I mentioned) and not just because you're developing an app with an inadequate toolkit that can't handle native widgets properly.
What limitations do you mean? [...] Risk? I don't understand you.
If Google folded, or got taken over by new management, or found a serious flaw and shut down the system without notice tomorrow, how much data would you lose? When was the last time you backed up your mail (and message rules, and address book, and spam database)? If Google's servers were cracked tomorrow, how much useful information about you could the cracker find?
There are basic security issues with trusting a remote service with important data, particularly if you're not paying for that service and have no contract and absolutely no come-back if they screw you.
That depends on your point of view. Some FOSS products are very good. Some are still mediocre at best, OpenOffice being perhaps the obvious example. However, these are so obviously not up to the standards of market incumbents like MS Word that people will stay pay much more money for the latter, unless they really just want a cheap package they can type simple documents with, and are prepared to put up with the shortcomings.
It used to be much simpler than that, with just three pretty clear phases for testing and QA.
Obviously you start with your in-house testing, hopefully a constant background activity as you write new code. This is just routine development activity, and might include unit testing, regression testing, and more. A lot of this will be done locally on specific areas of the software.
As you reach the end of the new feature development for your coming release, you bring everything together to build a complete version of the whole product. This is your first alpha release, and you run all the system tests, integration tests, etc. If there are serious failures identified here, they get passed back to the relevant dev teams, and we go back to the previous step until everyone brings their revised contributions together for the next alpha.
As an aside, obviously for smaller projects you might be working with complete builds from almost day one. In this case calling something an "alpha release" is giving it rather more significance than it really has: you're just identifying a "mental marker" where you switch focus from localised to global testing.
When we have what we believe is a solid alpha build, we might want to ship it to a select group of customers and prospects. This is a beta release. It's not supposed to be a marketing exercise; it's an opportunity to get feature-complete code tested in a wider variety of realistic contexts than you can ever create in-house, so that you have a better chance of finding any subtle bugs before release: hardware incompatibilities, interoperability problems with data from other applications, etc. As with alphas, if serious flaws are identified, we go right back to the dev teams at step 1 to get them fixed, and then go through the process of localised testing, global testing, and potentially (but this used to be a rare event) running a second beta test.
Note that further formal alpha tests should never be necessary at this stage. Once a project has passed an alpha test, no code changes should ever come through in the future that don't. If they do, they weren't properly regression tested. Hence you re-run all the system and integration tests as part of the next beta/final release testing just to be safe, but you don't expect to have another alpha cycle.
When you've run a beta test and are happy that you've got enough bugs for your software to be a product your customers want to buy from you, you make the release. The problem today is that marketing droids have taken over the beta release process; it's no longer about improving code quality in partnership with carefully chosen customers/prospects for everyone's benefit, it's about promoting your software before it's ready to manage customer expectations and get community support built up so you don't have to support it yourself. The additional testing and consequent quality improvement is often negligible.
For those who missed it, this implies that you ought to be feature-complete before going into alpha, though you might change something significant if your system tests identify a weakness you hadn't noticed before (e.g., the combination of features written in practice doesn't meet a requirement completely). Anything going out as a beta should be both feature-complete and very well tested internally. A lot of places would assume you'd get some significant flaws identified during the beta programme -- that's why you run it, after all -- but certainly anything beyond the first beta release should be a "release candidate".
I have no idea where this notion of several beta builds then several release candidates came from. Nor do I know when it became a Good Idea(TM) to make major functionality changes after you've entered the beta phase; doing so pretty much negates the point of the previous alpha and beta tests. It's certainly not a good approach to QA, and perhaps it's also why so many companies now seem determined to run year-long, 17-release beta programmes instead of shipping a finished product, and then a new release with the extra features customers requested six months later.
There is a reason NASA doesn't send the latest "working" laptops up to the space station, it's because you can only say something is "rock solid" after very extensive testing.
When I was younger, we used to do that testing before we released our software at all. If it hadn't been through our own test suite and passed everything, it didn't even get labelled alpha, and certainly didn't go to any (potential) customers. These days, everyone seems determined to release half-baked crap and then hope their customers/dev team could make up for it with some sort of on-line update system.
I've recently discovered that the clock on my fairly standard digital TV box is well-known not to be reliable, essentially making the whole timer feature useless. While I was out over the weekend, my friend's mobile phone crashed. I took my car in to be serviced a couple of weeks ago, and the guy in front of me at the desk was being told how his problem was caused by the electronics controlling his fuel injection system. This is what you get for accepting shoddy quality software and a "we'll fix it later" approach. The more serious accidents -- cars locking up at speed and causing KSI RTAs, phones not being able to make an emergency call because a trojan has taken them out, etc. -- will follow all too soon.
What other _free_ webmail system you've seen that offers: [...]
For web-mail, sure. Of course, many of us still use a single machine with a single mail client to access our e-mail. My Thunderbird box can do just about everything you mentioned with fewer limitations and less risk.
Except that this is no longer the case. With "partner programmes", and "beta test programmes" that are exclusive and require paying to enter, and even the ability to buy beta software at a signficant price (but less than the finished product), some software producers are doing exactly what the GPP implied: using beta software as a way to make money while having an all-purpose excuse to "justify" any feature faults or security problems. This is an unwelcome trend, IMHO; it is the "Wal-mart" of attitudes, applied to software, an industry that can scarcely afford it.
(In fairness, the advocates of OSS software have been known to do this as well: huge numbers of people were advocating Firefox betas as alternatives to IE when some things just didn't work yet, for example.)
I will dismiss your "research" with the simple statement that, personally, as a heavy reader (of paper books), I will find a serif font much more comfortable to read.
Please note the qualifiers in my original post about shorter works.
Sorry, but at work we've got whole stacks of reference docs saved in Word '97 format that can take out Word 2002 pretty convincingly just by trying to open the file.
However, he is incorrect in assuming that having only one solution will be best for the consumer.
I didn't say having only one solution will be best, I said having one good solution was better than a choice between many mediocre ones. You are attacking a straw man.
Right... until one day your favourite proprietor goes out of business or simply decides there's not enough money to be made on your piece of software.
Assuming the proprietary software I chose was good (as I specified in my original statement) why is this a problem at all? If there was one good piece of proprietary software in the market and everything else was mediocre, how did the good software proprietor just die out and one of the mediocre ones suddenly become better than what I've already got?
Of course we'd all like a choice of perfectly inter-operable good software in a competitive market in an ideal world; that's obvious. However, in the real world, having something that actually does the job you need well is better than having many things that only do a mediocre version, no matter how interoperable they may be.
Slashdot Mirror
However, the fact that some guys wrote something down a few centuries before today's information technology was even dreamt of definitely makes what they wrote then the best principles for today's society to follow.
The blind faith with which some Americans worship their constitution is scary.
Do you really believe that, as an absolute?
Consider what would happen if the press were effectively bought by politicians or big business in the absence of restrictions on spending. After all, they're free to print whatever they want, including whatever generates them the most advertising income, right?
What public good came of this disclosure? More generally, what public good comes from disclosing any business's trade secrets prematurely and thus damaging them (and all their investors -- that's your pension, boys and girls)?
A free and informed press is only a public good if it uses the information available to it responsibily and in the public interest. In this case, they have done neither.
Do you really not appreciate the difference between revealing information clearly in the public interest (which is defended by freedom of the press, 1st amendment rights in the US, etc.) and revealing any old information even if it should reasonably hav ebeen known to be obtained via illegal means?
Freedom of the press is not an absolute, nor is there any sort of superlaw that gives you a right to protect sources who you know damn well have broken the law. With rights come responsibilities, always. In this case there is no over-riding public interest, and there is a legitimate reason to want to track down the sources who are breaking the law and violating the trust of the people whose NDA they signed. Protecting the source is perverting the course of justice, pure and simple, and should carry all the penalties usually associated with such behaviour whether the protector claims to be a journalist or not.
Not so long ago, I was surprisingly refused credit. In fairness, that part wasn't Experian's fault; it was down to an automated address database that didn't recognise the correct form of my address and decided I didn't exist. However, during the follow-up enquiries with the credit card company who'd turned me down, I obtained a copy of my credit record from Experian. There were so many minor inaccuracies it was scary. The best bit was when, at 17:05 after speaking to someone there for five minutes (after about a half-hour on hold), I was asked "whether it really matters, because I'm supposed to go home at 5". I was speechless, and for me that's saying something. ;-)
The really disturbing thing is that despite our actually pretty good data protection rules in the UK (the Data Protection Act does have some teeth, and thus far the Office of the Information Commissioner has proved to be very level-headed and apolitical in its actions) the entire credit and finance industry has basically managed to exempt itself. The credit agencies are allowed to keep files on me without my permission. Those files are obviously grossly inaccurate and poorly maintained, but if I lose out on something because of the bad information I have no recourse. (Well, I can add a "notice of correction" to the file after the fact, after getting a copy of my record at my own expense.) If a financial group turns you down for credit, they basically don't have to tell you anything, other than (a) whether an automated credit scoring system was used (in which case they do have to offer you a reassessment by a real human being) and (b) which credit reference agency/agencies they used.
Now, I'm not a big fan of credit in the first place. I always liked the advice to read "credit" as "debt": "3 years' interest free debt!", "I have a $50mil debt limit on my card!" etc. But in our society today, credit can be a useful tool when used judiciously, and if a market that is fundamental to the way our society currently works is to be allowed to regulate itself to the extent that it currently does, it has to be reasonable about fixing its mistakes. Otherwise, screw 'em, and let fly the lawsuits that everyone else would be subject to if they made the same sort of mistake with the same consequences.
FWIW, while the old <iostream.h> header was never standardised, AFAIK it always introduced the identifiers into the global namespace. That was one of the big problems, and one of the reasons for moving to the standardised <iostream> version.
I think perhaps we're talking at cross-purposes here.
I am not saying interoperability is bad, nor that open standards are not a useful safeguard in an uncertain world. I am simply saying that they are not as important as having software that does the job properly in the first place. Interoperability, open standards and easy extensibility are only means to an end, not ends in themselves.
I confess to not understanding your arguments about customisation of COTS either. No matter where someone gets their apps from, they have to trust a supplier sooner or later. From a business perspective it doesn't much matter whether that supplier is a megacorp or a consultant. No-one making the purchasing decisions in management is going to look at the code even if you've got it; this often-claimed advantage of open source software is more illusion than reality.
Similarly, in the real world people get new features added to COTS all the time without paying any consultants or having the source code. Despite all this potential for customisation and consultancy work that the F/OSS community likes to advertise, the dominant and best word processor is still Microsoft Word, and the best C++ IDE in the world is still Microsoft Visual Studio by a very long way. The extra resources Microsoft brings and its ability to listen to a wide customer base to assess the most important requirements for future versions are vital so they can add features people will pay for via upgrades. Despite all the talk of lock-in and incompatibility, they actually do offer worthwhile extra features in most new versions of their products, and that is why so many people continue to buy them (or don't, when they produce a turkey that doesn't really offer anything new that people want).
Can you name a single task that MS Word can't do, but some business has paid a consultant to develop as a custom feature for a F/OSS word processor? Just one thing, in the most popular type of application in the world? If you know one, how about ten? How about a hundred? You need this to be happening routinely to make your point about the flexibility of OSS and custom-development being an advantage over COTS software...
Sorry, but that just doesn't make sense. Mozilla doesn't run on any compiler at all; it runs on different platforms. To run Moz on my system, I click the icon for mozilla.exe. I do happen to have GCC installed on my system, but it's completely unnecessary for running the application.
The only people who care about the compiler are those who are building the project themselves. Obviously YMMV, but if I were running the project, I'd rather help those developers who wanted to use modern language features to make their life easier than cater to a handful of people who for some reason want to compile from source but only using compilers nearly a decade out of date...
Either you're a fairly obvious troll, or your professor is sadly ill-informed. In case it's the latter: the use of <iostream> (and other headers with no .h suffix) and the std namespace has been standardised for many years. The old <iostream.h> stuff doesn't always work the same way, and is officially deprecated.
I don't so much disagree as think it depends on your perspective. C and C++ both were, and both remain, excellent at what they were designed for: being a portable assembly language and being a powerful systems programming language for skilled programmers, respectively. They also have niche uses elsewhere, such as writing high-performance libraries that use a lot of maths (3D graphics, for example). The problems started when they became popular for other tasks -- notably application programming by non-expert developers -- because there wasn't a lot of choice. Today there is, and it's more important now to choose the right tool for the job.
Even the Linux kernel itself? I've never looked, so this is a genuine question, but a lot of people around here used to complain about the number of GCC-specific extensions the source code used.
I'll bet you a lot of money it is.
Some people like F/OSS because of the open philosophy. Some people like it for the geek coolness factor. But an awful lot of people like it simply because it's free-as-in-beer.
Considering that the business model has been working successfully for years, it would appear that you are mistaken. What's more disturbing is the recent trend for open source fanboys to prioritise access to source code and/or immediate interoperability concerns ahead of getting software that actually does the job well.
Now, I'll grant you that any smart person buying a specialist product would at least want a clause in the support contract saying that if the supplier goes belly-up then the escrowed source gets opened. But neither forcing the opening of source before that point nor forcing it even at death for trivial software where there are plenty of alternatives available is a necessity, and that's got the COTS market covered on both counts.
I'm afraid that information is also many years out of date. Overheads for unusued RTTI and EH support are almost zero in any decent C++ compiler today.
In their defence, it was also written before the standard was finished, so some of it was a "best guess". If the next version of VC++ hadn't taken so long to appear, everyone would just have upgraded after a few months and thought nothing of it. The VC++ .Net 2002 release had the twin advantages of actually having a standard to work to, and an extra 4 years of development work behind it, so it's not really surprising that it's better...
While what you say is true to an extent, I think you're ignoring a valid point. Sure, Microsoft plays fast and loose with its own apps, particularly the menu, toolbar and open/save dialogs. Others tailor the interface somewhat as well. But the vast majority of the conventions -- the things an average user will just assume to work -- are the same in pretty much all native Windows apps. A right-click brings up a context menu. You save your work by going to File->Save, and you'll find the Open, Print and Exit commands in the same place. The max/min/restore buttons are at the top-right of the window if applicable. And so it goes.
Some variations on the theme work very well. I was impressed with the simple but effective variation Firefox has adopted for its "find" feature, for example. Others suck: after my first experience using the GIMP on Windows, when it insisted on trying to use completely unfamiliar UI conventions, I gave up.
But the bottom line is that most native Windows apps do have a high level of UI consistency, and if you're going to vary the theme, it should be for a clear reason (such as the Firefox feature I mentioned) and not just because you're developing an app with an inadequate toolkit that can't handle native widgets properly.
If Google folded, or got taken over by new management, or found a serious flaw and shut down the system without notice tomorrow, how much data would you lose? When was the last time you backed up your mail (and message rules, and address book, and spam database)? If Google's servers were cracked tomorrow, how much useful information about you could the cracker find?
There are basic security issues with trusting a remote service with important data, particularly if you're not paying for that service and have no contract and absolutely no come-back if they screw you.
That depends on your point of view. Some FOSS products are very good. Some are still mediocre at best, OpenOffice being perhaps the obvious example. However, these are so obviously not up to the standards of market incumbents like MS Word that people will stay pay much more money for the latter, unless they really just want a cheap package they can type simple documents with, and are prepared to put up with the shortcomings.
It used to be much simpler than that, with just three pretty clear phases for testing and QA.
Obviously you start with your in-house testing, hopefully a constant background activity as you write new code. This is just routine development activity, and might include unit testing, regression testing, and more. A lot of this will be done locally on specific areas of the software.
As you reach the end of the new feature development for your coming release, you bring everything together to build a complete version of the whole product. This is your first alpha release, and you run all the system tests, integration tests, etc. If there are serious failures identified here, they get passed back to the relevant dev teams, and we go back to the previous step until everyone brings their revised contributions together for the next alpha.
As an aside, obviously for smaller projects you might be working with complete builds from almost day one. In this case calling something an "alpha release" is giving it rather more significance than it really has: you're just identifying a "mental marker" where you switch focus from localised to global testing.
When we have what we believe is a solid alpha build, we might want to ship it to a select group of customers and prospects. This is a beta release. It's not supposed to be a marketing exercise; it's an opportunity to get feature-complete code tested in a wider variety of realistic contexts than you can ever create in-house, so that you have a better chance of finding any subtle bugs before release: hardware incompatibilities, interoperability problems with data from other applications, etc. As with alphas, if serious flaws are identified, we go right back to the dev teams at step 1 to get them fixed, and then go through the process of localised testing, global testing, and potentially (but this used to be a rare event) running a second beta test.
Note that further formal alpha tests should never be necessary at this stage. Once a project has passed an alpha test, no code changes should ever come through in the future that don't. If they do, they weren't properly regression tested. Hence you re-run all the system and integration tests as part of the next beta/final release testing just to be safe, but you don't expect to have another alpha cycle.
When you've run a beta test and are happy that you've got enough bugs for your software to be a product your customers want to buy from you, you make the release. The problem today is that marketing droids have taken over the beta release process; it's no longer about improving code quality in partnership with carefully chosen customers/prospects for everyone's benefit, it's about promoting your software before it's ready to manage customer expectations and get community support built up so you don't have to support it yourself. The additional testing and consequent quality improvement is often negligible.
For those who missed it, this implies that you ought to be feature-complete before going into alpha, though you might change something significant if your system tests identify a weakness you hadn't noticed before (e.g., the combination of features written in practice doesn't meet a requirement completely). Anything going out as a beta should be both feature-complete and very well tested internally. A lot of places would assume you'd get some significant flaws identified during the beta programme -- that's why you run it, after all -- but certainly anything beyond the first beta release should be a "release candidate".
I have no idea where this notion of several beta builds then several release candidates came from. Nor do I know when it became a Good Idea(TM) to make major functionality changes after you've entered the beta phase; doing so pretty much negates the point of the previous alpha and beta tests. It's certainly not a good approach to QA, and perhaps it's also why so many companies now seem determined to run year-long, 17-release beta programmes instead of shipping a finished product, and then a new release with the extra features customers requested six months later.
Which is interesting, because to everyone else in the industry, the beta (or sometimes alpha) is the point at which no more major changes are allowed.
When I was younger, we used to do that testing before we released our software at all. If it hadn't been through our own test suite and passed everything, it didn't even get labelled alpha, and certainly didn't go to any (potential) customers. These days, everyone seems determined to release half-baked crap and then hope their customers/dev team could make up for it with some sort of on-line update system.
I've recently discovered that the clock on my fairly standard digital TV box is well-known not to be reliable, essentially making the whole timer feature useless. While I was out over the weekend, my friend's mobile phone crashed. I took my car in to be serviced a couple of weeks ago, and the guy in front of me at the desk was being told how his problem was caused by the electronics controlling his fuel injection system. This is what you get for accepting shoddy quality software and a "we'll fix it later" approach. The more serious accidents -- cars locking up at speed and causing KSI RTAs, phones not being able to make an emergency call because a trojan has taken them out, etc. -- will follow all too soon.
For web-mail, sure. Of course, many of us still use a single machine with a single mail client to access our e-mail. My Thunderbird box can do just about everything you mentioned with fewer limitations and less risk.
Except that this is no longer the case. With "partner programmes", and "beta test programmes" that are exclusive and require paying to enter, and even the ability to buy beta software at a signficant price (but less than the finished product), some software producers are doing exactly what the GPP implied: using beta software as a way to make money while having an all-purpose excuse to "justify" any feature faults or security problems. This is an unwelcome trend, IMHO; it is the "Wal-mart" of attitudes, applied to software, an industry that can scarcely afford it.
(In fairness, the advocates of OSS software have been known to do this as well: huge numbers of people were advocating Firefox betas as alternatives to IE when some things just didn't work yet, for example.)
Please note the qualifiers in my original post about shorter works.
Sorry, but at work we've got whole stacks of reference docs saved in Word '97 format that can take out Word 2002 pretty convincingly just by trying to open the file.
I didn't say having only one solution will be best, I said having one good solution was better than a choice between many mediocre ones. You are attacking a straw man.
Assuming the proprietary software I chose was good (as I specified in my original statement) why is this a problem at all? If there was one good piece of proprietary software in the market and everything else was mediocre, how did the good software proprietor just die out and one of the mediocre ones suddenly become better than what I've already got?
Of course we'd all like a choice of perfectly inter-operable good software in a competitive market in an ideal world; that's obvious. However, in the real world, having something that actually does the job you need well is better than having many things that only do a mediocre version, no matter how interoperable they may be.