Slashdot Mirror
Taking On Software Liability - Again
An anonymous reader writes "You may remember an article in which a BBC correspondent wrote an article criticising current software licenses. In answer to the huge discussion that this brought about, he has written another article defending his views. From the article: 'It is possible to make error-free code, or at least to get a lot closer to it than we do at the moment, but it takes time and effort. Doing it will probably mean that commercially-available code is more expensive and cause major problems for free and open source software developers. But I still believe that the current situation is unsustainable, and that we should be working harder to improve the quality of the code out there.'"
not gonna happen its like asymtotical or something. you keep spending money developing and finding buys and keey going yet getting less returns out of it.
http://omgwtfmedia.blogspot.com/
I've got an idea. For non-software developers with great ideas. You program some piece of software for 5 years and then warranty against any bugs or failures. Oh btw, it must be priced competitively with current offerings. This guy can go wank himself in a corner somewhere. Perfect software doesn't exist. If you want something done right, your best bet is to do it internally to your company instead of outsourcing. Walmart is a perfect example. Do it right with people that feel they have ownership in the software they are creating and you'll get a better product. Plus, Arkansas (and my state too) are like Bangladesh anyway in the wages paid to software developers.
It is quite obvious that the quality of open source code is not great - but since it was done 'free' those developers can walk free. But if I pay a developer to write some code, and his incompetence introduces bugs... I want to sue his ass off!
This guy sounds like he's just full of hot air because of a bad Norton AV installation. If one program causes something "devastating" to happen, who is to decide that it's not the user's fault, the compiler's fault, the programmer's fault, the OS creator's fault (and if it's OSS, who's package etc?), or the hardware's fault?
The computer world if full of many variables and I don't see this happening anytime soon, though with recent laws you never know.
$fortune
Tomorrow has been canceled due to lack of interest.
is stale software. Bit rot guarantees that all users will migrate from error-free, real stable software, to new-full-of-bells-and-whistles but error-ridden software in 0 time.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
The fact is that the market has already decided the answer to this. People buy the least expensive software they can get away with. If the application is unreliable enough to regularly lose data it gets flushed out of the market. If it works well enough and is for the desktop it becomes popular. If it is used in critical applications where data loss is not tolerated they you have stuff like Oracle which people pay $50,000 per CPU for.
There is also a big difference between consumer software like word processors and web browsers, and the massive information systems used internally in large companies.
The companies writing the large systems usually have contracts which mean they are liable for damages, and this increases both the cost and the reliability of the resulting programs.
I must assume he doesn't work with internal apps much.
Snowden and Manning are heroes.
Everyone knows that most free software, by virtue of peer review, has fewer bugs and errors than commercial code does. If what he means is that you have to be licensed, bonded and "protected" by a corporate staff of 800 pound gorillas to write code, then free software will have problems. Such a missallocation of resources still won't buy him better code.
This whole issue is a troll the non free software companies come up with every few years. It's a mistake for them, however, and will blow up in their faces. Free software will overcome such nonsense the same way Good Samaritans do. Worse, what kind of society would outlaw exchanging of advice on how to do something? That's what sharing source code it. Why not outlaw engineering texts instead?
Friends don't help friends install M$ junk.
I've said this years ago: software liability should apply on programs you pay for but for which you don't get the source. If money you pay goes to make something you don't have source level control over then that implies the vendor thinks its of sufficient quality that you, the end user, should not have to fix it. If you get the source then there is no guarantee and the distributor should have no liability. This doesn't mean you have to have the right to re-distribute the source -- but you have to have the right to re-build it using commonly available tools so liability can't be limited to one "magic" libarary.
Bug free software is possible, so long as it is done right and people are prepared to pay for it. Right now, software is mainly "good enough" and "cheap enough". What is "good enough" and what is "cheap enough" will depend on what is being done.
Engineering is the art of compromise.
that must be the article with the least content in my entire slashdot "career".
no thesis, no argument, no concrete examples of HOW to make software better or HOW to implement such liability.
i do understand this is a follow-up, but why exactly should ANYONE care about this mindless piece of crackpot-tery?
[ ] vendor guarantees that software works as advertised
could be another checkbox that all software companies are trying to reach.
"What? You don't guarantee works-as-advertised? Well, then I'm looking for a different product."
If computing magazines would update their testing methods and added this one checkbox, Microsoft just might say "oh, hey, we haven't covered that checkbox yet. We need to have every checkbox. Let's quickly drop by the legal department get this in order..."
That's been shown to be impossible! Otherwise I would do it 24x7.
Netbooks, they come with Linux or a $3 copy of Windows. Either way, Microsoft loses.
The Lawyers will love it. They will launch massive class action law suites and will make millions. If you are part of that class action you will get one dollar.
The software vendors will not fix bugs because to fix them they have to admit they have them and will get the daylights sued out of them.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
The keys are:
* Tell users to stop asking for tons of new features in unrealistic timeframes.
* Tell software managers to actually give individual developers time to develop software the write way instead of insisting that they slam code out.
* Get compentent testers who can help catch any aggregious problems before it goes to market.
* Stop hiring assholes who just have certificates and get some degee holding professionals who actually know what the f*ck they are doing.
* Stop outsourcing to india where most programmers are taught to slam out code no matter how messy it is. (I know this because I've worked with a few people who've come from that environment to the US)
All of the above costs money. If you're willing to spend the $$$$ that all of the above will cost you, you're software quality will improve.
Until then STFU.
Later, GJC
Gregory Casamento
## Chief Maintainer for GNUstep
Software products, the Internet and concepts of open source and free software are so new that our eminent law makers are having severe difficulties trying to comprehend the implications of their use on society. The concepts of negligence, mechantable quality and misleading and deceptive conduct that prevades traditional product liability cases are difficult to apply in cases of software faults, especially when it is free software. Modern complex systems are usually confined to specialised units such that faults can usually be traced to a responsible entity relatively easily (e.g. nuclear power plant). However very complex software products often interact with each other in the mass consumer market sometimes producing unpredictable results which may or may not be intended. Added to this is the question of even who is responsible in a free software environment where the contributors number in the thousands. Traditional legislative framework that govern normal product liability need to be overhauled in this new complex software environment. However given that our eminent law makers will, for the forseeable future, remain wilfully ignorant of the pace of technology change I doubt things will change.
Pundits seem to frequently make two assumptions/assertions
1) Free software is less tested than commercial software
2) Free software programmers are programming for free. (The article
claims this without the slighest proof)
But I know from personal experience neither of these is universally true,
and I don't believe either to be particularly true. I wish there was
a great deal real data on these topics, but there does not seem to be.
1) I know proprietary products sold to customers by a commercial
enterprise that were written
by one person and not code-reviewed or even read by anyone else ever. (Ok, not a big seller, but who is to know the statistics of review
in proprietary software? Proprietary software is well hidden...)
2) I know one open source product on which all the key contributors are paid to do
the work because it benefits the companies they work for.
Just not paid by the FSF that owns the product.
My comments don't prove anythin, they just advise caution about pundits
who seem to make questionable assumptions.g
The possibility of errors rise with the size of the project, number of people involved and competence of the programmer. If precompiled libraries are used those are also a source for errors.
Error free code is another funny concept like police protecting you (they exist to enforce law, not protect you).
The author has a point here. We accept a lot more ... "bugginess" in software than we do in any other product (Cars, Banks, Tools, etc.) And it's pretty much become the norm that if there are problems, folks just shrug, claim it's just software and move on.
But if the folks building bank vaults left as many holes in their products as software, people would be screaming bloody murder.
I've done software development as a hobby myself, and don't release my code to the public, because I know it's not even up to my own standards of stability, reliability, security.
Programmers/developers need to take more time with their products, and think security & reliability from the start of a project, not as an afterthought.
With as many products requiring patches within the first couple weeks of release, consumers do need to start getting angry about this stuff. Or, at the very least, start challenging software companies when the products they do release require more MB in patches than the software was originally....
-merlyn
Ah, so he wants people who right software to guarentee their work?
Things will then just never make it out of beta, for fear of the law. If the software breaks "Tough luck, it's still in beta, what were you doing using it for mission critical work anyway?"
This "eternal beta" is also used to avoid other sorts of legal wrangling . The most obvious example is Google News - it's "beta" still because google is worried about capitalizing on other people's news content. While unrelated to software quality, because it's an "unfinished beta", it doesn't get sued out of existance.
So, welcome to using software versons 0.9.9 forever... I can't wait.
None of these demands fosters reliability. It fosters a frantic race to add features and ship stuff ASAP. Everyone seems caught in a massive vicious cycle of upgrades so that nothing ever stabilizes or matures.
Perhaps if/when people stop finding new uses, new formats, new file types, and new applications, then the industry will mature and people will turn their attention to stability and reliability.
Two wrongs don't make a right, but three lefts do.
However relatively bad the security of Microsoft's products are in comparison to what the free licensed and open source communities ( as well as practically every other vendor on the planet ) provide, Microsoft is not alone in the presence of vulnerabilities, this is a major issue for Linux/BSD and Unix as well as ever other OS and vendor.
From the Plimsoll Club history
The risks,issues and solutions for providing a more secure operating and application enviroment have been known for decades.
Those who do not already comprehend the issues and are willing to learn, should take some time out to listen to some of the speeches at Dr. Dobbs Journal's Technetcast security archives, starting with Meeting Future Security Challenges by Dr. Blaine Burnham, Director, Georgia Tech Information Security Center (GTISC) and previously with the National Security Agency (NSA)
The design and implementation of some applications and servers are just too unsafe to use in the "open ocean" of the internet.
Numerous security experts have railed against Microsoft's lack of security, best summed up by Bruce Schneier Founder and CTO Counterpane Internet Security, Inc who rightly said:
However Microsoft's products are not alone in the presence of vulnerabilities, this is a major issue for Linux/BSD and Unix as well as any other OS and vendor.
In a recent speech "Fixing Network Security by Hacking the Business Climate", also now on Technetcast, Bruce Schneier claimed that for change to occur the software industry must become libel for damages from "unsecure" software
For now, given the languages software is commonly written in these days.
What the liability should be is for Time To Fix.
A software developer shouldn't be liable for a bug, but they should be liable for unreasonable time to fixes for the bugs. How long is unreasonable? That depends on the severity of the bug as it relates to security and advertised functionality. I'd say that a week was long enough to post a fix in most cases for a replicable bugm certainly no more than a fortnight.
This type of liability might be a problem for spaghetti-code houses that knock out crap without a care. I don't mind if these places get a kick up the backside.
The issue is rushed software development, utilising software programmers rather than software engineers. Liability rules would mean a move towards proper software engineering - the implementation might still be by mere programmers of course. It'll probably take twenty years or so to get to this state I suppose.
bill thingi that wrote the article likes to jump on the latest band wagon the bbc send him.
from his previous articles, he has scant grasp of the realties of the tech world. he gives his 2 pence worth to the bbc so they can publish another "the sky is falling" piece.
yes perfect software is possible, but you can't possibly afford it
civil engineers do not build perfect bridges, they build them within tolerances. plus you don't normally build a bridge with a box of millions of different bits. you get your lot of girders and cable etc. which are all relatively speaking the same.
The reason you can't use critical systems development techniques to develop applications software is because the cost/benefit analysis is still unbalanced heavily on the side of cost. If you're a company that does critical systems development you have a greater chance of success if you find a client that requires critical systems as the benefit (often, "people don't die") far outweighs the costs. But Open Source turns cost/benefit analysis on its head. When developers volunteer their time the costs can't help but remain low. When the benefits are spread around to everyone, instead of just a select few, large costs can be justified. Sure, we'll need an order of magnitude more developers, and they'll have to learn new techniques, like formal specification and software verfication, but we're geeks, we like to learn new things and we like to have real projects to practice our craft on. How many of us are going to get the chance to develop using critical systems techniques? It'd be fun, and imagine the bragging rights: Four years and counting and not a single bug found. Unprecidented.
How we know is more important than what we know.
Everyone knows that most free software, by virtue of peer review, has fewer bugs and errors than commercial code does.
No, I don't know that.
Would you mind telling me it's basis?
OSS software typically has fewer bugs because most OSS projects are so small in scope that it's possible to kill most bugs within the useful lifetime of the software.
The large OS software (Mozilla, Linux, OOo) that exists typically has as many bugs (or more, in the case of Firefox -- note all the exploits being released for it, now that it has market share) as it's commercial counterparts.
Where did I get that idea?
I pulled it out of my ass, just like you pulled that crap out of yours.
I do not think we should automatically exclude free/open source software from our analysis simply because it is produced by teams of programmers working for nothing, and the fact that it is given away does not, of itself, provide legal immunity.
I do, at least to the full extent of the law.
Expecting anything from someone who gave you free/free software isn't reasonable. The fact is, the licenses are there not only to save the developers necks but also to serve as a warning. When something says "AS IS" that means exactly what it says. You take it as it is, faults and all. There is no trickery involved. Nobody tried to sell you a lemon.
Writing error-free code IS impossible because there is no possible way to enumerate all the potential hazards that face the software. In a bubble, on a clean install, software can behave "perfect". Once you let it out into the real world where people have literally an endless number of different conditions on their computers, it's simply not realistic. If the operating system has a single flaw, then the software is inherently flawed as well. We all know about Windows' track record of buginess and of course all OS suffer from bugs. That doesn't mean the developer or corporation is trying to get by with it (well maybe some). It just means that "to err is human".
The way I see it, free software (as in freedom) is a community effort. If it doesn't work, it is just as much as your responsibility to fix it, by contributing either time or money. If you won't help fix it then you are as much to blame as anybody. I guess that sounds harsh but I'm really tired of seeing everyone passing the buck to someone else, especially to the people that are trying to help society by providing possibly useful or entertaining software. These developers are doing us a favor. They don't have to write software for us and we don't have to use it. Expecting anything more than that is absurd.
"The companies writing the large systems usually have contracts which mean they are liable for damages, and this increases both the cost and the reliability of the resulting programs." As an IP attorney working in the industry for the last 14 years, this statement is just so....amazingly....stupid I would have thought the editors of the BBC would have caught it. It is wrong on so many levels. No non-on-the-ropes software developer will bet the company on error-free code. At the most, a developer will agree to correct errors. And MAYBE some limited liability for intentional errors.
I haven't taken the time to read the prior article carefully, but whatever the point he was originally trying to make has been completely lost in his attempt to shift the goalposts of the argument. (As far as I can tell, his original article said we should be allow to sue programmers for bugs.)
This second article says "people should write better code". Well, um, I disagree! Wait, no. Of course not. Yes, the quality of code should improve, and should always be improving.
The analogy to automobiles seems quite ridiculous. While there are some rare and unusual automobile failures, the basic system you have to check to make sure a car is "fatal accident free" is both completely transparent (mechanical connections that you can fully simulate if need be) and has been unchanged for years. Furthermore, it is possible to "overdesign" -- you know what the failure is going to look like (car hits object stops suddenly) and you can plan against it.
Software is something completely different. Each piece of software does something new (or, at least, it should.) The connection between different components is not transparent and while there are overall structural similarities, and long tested protocols, those protocols are nowhere near as "clean" as a car's drivetrain. Not to mention the fact that truly new software has to invent protocols along with the code.
I would imagine if car manufacturers changed basic facts about the drivetrain or the steering mechanism or the car structure each time they built a new car, they'd have a bug rate close to the average piece of software. And, of course, car bugs are not new -- there are the famous ones, like the Pinto (and less famous ones, like the "suicide doors.") To put things in perspective, when the Pinto was built, cars had been around for decades on decades. Are there any remaining fatal bugs in a classic C compiler?
Protect your liberties. Donate to the ACLU
It doesn't make economic sense to create some kind of liability for the authors of software; there is no single level of quality that everybody needs.
The best thing we can do to increase software quality is to hold the people responsible who can actually do something about it: the people who buy software.
If your Windows PC crashes and you lose data, that's your responsibility; you could have gotten something different.
If the bank's Microsoft-based database server has a serious security hole and someone breaks in and defrauds customers, then the bank should be held fully responsible for that; they shouldn't be able to shift responsibility to either Microsoft or the person who broke in. That will force institutions like banks to negotiate contracts with software vendors that ensure an appropriately high level of correctness. And there is no need to burden our courts with "hackers"--you won't be able to find and lock them all up, so locking up some of them is not a rational strategy for making computers secure.
In any case, if one wanted to, one could easily make legal distinctions betwen FOSS and Microsoft/Apple when it comes to liability. First, expert users generally have to accept a higher level of responsibility than non-experts. Arguably, FOSS users are, by definition, expert users. Also, for-pay software involves an actual sale, which can easily and sensibly be regulated differently from non-sale distribution when it comes to liability.
Once someone starts making analogies between building software and building bridges or cars or houses, you can pretty much ignore what they have to say. Engineering software is unlike any other form of engineering in almost every way. All of your cost is in the design and test cycle. Prototypes are available to test for free as development occurs. Building and distributing the finished product is incredibly cheap. Replacing faulty software is typically inexpensive for both parties.
The economies of the situation provide completely different motivations from the realities of engineering a physical product, so there's just not much point in the analogy.
-- Moderation in all things, exceptions to all rules --
Near perfect software is possible:
They Write the Right Stuff (I got it from here: Space Shuttle Software: Not For Hacks)
Yes, it takes time and money but it isn't unthinkable to change how software is written. Fully understand your customer, and justification for EVERY code change. Code reviews aren't important, they're everything. When the way we think about writing code changes and the procedures become commonplace it won't cost so much to do it this way.
Dan Bernstein has offered a guarantee for many years that djbdns and qmail are secure. Now, this is a rather vague guarantee, since the task of deciding if a reported problem is a security flaw lies with Dan Bernstein himself; but it's a start.
I'm currently writing some cryptographic code, and I intend to go considerably further: I intend to offer a guarantee not only that my code operates as specified, but also that it is not vulnerable to any side channel attacks within certain classes.
As the time-to-exploit of security flaws continually decreases, I see only one solution: Writing code which is correct in the first place. If you can do that, you can offer a guarantee. And hopefully once security becomes as larger issue to consumers, people will start looking for guarantees.
Tarsnap: Online backups for the truly paranoid
Making bug-free software is much harder than anyone can imagine.
Let us not forget the very modest program IEFBR14 - arguably the shortest
program ever written for use in a production environment. It ran on IBM's
System/360. (I rans it many times myself.) Its sole function was to
exit - nothing else. It was a whopping one machine instruction long - 2
bytes. It was even Open Source (BR14 is the assembly language version of
the instruction, which is the standard way programs exited). It was the
simplest possible program that one could write. If ever there was a
program that was going to be bug-free this was it!
It had a bug.
When a program exits on OS/360, it is expected to have set some bits to
indicate any errors. When a program is called, those bits are in an
unpredictable state. IEFBR14 had to be modified (doubling its length) to
clear the bits first.
Sigh...
When I ran Autopr0n, hooo... that code was awful. But there really was never any kind of economic incentive to fix it, I could just keep restarting my JVM (the thing was coded in java).
Or, look at metafilter.com. That site goes down like a $2 hooker, yet it's so successful that the maintainer was able to quit his day job and support himself based on the site. People don't care.
Even when you get to a desktop OS back in the '90s, quality just wasn't that important. Would you rather pay $10,000 for an OS, or $90 and loose work once in a while.
If the cost of the lost work due to software errors is less then the cost of writing the code so that it works perfectly, then it's not worth doing. Sure, for some programmers there's not a tradeoff, but those programmers probably cost a lot more to pay then 90% of the coders out there (who are idiots, IMO, just look at the existence and popularity of Visual Basic).
When the cost of the error increases, you'll find much more stable software (like on medical equipment, airplanes, and so on).
The secretaries spreadsheet just ain't mission critical.
Of course, now that all computers are connected together, they need to be at least secure and not targets for worms and trogens, etc. I predict that we move towards web services, the software quality will get worse and worse, but people will just pay a sysadmin to sit there and reboot the machine whenever it goes down, so people won't notice everything...
autopr0n is like, down and stuff.
This is an issue that I have tried to find a decent answer to. I have some engineering software that I wrote (or will write) and want to release as open source. There's no real money in it, and if I had to support paying customers, fagghetaboutit. I've been around it long enough to know that a) you can't reasonably develop bug free software of anything more than moderate complexity and b) there's still the chance that someone does something stupid (garbage in, garbage out). With current product liability laws, I would be on the hook if something went wrong. Now, I'm not talking about software where a bug causes someone to lose an hours work, but software where a bug could possibly result in the loss of multi-million dollar equipment. Even though I'm giving it away, I could be sued into oblivion if some schmuck uses it and screws up. My big question is this: Is there an open-source license that effectively limits product liability? They all more or less have clauses, but I'm not all that sure they hold water. Anyone know anything about this?
"The companies writing the large systems usually have contracts which mean they are liable for damages, and this increases both the cost and the reliability of the resulting programs."
Usually??? Liable for damages? I've done a lot of consulting working on contracts and it's a standard procedure to disclaim or SEVERELY limit all liabilities. Otherwise, you'll be out of business pretty soon: e.g. deliver $1M of software and have a couple of trades go wrong with damages of $50M due to some rarely used and poorly tested branch of the algorithm.
Seriously, can someone point to even one example where a software development company (with exception, perhaps, of medical/life support and nuclear industries) would accept liability for damages?
Well here's a question, Mr Informative. Have we reached the "point of diminishing returns"? Why bring up a point, that we haven't even gotten close to yet? In fact, after reading this. I'd say that we have a long way to go.
Our marketer continually pressed to release feature code before it was completely tested. Our QA enforced zero defect and full regression testing on all releases. Where it paid off was in user support, we charged a resonable maintenance fee for suppport that we never had to provide because the software was fully documented and tested. Our support staff was a guy with a pager, who answered calls 24/7 for software that was sold on 5 continents around the world.
Our software was squashed by our marketer in the end because we would not relinquish control of our source code. So our marketer killed our software business. The problem with software is marketing and the lack of commitment to quality.
Because of the nature of our software, we had 5 major releases including Beta over the 3 years, not to mention interim feature updates. Again, only 3 public user impacting bugs. Our focus on quality minimized our need for support.
As I said to begin, zero defect quality software is attainable, but it requires discipline and the strength of will to resist the marketer. I hope that I will again get the opportunity to prove it.
unsustainable - (adj.) 1. Following a pattern which can not continue indefinitely due to the inherent limitations of the system. "Present growth is unsustainable in the long term." 2. A term expressing distaste, annoyance, and a personal desire to change things. "The current situation is unsustainable."
proof, n. A demonstration that a conclusion is implied by certain premises and axioms.
There has been a lot of discussion about my call for software liability in a column entitled Whose fault is it anyway?, and it shows that this is an issue which needs some serious attention.
/sarcasm
"it" is an unclear variable reference. Does the pronoun "it" refer to the call for software liabilty or the column itself? Also, the title of the column should be italicized, underlined, or capitalized for clarity. Finally, the phrase "a lot" is depreciated.
There is also a big difference between consumer software like word processors and web browsers, and the massive information systems used internally in large companies.
Syntax error. No comma is needed after "browsers".
The companies writing the large systems usually have contracts which mean they are liable for damages, and this increases both the cost and the reliability of the resulting programs.
Syntax error: a comma should proceed a "which" as discussed in rule 11.
Many readers commented on the difference between free/open source software and commercial software when it comes to guarantees, and criticised my use of the licence for the Firefox browser as an example.
Syntax error: no comma is needed after guarantees.
something that is paid for
Better: "something for which one pays"
But liability for consequential damage is different from guarantees of proper working.
Awk. Please unobfuscate this sentence.
Cars are a good example here. Motor vehicles have to be safe, and there are rules and regulations governing their development and production which, by and large, keep the roads safe from exploding cars. It does not stop accidents caused by driver error or poor maintenance, but it does make us safer.
Again, confusing pronoun reference. The "it" in the second sentence seems to refer to "rules and regulations". If this was the intent, please correct to "they" as this could cause unexpected results.
And if a group of people build their own cars then they have to follow those same rules in order to be allowed to use public roads, even if they gave their cars away.
The second variable "they" above refers to "group" not "people", which is singular. This sentence could be further optimized. Suggestion: "If a group built their own cars, it would still have to follow those same rules to use public roads, even if it gave the cars away."
It should be the same for software
Uninitialized variable. What is "it"? Please specify.
It is possible to make error-free code, or at least to get a lot closer to it than we do at the moment, but it takes time and effort. Doing it...
Overuse of "it". Please be more explicit in your casting.
Bill, please check your fixes as soon as possible before someone gets the idea to sue. Thanks.
And you get modded down. Genius.
Seriously here people, most free software is complete tripe. The popular projects you hear about, Linux, Firefox, etc. are just a small fraction of what's out there. Peer review only works if people are interested in your project.
Open source tends to be written by/for people who care more about stability than features, and that's a major help, but it is not miraculously better. How many people here have actually sat down, and looked over the source of an open source project to check for bugs/exploits?
"For now, given the languages software is commonly written in these days."
And what language would you recommend?
Has he even ever written a program in his life? Idiot.
Proverbs 21:19
Of course, I am being a little facetious, but the pressure to reach the market is simply too great to allow for stable software development.
Okay, so we've had the predictable reponses about how building software is different from building bridges, and then others point to the respective difference in cost. All true. But if bridges and buildings are so much more reliable than software, it's not only because they cost more. It's also because when they are designed and built, all procedures must conform to known standards (and not a few regulations). The specs are open and auditable, and architects actually have their work inspected all the way.
Should every word processor be built in this way, with open specifications, norms and audits? I don't know. Now how about vote-tallying software?
"Only the small secrets need to be protected. The big ones are kept secret by public incredulity." - Marshall McLuhan
First off, I should issue a disclaimer that I'm an oldbie. I started programming in assembly language on punch cards, but no, this isn't going to be a rant about youngsters and their newfangled languages. (At least it better not be; my current job has me living, breathing, and eating PHP.)
The problem with bad software today -- just like it was thirty years ago -- is bad engineering. It's not because of the methodology du jour (or its absence), licensing, choice of language, or toolsets. You can write brilliant, bug-free, efficient software in COBOL using the basic procedural structured programming paradigm. You can write awful, buggy, resource-hungry software in object-oriented Java using XP. None of that shit matters.
Good engineering requires, among other things, a detailed understanding of the problem, thorough planning, the sheer experience required to distinguish between the clever and overcomplicated on one hand, and the lucid and elegant on the other, excellent communication between developers, foresight (also borne of experience), and rigorous debugging. All of these things, including the many other prerequisites not mentioned, require lots of time and effort. Too much time and effort, in fact, for most commercial software outfits to invest and still turn a profit.
That's the rub, really. All the methodology and language fads aside, the basic principles of good software engineering were worked out decades ago, and sometimes further -- good generic engineering practices in the abstract were worked out long before we harnessed electricity. It all comes down to this: the more time, effort, and care you put into a product, all other things being equal, the better the product will be. It's easy (and well-deserved) to mock Microsoft for the shoddiness of their major products, but that very shoddiness is why you can buy MS Word for less than ten grand. If MS built word processors the way engineers built the Golden Gate Bridge, the prices would be comparable.
The market does not reward that kind of quality. In the first place, no one is willing to pay thousands of dollars for a supremely excellent product when one that is good enough can be had for a couple hundred. Most folks couldn't afford that kind of software engineering even if they wanted it. In the second place, once you have the perfect all-in-one software package, why would you ever buy another one? Microsoft is in this position already with its good-enough products. No one needs an upgrade, so remaining profitable requires MS to churn out new versions of its increasingly resource-intensive operating system so that you at least have to buy new copies as you replace your older machines.
FOSS is at least theoretically invulnerable to these pressures. In theory, there will eventually be all-singing all-dancing FOSS packages covering all of the major software categories, and the age of commercial mass-market software will be at an end. I've been waiting for this day to come since well before the first release of Linux. I'm surprised that it hasn't come yet. I'm surprised that the majority of FOSS software is still as buggy, poorly designed, and -- almost without exception -- undocumented as its commercial equivalents.
I suppose I shouldn't be surprised. Excellence in software engineering is like excellence in any other field: it's really fucking hard. It's even harder when you have a day job; time constraints aside, after 8-12 hours coding at work, the last thing many developers want to look at when they get home is compiler output. Many of the remainder are either amateurs or students -- not to diss either category, but often the necessary experience is lacking, and the lone hacker often lacks the knowledge or the inclination to produce code that's easy for other developers to work with. I remain confident that we'll get there, though. (I am less confident that I will still care by then, but it will still be a boon to those who live to see that day.) I am equally certain, for the reasons
Proud member of the Weirdo-American community.
You mistakenly assume that just because someone is given the source code, they are capable of understanding it and making fixes. If your refrigerator manufacturer gives you the blue prints to the frig, does that mean they aren't liable if something goes wrong? Software shouldn't be treated any different than any other product. If there is a safety issue, then the manufacturer should be required to provide a fix. Source code or not shouldn't have any effect.
I don't think that we can simply say that the market has decided against software vendors accepting liability. Part of the problem is that so much software comes from Microsoft, which has refused to assume liability for its software. A company that tried to distinguish itself by selling a product that competed with Microsoft at a higher price in return for better quality assurance and a real warranty would probably not survive, not because people didn't like less buggy software with a warranty bug because of Microsoft's near monopology power.
It seems to me that a better approach would be for insurance companies to sell third-party insurance. They could test the software themselves, to whatever degree of rigor they considered appropriate, for whatever kinds of bugs they and their customers considered important.
This would have several advantages. First, it would not favor rich software vendors over poor ones, commercial products over free software. The insurers would evaluate the software and would set their premiums in accordance with their evaluation. The fact that the producer lacked the ability to stand behind a warranty would be irrelvant. If the software was of high quality, the insurance company would decide that it was not taking on a large risk by insuring it.
Another advantage is that software users could negotiate appropriate amounts of insurance at appropriate rates with the insurance company. One problem with asking the software producer to stand behind it is that users may have a vast range of uses and bugs may have vastly different consequences for different users. If a program crashing just means you have to go to Kinkos to make a poster or a greeting card, the damage is minor. If a security flaw reveals your company's strategy to a competitor it may cost you millions of dollars. Customizing the warranty that the producer gives to the customer is impossible outside of very specialized niches, but this is the sort of thing that insurance companies do all the time.
ANY software is better off if more people have access to the source, and have an interest in the use or improvement of the software. Just source access is needed for this. Look at JIRA by atlassian for example, or one of the thousands of other commercial software that allow source access (java for example).
99.9% of open source software is buggy rubbish. Just look at the sourceforge graveyard. The best projects have lots of users with a vested interest in the projects success (see linux, gnu, mysql, perl etc). This allows many people to inspect and improve.
Open source per se has nothing to do with it - nor does commercial software. Its the people who have access to the source, whether it be companies or the public that determine the quality, not the license which its distributed with.
people demand that it sucks.
Seriously. For nearly every case, if there are two available pieces of software (OSS or not), most people will choose the one that is more feature rich. Sure, those in a mission critical situation or the poor people that get to install and support the software long-term will demand quality and maintainability. But, those people are far outnumbered by the masses that use software casually.
So, given a limited set of resources, quality will always be just barely up to what people will tolerate. Yes, even in open source software. Example: Mozilla Thunderbird -- They have a feature schedule out right now. About half of the planned features are in the current build. Do you think they'll wait until the code is 99.99999% error free in all situations before comitting time to add features? They have no deadlines, no financial burdens, no one telling them to ship the software. Yet, they will ship it. If they don't, their user base will entirely desert them and switch to a horrible, buggy, alternative (probably Outlook Express). This is simply because people demand cool crap. That's why they buy half the crap they buy, that's why the US has a $250 billion trade deficit with China. We collectively love crap.
"The computer world if full of many variables and I don't see this happening anytime soon, though with recent laws you never know."
Translation: This computer stuff is too complex. Why didn't I become a dentist instead?*
*Free hint: The whole process of software development is about the managing of complexity to tame it and create something useful from chaos. And quite frankly we haven't really tried to do so, and in fact work against any efforts to do so in the name of preserving the illusion of programmer power and control.
Unlike almost every other branch of engineering, software has no accreditation standands or process. Totally unlike, say, those civil engineers who built and designed the bridges we're using as a comparison. You'll notice that the vast majority of those don't fall down after a day's use.
Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
Sure, let's have liability. The software must perform substantially as advertised - counting all advertisements, press releases, interviews given by publisher's officers, etc.. But make the amount of damages simply equal the price paid.
This would keep free-as-in-beer software in the clear. It would also have the side benefit of forcing Microsoft to reveal its OEM prices. :D
I like the source code as condition of immunity suggestion above too, but it would be futile without a licence like those the FSF approves, which would actually allow you to fix problems without violating copyrights and patents.
Bugs and security holes can be as simple as a typo - e.g. if (uid = 0) { instead of if (uid == 0) {.
Now imagine that the BBC could get sued for every typo that made its way into their news articles. Sounds unappealing? That's essentially the standard this clown is holding software developers to.
Bogtha Bogtha Bogtha
Everyone knew that the Earth was the center of the universe.
Mea navis aericumbens anguillis abundat
You realize what you said is true, circular and bad news for commercial software, don't you?
What you call "tripe" is what the author wanted to get done and what no commercial software vendor would provide. Score one for free software - meeting user needs.
The "popular" projects do indeed rock and will be better than anything commercial because no firm can match the development effort. Look at the gnu debugger. The last time I checked it had more than 87 authors. Show me a commercial debugger that gets that much attention. That's just one of the thousands of gnu projects that make free software actually work. Score two for free software - in the end, what needs to get done gets done better.
Finally, you are half right about peer review only working on projects that other people care about. If you can't find a single other person in the world interested in your project you have a rare project indeed and won't find any help. Most people are not so original and will usually find dozens of projects that do something very close to what they want to do. So far, so good, where did you go wrong? When you turned a blind eye to the most popular non free software getting no such help at all. For all your customers can tell it was written by a lone monkey paid in bananas who was forbidden contact with the rest of the world. Final score - free software 3, commercial software zero.
This message composed and transmitted on a system run with complete tripe that just happens to have more features and run much better than any commercial software available.
Friends don't help friends install M$ junk.
Happened to me once as well (regular burgers, but what's the difference). Gaaahh! I smell a class-action suit - sign me up!
Um. I do. frequently.
And while yes, the majority of users aren't going to do that, the fact that it is open source enormously simplifies life for those of us who can.
Under windows I'd just restart it. Maybe reboot.
Under linux I fire up gdb, try to get a stack trace, poke through the code a bit and e-mail the authour a patch.
Just because some people don't doesn't mean open source doesn't get a huge win from those who do.
And I've talked many a user through recompiling in debug mode and providing a stack trace at least.
-- perl -e'print pack"H*","6e656d6f406d38792e6f7267"'
It it is interesting all the comparisons being made to physical deivces, such as Cars and iPods. But there are two major differences I see with this:
Most often companies provide software upgrades that may fix the problems the consumer is having (analogous to the real-world physical replacement of a product). So in some regards I think software companies are already doing this.
The problem I see comes in with the lack of accountability in regards to taking returns or providing refunds to those truly disatisfied that don't want a replacement.
As an oldie that started programming on tab equipment, IBM 1401's, 360's, Bendix G15's, Nova's, and a number of other long obsolete architectures, the problem is the unconstrained growth of nearly every application. Not just by the size of the application, but the minimum environment to just run "Hello World" in a GUI window.
.dll or .so, and you have the perfect example of being able to ship tested code, that since it is NOT statically linked, is very likely not to match field systems after the first "critical" OS update chasing bugs, security flaws, and creaping featurism. You can code around bugs, and sometimes accept them with statically linked code ... that becomes impossible with a dynamic library environment.
... and that is unmanagable complexity and the resulting quality issues.
Even if a software developer can get an application thru a GOOD Alpha and Beta test, the OS platform will change under it before or just after it goes to market. 30 years ago, when you targeted a vendors OS platform, the critical design concern was forward compatability and portability HAD to be perserved. Today the interactions are so complex, that isn't even an achievable design goal, even though some people try.
An interesting quote from the 1970's was a well known authors pride in the most difficult problem in managing the feature set of his compiler, was keeping all the good, but unnecessary cruft out. Today, software seldom has controlled complexity management, but rather not only is the kitchen sink tossed in to expand the side by side feature comparison set, but every kitchen sink on the planet. With this kind of pathing and feature competition, complexity spirals out of control, and the ability to regression test effectively is eliminated by the N to the Nth interaction matrix between features.
Add to that, the problem of library complexity, where everything is a
Many difficult to debug code paths are the side effects of resource allocation issues/failures, which do not even show up until the system environment grows on certain platforms to trigger those issues, even though the applicaiton may have been stable on the platform for 5 years.
RedHat is trying to manage the problem, by forking Linux into a stable release path that doesn't have then entire OS and tool chain changing radically every 3-6 months. And avoid forcing applications developers from rolling new releases every 3-6 months as well. Many custom appliations, and the cost to maintain inhouse software, is driven by this instability of release migration. Even if you manage to stay on a particular MSWin or Linux release for several years to manage this cost, it comes back to bite you in that the migration inbetween gets so large that new off the self software will not support the 2 year old platform, and the coding changes to bring custom software forward and excessive.
There is a cost, a huge cost in rapid evolution
I thought about this the other day, asking myself why we can't have the same approach in software development as bridge building, or other engineering disciplines. The difference seems to be that of prototypes. When you build a bridge you create a prototype, test it as much as possible, tweak it where necessary and let the cycle continue until there is a working solution. Once that is done you are ready to build the bridge, based on specifications that in a certain sense are easier to follow than what software does.
Look at software and ask yourself where that prototype is, that can tweaked reworked until all obvious and so obvious issues have been tested for? You will end up noticing that the prototype and the final product is the same thing. While a bridge can be tested based on a number of complex mathematical formula, I am not so sure that software can be tested in the same way. Software is designed and developed based on a number of philosophies and sometimes these even have to interface with other programs based on other philosophies. Over time the complexity grows to a point where testing it 100% is like trying to predict what the stock market is going to do next week. I would like to give a figure to what we are able to predict, but that I will leave that for someone else, since I am not sure I am qualified to do so.
At the same time I will say that there are a good number of things for which you can create unit tests for and these help avoid the most obvious issues. The non-obvious issues, based on difficult to reproduce scenarios, variable dependencies are a little trickier.
Things are also improving thanks to libraries that implement much in the way of reusable code, but here too there is an issue. Imagine that you designed your program to be dependent on libraries x, y and z, and then the user adds libraries that effect the libraries you depend on, how can you predict what is going to happen?
You will notice that most mission critical systems are designed to have only the most essential features (as compared to desktop software) and are often coded with very precise memory management and sometimes even avoid the pointer type and instead using only primitives. Trying to develop most applications this way would be long and laborious and your users would be complaining that his complex office software doesn't do what (s)he wants (remember they can't agree on what they want), even if it is 99.999% stable.
I am not saying it is impossible, its just that I have yet to see an approach that is 100% effective and for 100% of cases. Yes I am a software developer, so I do have a certain bias.
Jumpstart the tartan drive.
An article in which a BBC correspondent wrote an article? What was that article about, someone else writing another article?
If you want "durable" software, look no further than
:).
1) mil-spec or life-depends-on-it software like medical devices, nuclear power plants, or aircraft or automobile control systems
2) embedded systems where throwing in a million features and tying it nicely in a bow is NOT what the customer wants.
Note that most of #1 are also #2.
AFAIK the embedded computer in my VCR has never crashed, never needed an upgrade, and never caught a virus. Until a few years ago when they stopped becoming single-function systems, neither did the computers embedded in cell phones. Of course, not being able to run user-installed programs helps
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
I believe we should be doing more to prevent ignorant twits from misguiding people's perceptions about software development. If the BBC has any editorial judgement at all, they should stop giving ignoramuses a podium. Unless they are intentionally trying to start a flamewar, which would, perhaps, drive up ratings. They can count this occasional reader out for a while, though.
I guess not, this is slashdot, what a stupid question.... :)
Arash
Arash Partow's Philosophy: Be a person who knows what they don't know, and not a person who doesn't know.
The BBC correspondent writes as though software quality and proper construction were at issue. The problem is not however such, but is that deliberate attacks are being made, and where defenses against such attacks are inadequate, the attacks succeed. The odds of a buffer overflow causing trouble when random inputs are present are astronomical against anything but crashes arising, for example. Therefore software can be, and generally is, designed so that such crashes produce harmless results. A deliberate attack however produces results that statistically "cannot happen". If we were building bridges or office buildings the situation would be like designing so that max observable floods, winds, earthquakes, do no harm, but having the structure fail because someone fires artillery shells at its supporting members. Nobody blames civil engineers when this happens; they blame whoever fired the shells. The best that can be done is akin to designing fortresses. This is an art, changing with time, and offers few to no guarantees; nor has it ever been able to, because the events which must be defended against cannot be statistically predicted (and mostly cannot be otherwise predicted). Yes, designers can design good fortresses which resist most attacks of a given era, and we can build software which resists most attacks. A few OSs out there have earned reputations for doing so (Multics, VMS, MVS, OS/400...) and all but the first still run on current iron. Programs generally, though, are still very hard to design to be proof against attacks, and few places can sustain a culture of paranoia needed to secure the OSs. I too have written and given away scores of programs, and write them to be used with proper care, and generally do not claim they function in hostile environments. The law should recognize that when attacks are done deliberately, the attacker is responsible, and the software author is not unless he has done an attack. At most software authors (esp. corporate) should avoid charges of fraud by making it clear what they can protect against, so that those who want to use houses of straw can ensure they put them up in areas where no big bad wolves live. Buyers however should refuse to buy such software unless they know they can use it safely, and machine vendors who sell pre-installed "straw house" software and anyone who makes it difficult to get machines without it installed, should be liable for whatever damages occur due to their making it less likely that buyers will exercise proper caution.
As a programmer, my task is to create a software product, idealy without bugs.
I can easily create simple, small, concise and streamlined software quickly without any bugs. The problem is, except for skilled computer users, the average person would not like the software I write.
So, I have to dumb down the software and make it idiot proof. I have to start second guesing the needs of the end user (because no two people expect the software to do the same things), start ensuring they don't enter data out of range (i.e. second guess the data they enter), and all the time guide them down a path that won't let them shoot themselves in the foot because they started using the software without reading the manual or even the readme file.
Making software idiot proof increases its complexity 100-fold, even more. Take this example:
Goal: To write a simple program that ask the user to enter a value from 0 to 100.
Error proof version: dialog with edit box and a text box "Enter a value from 0 to 100".
First user complaint, they can enter a value of "abc" instead of a numeric value from 0 to 100 like they were asked. Add logic to accept only numeric values.
Second complaint, user can enter 101 or -45 or 2.34. Add logic to ensure values are between 0 to 100 like they were asked and change text to imply integer values.
Third complaint, user finds typing the numbers in the edit box too complicated or repetitive, add UI and logic to support an up/down button or even add buttons with numbers on them.
Fourth complaint, user wants to quickly enter values previously entered, so add a history drop down button that stores previous entered values and the supporting logic to store, retrieve and select those values.
Fifth complaint, add a help button to explain that values can include the values 0 and 100 and any integer value between and a link to a website for support groups to let users complaing and b*tch about what they like and don't like about this dialog.
Now, make this dialog work in ALL languages in ALL versions of operating systems. Make the control accessible for the visually and hearing impaired (add voice control and audio feedback and make a high contrast large font version). Make sure some hacker can't corrput the program by entereing invalid data potentially causing a buffer overrun and thus create a security hole.
Finally beta test the software for a year and scratch your head over all the situations you couldn't predict in a million years over how users find ways to turn this simple task into the most complicated routine.
Yeah, software developers can make software error free, but then, BBC journalists would have to go back to using quills and ink because they wouldn't understand how to use feature rich, powerful, easy to use and robust software filled with redundant logic so that the end users CAN simpy use the software, even if it crashes or does something unexpected once in a while.
I haven't thought of anything clever to put here, but then again most of you haven't either.
It makes me wonder why no insurance companies offer insurance against loss via bad software. House insurance is dependant on suitable locks and security. Software insurance could be made available on the condition that suitable AV/Spyware/Firewall software was installed and patched.
I am a free slashdotter. I will not be modded, blogged, DRM'd, patented, podcasted or RFID'd. My life is my own.
There was a time when cars could be designed by 1 person, or a handful on engineers. Nowadays there are a handfull of companies in the world who can afford the billions of dollars it takes to bring a car to market. Although with computers, simulators, robotic controlled milling machines, and off-the-shelf parts, it should be easier than ever to design and build cars, the laws and liability are so strict and the cost of cars are so high that anything less than GM, Toyota, Ford, BMW, can afford to make cars (and actually, looking at the bottom line of a lot of auto companies, even GM and some other companies can't make a profit designing cars).
So all you people who enjoy working on free software, or have dreams of starting your own software company, give it up! The big corporations on the right love government regulation and liability because it squashes little companies, and the socialists on the left love government regulation and liability because it squashes all capitalists but the biggest corporations. When you got these two working together for the same goals, there is no way that things will ever stay as free as they are now.
One day we will all talk about the "good ol' days" when a person was allowed to write a program without a licence, and when there was more than 3 companies that wrote software... And our kids will learn in their schools the horror stories about the days before software was regulated by the government, and hate anyone who would want to bring back that "nightmare".
I can agree that software should be less buggy, however there are many factors influencing bugginess, from hardware issues to motivation to generate repeat sales (upgrades).
...... What will it be called should the public ever take a stand for their fair rights?
There is a way to fix this industry wide problem howver the solution direction is not compatable with the current methodology of repeat sales and support for a dollar price.
I recall some research that dealt with why the Mac wasn't a bigger success and the reason is that its simpler to use than the typicaly windows PC. As such it requires less service and support and this equates to causing less money to flow in the service and support industry.
Bugginess in software follows the logic of why not to fix it...
Licensings is another issue all together.... there is no fair way that many licenses read.... you give us your first born and we are not responsible for any bugs that kill the rest of your family....
If a software producer is not going to take responsibility for their product then as far as I'm concerned they have no rights to impose upon me any restrictions that prevent me from fixing their product so I can use it without damage... and that includes getting the help of others outside of them to fix it.
It is this that contributes to my support of free open source software.
I understand he difficulty of making sure your software works in the endless hardware and software configurations, Likewise software producers must understand our RIGHTS as Consumers to be allowed to fix it, outside of them.
Proprietary software without responsibility is intentionally a double standard and the courts really should recognize this.
But considering the US courts don't understand the unpatentable nature fo software and never ever consulted the public on the..... there is certainly breading grounds for dishonesty and double standards.
Boston tea party.... for software
He keeps insisting that software can be made to be almost perfect, yet backs his arguments up with absolutely nothing. Where's the proof? examples? What about realistic estimates of how much this will cost compared to present software development?
This whole 'guaranteed software' thing seems like a troll to restrict or get rid of open source software. Its a bit like software patents in that its pushed by big software companies because they know that it will mean that nobody can develop software without a multi-million dollar law-suit fund to back them up. There's no doubt many lawyers salivate at the idea of being able to successfuly sue someone for the simple act of producing a piece of software.
Also the car analogy is a fallacy. Cars sold to consumers are heavily regulated because if something goes wrong it will likely kill or seriously injure someone. If something goes wrong with consumer computer equipment its simply a matter of inconvenience - 'oh shit I lost my essay, I'll have to write it again' and often the consumer contributed to the problem by not using the computer properly, eg. 'maybe I should have saved my essay sometime in the last 4 hours'. At no time is life, limb or property in danger from a crashing PC.
Computers used in important tasks (eg. hospitals, nuclear plants etc.) are a different matter and are treated differently. They can pay the big bucks required for an integrated, well tested, reliable system
Pre-canned Evolution Links for all those Slashdot holy wars.
Yes bugless software is possible. It requires more testing, which requires more money. It's a simple economic decision:
Is the additional cost of reliability less than or equal to the decrease in the mean rate of failure multiplied by the average cost of failure
If you cannot keep politics out of your moderation remove yourself from the Mod Lottery.. NOW!
Things are getting better, we are just happen to be using the software as it is being perfected, rather than wait for "everything to be perfect" before going to market (an impossible situation).
I don't make predictions, and I never will.
In every other business "experience", part of that "learning process" is covering your product with a minimal warranty, not a "nothing is my fault, take it or leave it, suckah" scene EULA like you get with software. This is the only industry that pushes a product that gets this totally free skate on quality. In essence you are saying that you can't offer even the bare minimum warranty a blender manufacturer offers, yet it's "professional".
People "in the industry" really can't see what joe consumers (dude in the article in this case, but call it joe consumers) are saying? Or People "in the industry" don't want to see that?
Give it away for free, share the source, swell, call it perpetual beta ware, slap that "it ain't my problem, it's YOURS" EULA on it. But sell it, err excuse me "license it to use", and you should have a minimal warranty of some kind, by law if not by volunteering one because you stand behind your product with more than soothing words and a shrug.
We got rid of "caveat emptor" in the pharmecutical industry when 99% of the medicines on the market were snakeoil, and they survived just *fine*, so maybe it's time to do the same with software products, products that the multi hundred billion a year industry receives *patents* on. Patents! Software is a mature industry now, it doesn't need the hand holding and training wheels like it needed when it first started out half a century ago.
Less releases of better quality? HELL YA! Sign me up! Cost more? Probably! Who cares? Would the end user be forced into buying the same thing over and over and over and over and over and over again if what they bought in the first place worked much better? Most likely! So in that case it would long run be cheaper. Less headaches for the end users, the customers? More than likely, things go smooth when stuff "just works". Better for society, economically and socially? Judgement call, but seems like it's worked for about every other industry, so...
No problem! Anyone can write errorless code if only they are careful.
#include <stdlib.h>
int main() {
printf ("Hello world\n")
}
No problem! Anyone can do it!
What? ®
"Doing it will probably mean that commercially-available code is more expensive and cause major problems for free and open source software developers."
If commercial software was well-coded, a lot of open-source software would never have been developed.
The article didn't really offer any plausible solutions, or for that matter, didn't really articulate the problem very well either. The author's writing style is a little whiny.
Bug free software is possible, so long as it is done right and people are prepared to pay for it.
It is impossible to guarantee the reliability of complex algorithmic software. This is something that Frederick P. Brooks has shown in his famous "No Silver Bullet" paper. However, Brooks' arguments fall apart in one important area. Although Brooks' conclusion is correct as far as the unreliability of complex algorithmic software is concerned, it is correct for the wrong reason. Software programs are unreliable not because they are complex (Brooks' conclusion), but because they are algorithmic in nature.
Last week, an article in the Wall Street Journal's OnLine Edition gave a vivid description of the costly software reliability problems that Microsoft has had to endure in its effort to develop the next version of its Windows operating system. It drove home a point that I have repeatedly made in the past. The biggest problem with software is communication. I am not talking about the lack of communication between programmers (nothing can really be done about that since programmers come and go) but about communication between various parts of the software. Microsoft is suffering from a classic case of the "right hand not knowing what the left hand is doing" syndrome.
The problem has to do with what I call blind code and it is not just Microsoft's problem. It is an old problem that has plagued the entire software development industry from the beginning. It is proportional to complexity but it does not have to be. In fact, it can be completely eliminated. The solution requires a rethinking of software construction, not only at the single program level but also at the operating system level. It calls for the reinvention of computing at the fundamental level. We must abandon the algorithmic model of software construction and embrace a signal-based, synchronous model. Eventually, even basic microprocessor architecture will have to be overhauled. For more on this important subject, see the link below.
But I still believe that the current situation is unsustainable, and that we should be working harder to improve the quality of the code out there.
This is a very different thing that legislating mandatory guarantees on software. Yes, we SHOULD be working harder to improve the quality of our code. But not at the price of authoritarian government.
There are few things in life that are truly a free market, but software comes close. It's no surprise then that spoilsports want to come in and regulate it. That happens wherever freedom begins to bloom. Let me clue you in: the marketplace has decided on a low (as in almost non-existant) demand for guarantees and warranties on consumer software. It's not developers doing this, it's the users.
A Government Is a Body of People, Usually Notably Ungoverned
The problem is as old as Lady Ada Lovelace who wrote the first algorithmic code more than 150 years ago. We've been writing algorithmic programs ever since and the ensuing unreliability problem has turned to a major crisis. The problem is not software. The problem is algorithmic software. Switch to a non-algorithmic, signal-based, synchronous model and the problem will disappear.
Sure, my software comes with a 100% lifetime warrantee. Note: Installing any software BUT mine, or using anything but a stripped-down bare-bones OS voids the warrantee.
The hugeass elephant in the room here is that for centuries builders have been relying on reusable components and clear standards, while massive numbers of programmers shun these despite their availability, and constantly reinvent the wheel. I'm looking directly at every dink on Slashdot that bitches XML is too complicated and trashes (ha!) on automatic garbage collection. (if someone has some obscure exception, keep it to yourself. The exception isn't the rule.)
Another difference is, typically if an engineer says something is unsafe, people actually fucking listen to her.
Oh yeah, and you can't hide how a bridge works. Proprietary code encourages cut corners.
I believe that good software is attainable. But that won't necessarily come from legislation, it'll come from the industry growing up.
That's right, the regulations and such are important for cars because otherwise, the cars will end up killing lots and lots of people.
Most software isn't like that. If a web browser crashes every five minutes, I'm still breathing. Even if some crappy software causes all my credit card information to be spread all over the Internet, I'm still breathing.
Of course, there are some critical types of software, running power plants and rockets and such, for which failure means human death. And hey, those have super-robust development processes and regulations and guarantees.
A newswriter tells software should be more reliable, and so many posts here jump on him with defensive rants.
It's not a commercial vs open source thing. Most software is crap. But crappy commercial software generally doesn't stay around very long. Open Source software, OTOH, gets uploaded to Sourceforge and never goes away. (actually, SF seems to be a graveyard for quite a few failed commercial projects too)
I personally have one bit of software that I'm getting ready to retire, after 7 years of working just good enough. It's stability problems were all the fault of Windows' spooler.exe, really....
It is amazing what you can accomplish if you do not care who gets the credit. -- Harry Truman
On the other side, just by picking another example than Word, I must agree with you: The market wants cheap, buggy software with the last pretty zooooming feature more than all the rest. See the popularity of LaTeX.
The last time I checked it had more than 87 authors. Show me a commercial debugger that gets that much attention
Oh no! The broth is about to spoil! Quick add more cooks!!!
These posts express my own personal views, not those of my employer
We know how to write bug-free software. It's a very rigid process that sacrifices time, money, and functionality for dependability. Well, raise your hand if you want to pay $20,000 for a stripped version of MS Office.
Note also this raises the barrier for entry in a business with high barriers already. Who's gonna invest in a software company that could get sued out of business in a couple of weeks? Only a company with deep pockets and a take-no-prisoners legal team could possibly cope in that environment.
I suspect if they actually went through with that the government would end up releasing software so people could do their jobs. Not because the quality was higher, but simply because the government would exempt itself from lawsuits.
Computer software has been mostly unregulated. This has allowed us to watch the "invisible hand" of the market in its purest form. Commodity programs have disclaimers, buy bespoke and you get guarantees, pay yet more and you get formally certified code. The cost of risk and the cost of the program are in effect two seperate purchases - product and insurance.
If you force programmers to carry the risk cost, you don't magically get bugfree code. You just delete the no-guarantees market. In effect you're forcing programmers to bundle insurance with every installation. "Free" disappears. "Libre" might survive in an attenuated form - edit "open source" and you become the liability carrier. You might do it in house, but few could afford to publish.
The guy points out that other industry sectors have this sort of law. Yup, they do, and I contend we're all worse off as a result. Amateurs are frozen out, because they can't afford to jump insurance hoops. Innovations are stifled. Saleable skills are wasted. Personal self-expression is denied. Even though all parties are willing, the law stands in between saying "no". This is nothing to emulate!
Nanny liberals would contend they are protecting buyers from risk. As an adult you have to accept that the universe has dangers. You can't wish it safe, and the utopia of your childhood was an illusion. Who then is best placed to decide when you should gamble and when hedge? Philosophically, no action can be said to be "better" or "worse" without a reference to a person whose goals it serves or thwarts. No person can know another's mind. Therefore, you alone are properly placed to weigh the options and decide on your own behalf. At best a law commands you to take your best choice. At worst, bans it. Neutral or harmful, and (given diversity) certain to be harmful to some. This is why regulation is never better than a free market, even in risk.
Look at the gnu debugger. The last time I checked it had more than 87 authors. Show me a commercial debugger that gets that much attention.
Let's see, the only commercial debugger worth talking about is Visual Studio. Microsoft definitely has more than 87 people working on it. Oh, and those are full-timers whose only responsibility is Visual Studio.
Score two for free software - in the end, what needs to get done gets done better.
Considering the market share of Visual Studio, I think you picked a bad example to score points on.
First, of all, there is, so far as I can tell, there exist no non-tivial programs that are free from error. Indeed, there are no non-trivial programs sufficiently well-specified so that one can objectively discern whether there in fact exists an error. Even if I am wrong on these points, the outlier examples are so far, narrow and expensive as to be pointless -- nobdoy wants to pay what it costs to specify, design and impelment demonstrably correct code.
Given that code is buggy, all the law and market should do is efficiently and effectively allocate the risk and costs of error. The commercial law is, quite frankly, pretty good at this sort of thing.
Let the market decide how tolerant it will be about receiving buggy software. Let each business decide for itself how carefully it should produce code, so long as they are not fraudulent or misleading in selling their programs.
Let the market decide how much risk it is willing to accept for the consequences of the unavoidable reality of computer program error. If substantial conformity with documentation is enough -- almost certainly true for most consumer applications -- then let the market decide it doesn't want to pay for more.
Let the market decide how much of that risk it is willing to deal with -- what remedy do they want? Repair or replacement? Or money back? or more? If a party is willing to accept reaosnable efforts to repair followed by refund, a vendor is going to provide software for cheaper than if it were liable for consequential remedies.
Yes, we could pass laws to interfere with market forces. But would that be better or worse than the status quo?
Giving all your possessions, money, and yourselves to me: http://zod2008.com/
Took a break from trolling to jack that karma up?
That's exactly what I'm talking about in my post up above, where I suggest a self-rating system of this nature:
Software publishers could claim a reliability rating of 1 through 5, and price their product accordingly -- but the higher the rating claimed, the greater their liability if it doesn't live up to their claims for it (from minimal for "1", up to total for "5").
Under my proposed system, a rating of "0" is reserved for "no liability". Anyone could use this, but it is specifically to protect FOSS from all liability, without making any statement about its actual quality (that's where peer review would be important).
Most consumer software would self-rate at 1 or 2, be priced accordingly, and life would go on much as it does today, but consumers would be informed right up front that the product they're buying is known to have issues. "Better" consumer software might rate 3. Enterprise and mission-critical apps would rate 4 or 5.
~REZ~ #43301. Who'd fake being me anyway?
Wrong. If this were true, no one would be finding bugs and vulnerabilities in Firefox (for example) without even having to look at the code. OS/390 (for example) would be the most broken-into operating system in the world. This is a convenient legend, but it's ultimately false because it generalizes way too much. Stop repeating it.
Free software is in many ways better than commercial, but it's not a blanket applies-in-all-cases mantra. Arguing otherwise is the mark of the true ideologue that can't see past his cherished but flawed beliefs.
My car is way buggier than my software. My car is horrible at dealing with unexpected siutations and abuse. If someone attacks it, say by breaking a window, the window is broken and I have to pay to have it fixed. With software, I get mad and demand that they should fix the bug so the attack CAN'T break it. Likewise the car is not forgiging to unexpected operation. If I floor the gas in neutral, the engine will seize up. However I expect that software can deal with unexpected input and not have any ill effects. Also my car costs money for matenance. I have to regularly pay for things like oil to keep it working, however software I expect updates at no charge.
So all in all it seems I expect MORE out of my software than my car.
They are different things, you really can't compare them.
Pure Poppycock!
In that case I'm sure NASA would be very interested in being told where the bugs in the Shuttle's control software is situated.
http://www.fastcompany.com/online/06/writestuff.ht ml
It's all down to economics and greed. With $50,000,000,000.00 in the bank Microsoft have the money to do the job properly, but without legislation they are not going to spend any of it to perfect their product.
Doing it will probably mean that commercially-available code is more expensive and cause major problems for free and open source software developers.
This statement brought about an interesting thought when I read it:
What if that was the stipulation of the license for commercial software?
Only someone giving their software away for free or developing it under an Open Source licence can be non-liable for their software. After all, if you're going to charge for your software, the buyer should have some assurances it wont cause a catastrophic disaster on their system. But if it's free, you're just doing this (particular piece of software) as a hobby obviously, so your software shouldn't be held to such high standards. If your software is open source, an individual is free to go through the code and make sure there aren't any bugs before they use it, so it's their fault if you didn't verify it beforehand.
Note: I realize some may find that last statement a little harsh, and I don't agree with it personally, but it seems to fit in nicely with the OSS responsability mantra that if a bug is there and you want it fixed bad, or there's a feature you want and you're complaining, you should just code it yourself or shut up.
What would happen to the software landscape with a system like this? Would the price of software skyrocket? Would we see the bar for what kinds of software are actually sold rather than given away be raised? I think it would result in a lot for software being done under OSS, and more companies using support services for their software as a business model, rather than the software sales themselves.
There is the matter of efficiently taking a specification and implementing it. Very few people are actually any good at this, often because it isn't taught. You're taught either how to write code effectively, OR how to write it well, almost never how to write effective code well. This isn't because of the methodology - Z isn't dependent on how you write something, or what you write it in - it is because nobody really believes in the value of being able to be both effective and correct.
How would you turn Z into something compact and fast? Very easily - by not starting with the Z. You use the Z to build test cases, then implement code totally independently of the Z that complies with those test cases. Writing code directly from a specification is sloppy and does lead to very poor-quality code, but writing indirectly will produce very high-quality code that is provably correct.
Ok, so how many people know Z? Very very few - again, because nobody thinks it worth the effort of teaching or learning. And those who do know it, know it very badly as a rule.
Re-engineering of software is the only place software could be considered different from other forms of engineering. It is hard to re-engineer a bridge or a tower block, but it is actually quite easy to reverse-engineer what the specifications SHOULD have been and, from those, deduce what the test cases SHOULD be, and from those, deduce where the deviations from what was intended have occurred.
Could you do this with Linux? Oh, certainly, although that is now so large and complex, it would take a substantial team a long time to work through. But it is possible. You'd specify what the components were intended to do, then use either User-Mode Linux or the various conformance testing packages that exist to verify that the kernel did indeed do what was expected.
(The conformance testers will tell you if the I/O matches what is expected, by the specification. UML gives you the chance to do module testing and to develop test harnesses to verify the correctness of internal operations. All very feasible, just not something that is being done.)
"But Linus said..." Yeah, what Linus said about specifications involved implementing directly from them. And I've already said that's a bad idea. I have seen nothing to suggest he'd be averse to people using specifications to trap errors and eliminate bugs, which is where they SHOULD be used.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
"most" free software is complete and utter crap. "most" free software never gets past version .00000001. "most" free software doesn't get reviewed by very many eyes at all.
some free software projects are certainly of much better quality and get massive peer review, but that number is pretty small compared to the vast sea of crap free software out there that doesn't.
Freshmeat lists nearly 70,000 projects. You can't possibly believe that "most" of those are of even moderate quality, or that "most" of them get any real peer review.
Even if we accepted your inaccurate tautology, it wouldn't change the fact that having "fewer" bugs wouldn't make you any less liable. All it takes is one to put you in financial ruin if such liability were required. Simply put, no open source developer could afford to write code, much like no unlicensed and uninsured doctor can afford to practice medicine.
If you need web hosting, you could do worse than here
Look, while I recognize that it would be nice to put a boot up most vendors' behinds to write less buggy code, imposing product liability -- with its standard of perfection -- would simply bankrupt all private software companies. If you haven't read this article about the best software currently written, you should.
t ml
http://www.fastcompany.com/online/06/writestuff.h
It's written about a small company that writes the software to run the space shuttle. They do it amazingly well -- their 420 KLOC program has had only one error each for the last three versions. However, this is the work of TWO HUNDRED AND SIXTY people. It takes that many people and they still have bugs! Not many, but some. This quantity of effort simply doesn't scale to current requirements for commercial code -- we ask programs to do so many things that they simply can't possibly be done with such a small program. Hell, I'd bet winamp is bigger than that, and all it does is play music files. If we impose this sort of requirements on software, we'll be jumping back to the 80s.
earl
Hi -
I was saying this 20 years ago - if an orgainization claims something like "Software will always have bugs" then it ends up becoming a self-fulfilling prophecy. There is little motive to eliminate defects.
Have people already forgotten the book "Quality Is Free" that suggests doing something correctly the first time is actually cheaper in the long run?
The American quarterly earnings obession forces mass market software to be released as early as possible, with a focus on a total number of features.
TWR
So why not get liability insurance? This article is not an attack on FOSS anyway it's an attack on the incompetent commercial sector who have zero excuse for the poor quality of their code.
Does a Christian soccer team even need a goalkeeper?
It's kind of like the BBC story, of the guy who got arrested for using an open wireless connection. There was no mention of the moron who left his wireless connection open - probably without a clue as to what he was doing. If you have a gas cooker and blow your house up - it's your own fault. If you're going to use technology, you should know how to use it and what you're doing. If I provide a disclaimer, you should be doubly sure that you really want to install my software. If not, go out and buy an off the shelf product from a software house which accepts liability for any cock-ups.
The journalist had worked in software for seven years. Perhaps the reason he quit development is because he couldn't bare the reality of the fact that complex software implies bugs. You're not going to get around them by clicking your heals together and taking the twister to court. It's a consequence of humans writing complex software which has to run in dynamic and differing environments.
The issue is that consumers want features that are not advertised: up front reliability and security. And most people don't understand software development enough to know why those are features that cost extra. It is the up front part that is difficult. Software companies as a rule are good about releasing patches where reliability and security are concerned, but only after the fact. Keeping current requires a higher level of vigilance than most consumers desire. However, most people also don't want to pay extra for something they perceive they are getting for free if they just keep up to date with the patches.
Highly reliable and secure software does exist; it is just out of the price range of the average consumer. Consider basic instant messaging software. Now consider the same basic requirements, but used to communicate orders to a military aircraft. What would you do differently in the software engineering and development process? How much more do you think it would cost to develop? How many people using AIM would be willing to pay what the military pays?
This space intentionally left blank.
Lets back up a couple years. Would productivity be lost if a typewriter jammed, eating the page it was working on? Is the typewriter manufacturer liable for lost man hours and that sheet of paper? Would the typewriter manufacturer be responsible if their machine was too heavy for a glass desk and caused an injury when it broke through? What would be the effects of misplacing a physical file folder in the legal department? Is the manufacturer of the file cabinets in that department liable for any damages encurred by losing an important notarized document? If there are file cabinets from different manufacturers in the same room, which one carries the liability, the one where the file was supposed to be or the one that the file ended up going to? How about if the reciever switch in your telephone fails? Is the company that manufactured that liable for business lost due to predicted earnings based on calls that might have been recieved on that phone? Software liability doesn't make sense. Machines fail, they get placed in situations that the designers wouldn't normally think of, they are faced with sometimes truely absurd user errors, and they are sometimes run by themselves in situations where redundancy would be appropriate. Why should we hold consumer software to a higher standard than any other piece of typical office equipment? A desktop application is not a bridge or a skyscraper, it's a tool. And as a tool it need only be safe enough to prevent reasonable paths of personal injury to its users. Lost time/money is not a personal injury. We expect a typewriter to jam periodically because it has a hundred moving parts working along interfering paths. How many different discrete functions are in the source code for MS Office? How many of them are expected to work on the open document without interfering with all the other functions working on the same open document? MS Office is considerably more complex than a consumer grade typewriter. My old typewriter would jam on a whim, my student edition of office, aside from ticking me off with autoformating, has yet to eat any of the reports I've written. And I still keep those backed up (HD + thumbdrive) just in case anyway. And in some situations there is a liability issue with software. If the control software on an elevator allowed the carriage to move while the door was open, that would be a liability issue that the manufacturer/software developer would have to answer to.
My God! It's full of eval()'s.
Sure, a labeling system for liability makes sense in principle. Note that RedHat could sell RHL with a higher rating if they wanted; the point is: it's the ultimate vendor, not the creator, of the software that's responsible for any guarantees.
I question, though, whether it's practical. Many software problems are actually not bugs, they are user error. While user error are also often due to bad UI or documentation, the responsibility is shared between the vendor and the user. And many other software problems involve interactions between multiple components; when Adobe Photoshop kills your image while you are working in a plug-in, how do we determine who is responsible?
Bill seem to miss one important problem: When writing general purpose software the developer, software company or distributer has no realistic chance of evaluating the risks involved in the vast number of posible uses.
Nor have they any realistic chance of evaluating how the software will work when other software is installed on the same system. There are simply too many combinations.
Clearly, the second problem can be mitigated by developing applications such that each can run in a separate sandbox, but this is not very efficient.
It is perfectly ok for free software to disclaim any liability - if you don't want to take upon you the responsibility and cost of malfunction, don't use the software.
Commercial products could take some responsibility, but this increases costs. Are customers at all willing to pay that extra cost? I think not, look at the amount of pirate software - people do not consider software of any value at all. It is likely that if vendors take upon them more responsibility for their products costs will go up, sales go down, more pirated and less secure software will appear and we're all worse off.
Just how many do you know who have a fully legal computer with no pirated software at all? (assuming they run windows).
Fact is that the less you are willing to pay the more responsibility you must take yourself. Just like an ordinary ensurance: If you don't have it and accident happens, there's only yourself to blame.
Ofcourse, the developer should not take the lack of legal responsibility as a pillow but always do his best, as should anyone else in whatever they do.
But also, the user must take the required time to learn how to use the product correctly and safely. For driving, people are required to take a drivers licence, learn the rules of the road, take courses to stay in control on slipery roads etc.
There is no such requirement for the use of computers, even when these are connected to the internet. People just connect to the internet and ofcourse they crash! And they are not held liable when they unknowingly host a zombie or distribute a virus becuase of malconfiguration.
Take this story on securityfocus:
http://www.securityfocus.com/infocus/1848 on reducing browser privileges.
As it shows, much problems can be avoided if people use their browser with reduced privileges. Ofcourse, they shouldn't be running as administrator in the first place, but most do
of convenience and ignorance.
And what do people do when their computer starts to cause troubles? call a certisfied profesional? or call their neighbours 16 year old for help in exchange for a coke and a pizza? The last! Unlike cars, where people perfectly understand that the car must be repaired by profesionals and sent to a bianual check.
It's the consumers that define the market, and if consumers are not willing to pay for extra security, they won't get it, and they have to take the costs of any losses due to software malfunction.
If the software doesn't come without source, the user has to take its reliability on trust, and the vendor should be prepared to indemnify the user if and when it fails.
Whether or not the software is sold or given away is irrelevant.
Lol, poppycock. 99% of software companies aren't microsoft. For example, my software company builds a product and we have several known bugs that are in queue to be fixed at this very moment (part of the reason I'm up at 4am). The major limitation in my company is not having a dedicated QA role. We are working toward that now. Being a small business and having to go to market with software that is constantly in flux (user requests & regulation changes) is not possible without significant financial reserves. We chose to go the route that would allow us to enter the market the quickest with the least amount of risk to us and our customers. Our software is important but not critical. There are however errors that can be life threatening, those areas (medication related) are tested to a much higher degree than reports that have no real bearing on a persons life.
There are trade offs in every business. I build homes as well, you'd be surprised at the number of changes are made during construction due to unforseen problems. However, compared to software development they are very few indeed.
BTW Perfect to whom? One person's perfect software is another's POS.
No, it's not an attack on FOSS, but it would have the side effect of wiping out FOSS because nobody would be able to afford to give away code they're liable for.
If you need web hosting, you could do worse than here
There are people doing "zero-bug" stuff, it's just less obvious to see them.
:)
For instance, you have the guys at Airbus and Boeing, and the guys doing nuclear control, a.s.o.
And they use software development suites developped, for instance, by EsterelTechnologies (www.esterel-technologies.com) based on research from these guys (www-verimag.imag.fr).
And these are just the one doing the hardest stuff.
Then, you have the guys that are programming silicon, like in Intel, TI, etc.
One bug in your chip, and you're screwed for hundreds of millions of dollars.
Then, you have all the guys doing embedded control for devices that are hard to certify, such as medical appliances.
And so on.
If there's enough money, then the software (or what you make of it) can be guaranteed.
However, I wouldn't expect MS Office or the Linux kernel to be guaranteed any time soon.
I agree with the parent post. :)
During my PhD I worked on languages and case studies for safety-critical embedded systems.
And I can tell you that programming really critical stuff is done with very dull languages that make it difficult to add any new feature (and, as a side-effect, to add bugs). Just to make sure I got my message right: forget C++,Java,Caml, pointers, classes, exceptions (well, almost), and so on... Also, nifty algorithms are prohibited, and your nice obfuscated C code will be flushed out quite fast.
The code is reviewed all the time, and the final cost per line of working code is huge.
But they wouldn't be liable, though! If it was Open Source, they would be giving away the source code. Then it's up to the recipient to make an informed decision {possibly engaging the services of an independent third party} as to whether or not the goods are fit for purpose. Without the source code, they would not be able to make a fully informed decision, and so have to take it on faith that the vendor is being truthful. That's the crucial difference. The source code is a guarantee in its own right.
Je fume. Tu fumes. Nous fûmes!
I do not believe that we can make better code ... I think this is a human thing and not a technical problem
IT has be trying for almost 60 years now and it does not get any better. In fact it gets worse.
But what would it be worth if we had a way to more easily change applications so that fixes can be rolled out more rapidly, say before any calamity occurs ? What if we could install those fixes without the user having to reboot or even to stop the application containing the errors ? What if we can change those errors without breaking any 'version' relationship between other depending parts of the system ? Could this method perhaps do away with scheduled 'releases' and make software evolve more organically ?
Just because you give something away doesn't remove your liability.
If I give away candy with poison in it, I'm liable. If I give away copyrighted materials, I'm liable. If I give away cigarettes to minors, i'm liable. If I give away anything that causes damage to someone else, I can be held liable.
The whole point of the guys article is that *ALL* software should be legally required to be guaranteed to work correctly, whether it's given away or not. If you give away the source, and the recipient or "independant third party" deems it's not fit for purpose, then you're liable to them. What that liability is would depend on the law of course.
I'm not saying I agree with it, but you're arguing about something that would be counter to what the article is suggesting.
If you need web hosting, you could do worse than here
Anyone remember London's "Wobbly Bridge"? A bridge with a bug which cost a shed load to fix. Then, of course, there was the infamous SHM bug on Tacoma Narrows ...
The source code is a guarantee of functionality: it is an irrefutable statement of exactly what the program will and will not do if it is compiled and run on a properly-working computer. Of course it is written in a language that not everybody understands; but, to be blunt about it, that's their problem. For instance, if I writethen any sufficiently-competent Perl programmer should know that this program will not print "Hello World!" on a Saturday; and anybody else who is unsure but wants to find out anyway should engage the services of a sufficiently-competent programmer. {They might well be charged money for this service; but just because we are giving our give our source code away certainly does not mean that we shouldn't be allowed to charge money for explaining what other people's source code does to people who don't understand it.}
Je fume. Tu fumes. Nous fûmes!
I believe it was Frederick P. Brooks in his Mythical Man Month essay that says something about computer code being one of the very few human creations that, being governed by mathematics and other universal truths, can achieve perfection. However, he points out that humans themselves are not accustomed to perfection, since so few other activities require it. And so he compares the programmer to a poet, more than an artisan, whom creates real physical things (words or code on a medium) out of pure thought, and can be disciplined to attain this perfection by talent, skills, training, and experience.
Now, I grant that all this is a bit too idealistic for any commercial endeavor, but so did Brooks. He later points out in his essay that although this perfection is atteinable, it might not be practical or cost-effective, from a commercial standpoint, and so the commercial programmer must compromise between time-to-market pressures and error-free code by making sure the design itself is bullet-proof first, and utilizing his tools and skills, as well as those of his entire team, effectively.
I tend to agree with Mr. Brooks, and this is why I agree with the author of the BBC article. Perfect computer code is possible, perhaps not commercially practical, but certainly there is a much, much higher and closer standard that can be achieved than what we have right now, when every would-be computer scientist in college is brain-washed with mantras such as "bug-free code is _IMPOSSIBLE_", "there will _ALWAYS_ be bugs, so why bother", "just code it, we'll deal with defects after release". Many problems of current software are due not only to incompentence on the part of the programmers, but by lethargy or ineptitude on the part of the architects. But mostly by the drive to keep production costs low and profits high, in a disproportionate way.
I suppose this is human nature: the commoditization of art and technology. This is the same reason why we have wonderous works of engineering, that stand tall thousands of years after being built, along side with ready-made houses that crumble after a decade or two. Humans want cheap goods, and they are getting what they asked for. But nobody claims that a building or bridge that can survive at least a few centuries is "impossible" -- expensive, unsavory to stockholders, and challenging, perhaps; but very much possible. And this is the spirit of the article: that software is buggy because publishers are _cheap_; that we should endeavor to make software _better_, even if this means cost will be a bit higher; that we should stop spreading the myth that software, by its nature, is imperfect.
-dZ.
Carol vs. Ghost
I think it was Alan Cox who said that the only safe computer is one that you've unplugged from the wall, went out in the bush and dug a hole and then placed the computer in the hole burried it and then not tell anyone where it is. (maybe wrong about alan cox saying this but it sounds like something he'd say :)
Heck, new intrusion methods are being developed every single day, secure code yes, non executable stack and heap, but what about secure user? what about putting every known secuirty precaution in mind to make the flexability of your pc considerablly limited to stop the user from achiving efficent results with their computing.
Theres always a way, artificial, human or otherwise. Secure coding practices _should_ already be inplace but the reailies are programmers are paid by the hour and deadlines are needed to be met, furthermore to know every single process of making your code 100% secure would require significant upskilling for allot of programmers, pretty much taking them to school again and saying strncpy() NOT strcpy() so on and so fourth...
We seem to want cheap consumer software, just as we want cheap food, and the result is that we get security holes and bugs.
When he said bugs, did he mean in the software or in the food?
The NSA: The only part of the US government that actually listens.
"Score one for free software - meeting user needs."
Commercial software meets user needs as well. That's why people pay for it. Windows isn't a very good example, but there's lots of excellent commercial software that does exactly what people want it to do, e.g. Mathematica, Unreal Tournament. +1 for commercial.
As pointed out above, +1 for Visual Studio.
"When you turned a blind eye to the most popular non free software getting no such help at all."
Actually, that's not entirely true - the best commercial software makers will accept bug reports and fix them, will make modifications and extensions to their programs easy, and will generally not treat their customers like idiots. I'm not talking about Microsoft or Electronic Arts here. +0.25
It's a lot closer than you make out. Coexistence with commercial software is the way to go.
Additional thoughts: Some form of software liability may finally put the nail in the coffin of Creeping Featuritis, the disease that leads programs to contain an enormous number of fringe features. Perhaps time spent adding dubious features would be reallocated to assuring quality?
Liability might also encourage code resuse, given that developers would be loathe to replace a known "safe" wheel with one of their own creation (and uncertain quality.) Certified components might become a booming business.
Of course, there are a lot of "weasel words" in the thoughts above: "might" and "may" and "perhaps". I don't expect software to attain perfection; "perfect" is beyond human ability, and we need to accept that everything entails risk. But the current situation is awful, and developers should do much more to ensure the reliability and applicability of their works.
All about me
...that the author is alluding to "products liability" for software. This is lawyer talk for a concept called "strict liability". Strict liability makes you responsible for damages when your products are faulty or defective, regardless of any fault or negligence on your part. Anyone "in the stream of commence" from the manufacturer to the wholesaler to the retailer can be held liable if the product was defective and caused damages. Disclamers are usually held to be ineffective as a matter of public policy. That being said, strict liability is usually reserved for very hazardous activities such as blasting, keeping wild animals, and other ultra-hazardous activity.
So, the real question becomes, when software is used in a situation where there are extreme hazards, should EULAs be ignored and strict liabilty be found? A la using firefox at a nuclear facility which causes a meltdown?
Emacs is one of the worst examples of code bloat I've ever
seen. Who the hell decided that having an LISP interpreter
inside of a text editor was a good idea? (And you ivory
tower academic types just can put a sock on it , its NOT a
good idea. If you want LISP use a proper interpreter). If
I had asked someone to write a piece of code to carry out
a specific action and he added a load of unnecessary functionality and other rubbish into it simply for the
intellectual satisfaction and kudos then he wouldn't be
in my team for very long.
If cars are safe, as this journalist claims, (Cars are a good example here. Motor vehicles have to be safe), then why is car insurance expensive? (The average cost for auto insurance nationwide for 2005 is estimated at $870). What a moroon!
But he illustrates one point by accident. There's compulsory training to get a car license - perhaps there would be fewer computer crashes if IT training was compulsory too.
Proportionally - based off of popularity. Any software that begins getting popular *does* get the attention you speak of, and many (hopefully most) onerous bugs quickly begin to be smashed in it. Not all, no - but the biggest and worst.
Yes, most open source software out there was cooked up by one person, ten people have downloaded it and tried it. None of them looked at the code... and no one was harmed by this fact.
Have I looked at Linux kernel code? Yes. Firefox? Yes. Have I sifted through it all looking for bugs? Of course, I have 25 hours a day to do so, who doesn't?
Honestly though, there are people who have time and knowledge to look for bugs, and if you subscribed to any of the security mailing list you'd see them. The people who find symlink attacks, priviledge escalation, input sanitizing bugs - they didn't just happen to stumble over it because they clicked the 'save' button twice - they were looking over the code.
cyn, free software and *nix operating systems enthusiast.
Not until the quality of a software product out weighs the need to meet a deadline to produce it will we see this change in the industry.
I'm fairly certain there are a number of coders out there producing substandard (by their own standards) code, that they would much rather take more time to work a better solution or optimization. Constrained by a deadline though, unless you are a code god this is not humanly possible.
I am Bennett Haselton! I am Bennett Haselton!
This message composed and transmitted on a system run with complete tripe that just happens to have more features and run much better than any commercial software available. ... visual studio all the way.
Low blow, -3. I'd counterargue but the posters before me have made some pretty good arguments. And while I have used both linux dev environments and visual studio (C++ development)
-everphilski-
The problem is they have no point of reference when it comes to software.
If you buy a secondhand car for 50$ you're probably not going to complain to the previous owner if it break down after say 20000 miles. Hell, 20000 miles for 50$ is great value for money.
But if your brand new Benz, $70000 automobile, breaks down after 20000 miles, you better believe there is going to be hell to pay.
People understand value and price when it comes to cars. They don't when it comes to software. When I was in college a friend asked me if I could write a customized accounting and invoicing system for his company. When I told him "sure that will be $20000" he laughed his ass off. In the end he settled for a buggy script that added up totals from his invoices which were stored in XL files and a mail-merge type office application to generate the headers for quotes and invoices. He payed me $300 and complained about it too.
Firstly, with software patents and the DMCA and all that crap, it's possible for a company to restrict the ability of its competition to function fully (play MP3, read MSOffice formats etc). No-one is going to buy nonfunctional software so no proper competition exists.
Secondly, most people don't have the knowhow to, say, realise that whilst variants of Linux may be less user-friendly than variants of Windows, the former tends to be more stable. They just use whatever comes with the PC. Even the major executives will tend to just go with whatever the rest of the market is using. Again, no proper competition.
I think the answer is probably not legislation - that'll just inevitably shut out small developers. Rather, if I were government (perish the thought) I'd set up a certification scheme to measure the extent to which companies are willing to stand behind their products. The Debian Foundation, Ubuntu and other groups just using the GPL would get a Bronze - they don't stand behind their products, although those repackaging said products might. Microsoft would also get a bronze with their current EULA (great reading if you're ever bored). Red Hat or SuSE might approach the celebrated Gold standard - I don't know what terms they sell their services under.
Any obvious holes with this? I'm open to having the shit ripped out of it if anyone feels like it.
For the love of God, please learn to spell "ridiculous"!!!
Having read this man's column off and on for years (why, I ask myself...) I can safely say that he is a chimp and 95% of his opinion can be discounted (the 5% is solely attributable to the random-monkey-with-typewriter effect).
"'I pass the test,' she said. 'I will diminish, and go into the West, and remain Galadriel.'"
- JRR Tolkien.
Bill Thompson, the author of the original article, "worked as a commercial programmer for several years, and [has] seen how hard it is to write bullet-proof code." Now, 'several years' could be anywhere from three to five or more...but his opinion should not be dismissed as coming from a technology pundit with no real technology experience.
Other than that, I basically agree with you.
If you give away a recipe for poison, what is your liability? Would it not be the same as giving away source code?
> With a word processor this might be something like i18n issues. We might specify, design, build and test
> the thing without considering the user might not have a us-ascii character set and then it breaks in China.
When you first specified the program, i18n should have been decided. If full Unicode was a requirement then yes you had damned well better have tested it in something other than en-US, otherwise Chinese is outside the scope and if it fails it isn't a problem. And if the problem is in an input method or font renderer it also falls outside your scope.
The problem is with OO, it turns programs into nightmares of invisible interdependencies. Simple procedural code is easy to understand at the unit level and safely abstract away into libraries that export well defined interfaces. But no large project is developed this way anymore, all we get are C++ and Java horrors that never quite work and never will. They can bang away on Mozilla/Firefox for another decade and it will never get any better than IE in the bug dept because both have the same basic design defect, C++. Java & C# are only marginally better; while neither suffer from buffer overruns and pointer arithmetic they still suffer from the problem that in any non-trivial system it is beyond human understanding exactly what is happening within the running program.
A procedure can be proven, all the inputs and outputs validated and it need never be looked at again. All of the procedures that make up a complex library can be tested individually and then as larger units until an entire librart can be verified as correct and put in the deep freeze. Although admittedly many popular libraries were not totally validated, see recent security bugs in image processing libraries..... but in theory libjpeg's behaviour COULD be mathematically proven for all possible input/output streams at which point there would be no need to ever touch the code again. Classes are often prone to new bugs appearing when they are used (subclassed/inherited) in new and unexpected ways. This ability to inherit in ways the original programmer never anticipated are the selling features of OO design, but we all know it doesn't work that way in real woprld projects.
Democrat delenda est
Ok so every EULA will contain "this software may not even do what's meant for and may contain bugs" (which is essentially what they already say).
Now that the candy has the poison warning on it, is anything changed ?
If sources are enough to save OSS from liability, EULAs are even better.
That depends. You're giving away a recipe for poison. It's functioning as expected, and thus is fit for purpose. It does what it's supposed to, and thus you cannot be liable for poor workmanship.
You could still be liable in other ways. For instance, if you gave a kid a recipe for poison even after he told you he was planning to commit suicide with it.
This really isn't the issue here though. The issue is of liability if the product doesn't do what is expected of it, and what is the recourse for people who acquire the software and have it fail on them.
There is an interesting idea here though. An exemption clause for software that includes source would make it CHEAPER for corporations to supply source for their code than not. Unless you have massive amounts of money (ie, IBM, Microsoft, Oracle, etc..) and can afford monster liability insurance, it would simply be most cost effective to make your code open source.
Of course that would give the big corporations an advantage, but it would make the majority of software available to inspection.
If you need web hosting, you could do worse than here
Actually, yes. If you give away candy (Sweets.. as you call it) with poison in it, you're liable even if you mark them as such. The product is intended for consumption, and using the product as intended will cause harm.
Why do you think the Cigarette companies lost BILLIONS of dollars in lawsuits, despite clearly marking their product that it will kill you and everyone around you?
Further, the source code is no guarantee either, since it's very easy for problems to hide in plain sight, even after extensive analysis. By shifting the onus of responsibility on to the (most likely) unskilled end user, it's just a cop out, and any judge would see that.
If you need web hosting, you could do worse than here
Is this the kind of fanatical "free software" trolling that gets upmodded these days? For those who are unaware, Twitter is a well-known anti-"M$" troll.
Everyone knows that most free software, by virtue of peer review, has fewer bugs and errors than commercial code does.
No, "everyone" does not know this, and the Mozilla codebase proves you wrong. It has had more exploits lately than your arch-nemesis Internet Explorer. In your eyes, everybody is a programmer spending hours poring over line after line of source code, which never happens.
This whole issue is a troll the non free software companies come up with every few years. It's a mistake for them, however, and will blow up in their faces. Free software will overcome such nonsense the same way Good Samaritans do.
And you moderators seriously fell for this?
Yeah, the mistake will blow up in their faces, just like you've been saying for years, Twitter. Meanwhile, where is free software on the desktop again? Oh, right, non-existent.
Next.
"Sufferin' succotash."
Let me support your argument.
I know many people will say that comparing bridges and software doesn't make sense. But, let me offer this. If people want the same reliability from software they get from a bridge, then maybe they should be prepared for the same expense.
The average bridge runs many millions (if not billions) of dollars and can take 10 years or more (inception to completion) to build. Also, people will die in the construction process. And, you'll still get no guarantee of success (Tacoma Narrows anyone?). Then, bridges are usually payed for with tax money, and almost always run over time and financial budgets. (The Tacoma Narrows was conceived in 1928, construction wasn't completed until 1940, it fell down shortly after.)
I don't know about anyone else but, to me, this seems like a big price to pay to surf the web for pron without getting a virus or a browser crash.
----- If communism is a system where the government owns business, what do you call a system where business owns govern
Well this discussion is mostly dead but here goes.
.5 errors per release. And our release schedule went from one release per month to one release per 8 to 12 months. They were still paying us the same salary. The same amount of code was in each release.
What is the value of software that you do not write because you are putting so much effort into writing bug free software.
This is not an abstract question. At one company where I worked, the effort to get zero defects to production lowered our defect rate from 6 errors per release to
But a lot less defects and a lot more "control" since they knew exactly when the next release would be. But we were producing 1/8th to 1/12th the amount of code. Was it worth it? I don't know.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
We are paying several thousand dollars more per vehicle for these kinds of laws- each added on the premise that it only "costs a few dollars extra per car".
In return we save a few hundred lives a year. Who knows if other folks die because they are driving an old broken down car, or they don't have a car during an emergency so that we can save those few hundred lives.
A few hundred sounds like a lot- but we are talking about a hundred million people- in those numbers drinking water resuls in a few deaths a year.
The cost of our safety structures are making us very uncompetitive with societies who do not care if a few hundred die if it means all the rest can be more competitive. A few thousand students die (suicide) each year but you do not see them making the tests less competitive yet.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
I think this -- randomly-present allergens rather than deliberately-placed poisons -- is really more like the software situation. If we're being kind to the closed-source developers, the bugs are there by accident, not design. But even so, the closed source vendors are still effectively saying "This chocolate bar categorically does not contain any kind of nuts whatsoever and you'd better believe us, we will punish you if you try to check with a matter analyser". Because someone managed to persuade a judge that two wrongs make a right. Still, it opened up the way for the families of all those people who had been killed by gu
Any idiot can go to B&Q and buy some copper pipe, fittings, solder, flux and a blowtorch. If their self-installed pipes leak, or they manage to set their bathroom on fire, or they drip hot solder on themself
Open Source software is not necessarily free as in gratis, because you may well have to pay to get the code checked over. But that's still not a service you are ever likely to get at any price from the vendors of closed-source software; they have their own reasons for keeping their secrets which exclude all possibility of independent audit.
Je fume. Tu fumes. Nous fûmes!
- pay a software vendor for a worthless piece of paper {"This may or may not do what you wanted, and we couldn't give a flying toss one way or the other; but if you try to poke about inside it to find out, we will rip you limb from limb and feed you to the hounds"}; or
- pay a competent programmer, independent of the original authors and having nothing to lose whatever they say, to determine the suitability of a product for a particular application by inspecting the source code?
In effect, the above is already what most EULAs say anyway. It's just a matter of time before someone gets burned by closed software, tries to sue a major software vendor and calls the whole setup into question. I'm surprised it has not already happened, but maybe it has and they have been hushed up {bought off and given a stern warning not to talk about it ever againMy guess is that source code would stand up much better as a defence in court than an EULA, because source code does not actively seek to diminish your statutory rights. And if a bug is obvious to anyone in the courtroom from looking at the source, then it should have been obvious to the plaintiff or their agent in the first place.
Je fume. Tu fumes. Nous fûmes!
Geeks would call the solution "BSD"
I'm a linux user dough