Code patches and maintenance contracts 1

[sleipnir214]

The "Witty" worm, which targeted the RealSecure and BlackIce products of Internet Security Systems (ISS), hit two days after vulnerabilities were reported. The "Witty" worm is a destructive worm which writes bytes in random locations of an infected computer's hard-drive, eventually trashing the system. Around 12,000 computers were affected by this worm last week.

ISS only provided patches to those customers which had purchased maintenance agreements (

http://zdnet.com.com/2100-1105-5181825.html?tag=header.newsfeed" class="nd").

What are the ethical responsibilities a software company has to fix bugs found in the software it publishes?

Want the best answers? Ask the best questions!

TANSTAAFL!!

 

[Dimandja]

If a software vendor tells you "If you don't pay maintenance, you are not allowed to use the products any more", run away!

I have never heard of a company actually selling security patches: makes you wonder who released the worm in the first place.

I would stay away from this type of vendor.

 

[CajunCenturion]

I think all software companies have an ethical obligation to fix all known bugs, unfortunately, it's not always a legal responsibility.

The hard part is defining what is and is not a bug. Hypothetically, if a law were passed requiring all software vendors to fix all known bugs, then you're going to spend your time argueing over what constitutes a bug. The customer will define a bug as the system not doing what they want it to do which is not a workable definition under any cirsumstances. The vendor will define a bug as the system not doing what it was intended to do, which is equally to far off to one side. So how do we know what software was supposed, or reasonable expected to do? With respect to our favorite software vendor, they have no bugs, only features.

It would be fun to watch the legal eagles try to define, in legal terms, what constitutes a bug for the purposes of this hypothetical.

Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[MasterRacker]

If nothing else, this is very poor business practice. Who's going to buy a security product that doesn't patch it's own holes without an extra fee?

I can see premium support for maintenance customers, such as active notifications to them when a patch is released. All owners of the products should be able to download the patch once they find out about the need (through the news, etc.) however.

As CC says, this could be another item that could be very entertaining to watch work through the courts.


Jeff
The future is already here - it's just not widely distributed yet...

 

[sleipnir214]

Since CajunCenturion mentioned the idea of a hypothetical question, let's continue that way.

What are the limits to the ethical obligation of a vendor to fix software?

Some of the limits are easy -- for example, I don't think Honeywell has an ethical obligation to patch MULTICS any more, as the last MULTICS installation was shut down in 2000. They have no more users to support.

But does a product's being superseded by a newer product limit the obligation? Do the terms of how the new product is distributed make a difference?

Want the best answers? Ask the best questions!

TANSTAAFL!!

 

[hilfy]

What are the limits to the ethical obligation of a vendor to fix software?

I think that, at a minimum the vendor has the responsibility to notify users, either through email, or an obvious (not hidden x levels deep...) post on their web site well in advance of the cut off of support for the earlier version.

For example, my previous employer gave about 12 months notice that support for the older DOS-based version of the software was being discontinued. Of course, there was also an economic basis for this - they wanted to sell the new Windows version of the software (at a steep discount for existing customers.) However, this was not shrink-wrapped software, there was a lenghty contract process involved.

Even Micro$oft gives notice of when they will no longer support specific versions of their software.

-D

 

[SemperFiDownUnda]

I think it come down to the terms and conditions of your purchase.

If you purchase software and it claims you get free patches and upgrades then ISS would be treading on bad ground

If you purchase software and it claims you get free patches but no upgrades then ISS would still be treading on bad ground if the virus/worm effects the original code base. But if they brought out new features you would not be entitled to them

If you purchase software and there is an option to purchase a maintenance agreement for patches and upgrades and you opt out of purchasing that maintenance agreement then you wear the risk.

Its kind of like me having no pharmaceutical cover on my insurance and then complaining that I'm not covered for medicine for an illness that I get. I choose not to include pharmaceutical cover because I obviously thought the risk was low.

Yes it would be nice if ISS put out the patch but if they did that then really they have no need for a maintanence program sinse everyone would get the patches anyway. Which means this removes a pricing scheme from there products which means they need to transfer that cost back to the original purchase price which raises the cost for everyone.

If you buy something and don't understand the terms and conditions then you need to be more diligent. If you opt out of purchasing options that you find yourself in need of at a later date then you have no one to blame but yourself.

Hope I've been helpful,
Wayne Francis

If you want to get the best response to a question, please check out FAQ222-2244 first

 

[misterhux]

Even Micro$oft gives notice of when they will no longer support specific versions of their software.

and even if they don't "offically" support it (I'm talking about OS's here) they still test all there new software to see that it plays nice with their old OS's

 

[MDXer]

I fail to see how this is any different than letting you subscription to Symantec expire. If I use Norton Antivirus and let my subscription expire I am no longer entitled to updates.

The following link clearly states the Support agreements for BlackIce.

http://blackice.iss.net/support_renewal.php

I wouldn't expect anyother type of sales and a support scenario from a company offering system protection Software.


"Shoot Me! Shoot Me NOW!!!"
- Daffy Duck

 

[CajunCenturion]

and even if they (ed: Microsoft) don't "offically" support it (I'm talking about OS's here) they still test all there new software to see that it plays nice with their old OS's

Unfortunately, they only test their new software. They don't indicate whether or not the test was passed.

Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[gbaughma]

OK... tossing a couple of pennies into the mix.

As a software developer, I take pride in the software that I write. I've always considered it to be my moral obligation to fix bugs in my software.

Here's how I define it:

A bug is something in the program that is *supposed* to work one way, but doesn't work that way, or errors that keep the program from working at all.

For example, if I wrote a program to do a report for the last 30 days, and it only did 29, that's a bug. It's an error in my program, it didn't do what I said it would (or what the menu choices said, etc.) and therefore should be fixed. Free. Period.

If the user wants to do something that the software was not designed to do, that is not a bug. If they want the report to go back 60 days instead of 30, and it was never documented or stated that it would go back 60 days, that's a user request, billable, customized, or available in the "next release". That's adding functionality, not fixing something that is broken.

Additionally, the more complex a program, the more opportunity there is for bugs. You can't possibly test every iteration. For example, if you ask for the number of minutes on a form (I had this happen, btw). You're recording that as an Integer. Well, the user who should have put in 70 minutes, put in 1:10 (one hour, ten minutes). Barf. Program died. Why? The user did something that I wasn't expecting. As a programmer, I should have foreseen that, or at least done enough backend validation of the data to check for user input error. Was it a bug? Technically, no it wasn't. Was it short sighted on my part? Yes. Did I fix it so it couldn't happen again? Yes.

Of course, that's just me. Let's look at video games for a second. New game coming out, been a couple of years in development. Gotta hit the shelves before christmas. (Deer hunter was a perfect example of this going on, by the way....) So, meanwhile, the developers are pumping it out. When they create the installer, they want their game to run; they don't want returns, of course, so a lot of them will overwrite the DLL's on your system with the versions that were developed with their game. End result? The game works, but all of the sudden Office doesn't. Oh, must have been Office that crapped.... wonder why? Well, because this new game just overwrote some of the Office shared DLL's with two year old versions that came with the game!!!

OF course, that's an extreme example, but it happens. Was it a bug? Not really.... but it wasn't exactly ethical either.....

.... Maybe I should have tossed a quarter in on that one. Heheh...

Just my $.02

--Greg

 

[Stevehewitt]

I personally think that this thread shows that we should be thankful for at least one of MS traits!

 

[sleipnir214]

Stevehewitt:
That that trait is?

Want the best answers? Ask the best questions!

TANSTAAFL!!

 

[RiverGuy]

This is the way I see it:

1. It does no more harm to the software makers, shouldn't cost much to allow all users of the product to download the patch.

2. By only allowing users with maintenance contracts to receive the patch, the one way the software company can benefit is by trying to get others to get the maintenance, thereby increasing revenue.

3. The software company stands to make additional money because there was a flaw with their product. If there was no flaw, then then no one would need the patch. Users without the maintenance agreements wouldn't need to shell out money to get the patch.

The point isn't whether or not they should fix the flaw, beacuse they did fix it. It's whether or not they should make additional money because of the flaw. I think it's wrong.

But the way they get away with it is that they have the company rep saying that without the maintenance contracts, you can't even use the product. And that changes it entirely if it is true. If that is truly the case, then I believe they should design the product to cease to function at all when the contract is not renewed.

It was unclear whether or not the vulnerabilities were due to a flaw in the product in and of itself, or if the vulnerabilities were something that the product is supposed to supress. If by installing the product your system becomes vulnerable to new problems that were not there before, you CANNOT expect the company to imply that if you don't keep paying, then your system is even worse off than before you installed our product.

 

[chiph]

That that trait is?

Microsoft generally does a good job with their installations. Very seldom do you hear about a case where installing product "x" (of theirs) causing problems for product "y" (again, of theirs).

The problems usually are from 3rd party ISVs who don't version-check their components prior to installing them.

But the way they get away with it is that they have the company rep saying that without the maintenance contracts, you can't even use the product.

All ISVs try and minimize the number of bugs -- this keeps their support costs low. But that number never reaches 0, no matter what. You can ship a product with zero known bugs, but there's always that one client who finds the one you missed in your testing.

Are you familiar with the costs of shipping a defective product?
[ul]
[li]$5 - Fixing a problem in development[/li]
[li]$20 - Fixing a problem in QA[/li]
[li]$100 - Fixing a problem in media replication[/li]
[li]$300 - Fixing a problem in packaging[/li]
[li]$1500 - Fixing a problem in distribution[/li]
[li]$10000 - Fixing a problem at the customer site[/li]
[/ul]
The numbers are made up of course, but they illustrate how the costs escalate, the further you get out of development. Take a look at Barry Boehm's presentation (PDF file). The chart on page 5 shows the cost increases as you find problems in the various stages of software product development.

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first

 

[Stevehewitt]

I know many companies where you cannot get service packs and updates and sometimes even manuals and documentation without a support contract.

Sage is a bugger for this. I've decided to take company money else where. £600 for phone support 9-5 and updates sounds a bit steep to me when I can pay just £300 to another provider who gives better support without the patches.

All I meant was that MS have done a lot of things wrong and got a lot of bad press and PR for it - but there support isn't bad at all!

Installation works great, Windows Updates are even automatic, if I need a SP I give them a call and get it within in a few days and the knowledgebase is pretty good.

Shows that MS can at least do somethings right!

Steve.

 

[sleipnir214]

stevehewitt:
<facetious>
I suppose when you have sufficient practice publishing software patches, sooner or later you're bound to get it right.
</facetious>


chiph:
True, Microsoft has gotten very good about making sure their patches don't interfere with their software.

Unfortunately, since the Win32 API is unpublished you can't say the same for third-party software.

Microsoft has already stated that SP2 for XP will break some third-party software, and they say it will be because the third parties didn't code their software correctly. But if the API is unpublished, how are those third parties supposed to know what to do?

Want the best answers? Ask the best questions!

TANSTAAFL!!

 

[Dimandja]

Stevehewitt,

I have spent a year coding .NET and trying to get help along the way. So, let me ask you:

1. Where do you get Microsoft support, and how much does it cost?
2. Do you actually get answers from the MS 'knowledgebase'? The only place that helped me was TT or similar forums; MS stuff was always a mile besides the point.


sleipnir214,

I agree with you about MS upgrades wreaking havoc with existing applications. Some of my clients are at the point where they would prefer not to apply any patches from MS; because they invariably and wrecklessly break something.

Dimandja

 

[chiph]

Unfortunately, since the Win32 API is unpublished you can't say the same for third-party software.

Not true -- the part of MSDN called the "Platform SDK" is the Win32 SDK. If you write your app against just that part, and don't use any undocumented APIs, or use any calls which they say are "deprecated", then you should be OK.

What is not documented, is the kernel calls on the NT platforms (NT, Win2k, XP Pro, 2k3). They never have been, as they reserve the right to change them between releases.

In order to get advance notice of new APIs, you'll need at a minimum, a copy of MSDN Universal, and a subscription to MSDN magazine. If you want even more of an advance notice, you'll need to join the Empower ISV program, or join one of the levels of the Premier Partner program.

Empower is relatively cheap at $800, but they'll want to see a shipping app inside a year. Premier Partner is not cheap at all, but you get immediate access to 2nd & 3rd level support through an assigned representative at Microsoft, plus a certain number of education hours to use in training your people.

Some of my clients are at the point where they would prefer not to apply any patches from MS; because they invariably and wrecklessly break something.

Whose apps are the patchs & service packs breaking? They shouldn't be breaking MS apps at all.

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first

 

[Dimandja]

chiph: "Whose apps are the patchs & service packs breaking? They shouldn't be breaking MS apps at all.

One application I had to rewrite was using Outlook to send business mail. The application used the Outlook 'engine' to do this. After a 'security' patch, they found that the 'engine' was changed to become 'interactive' with the user thru pop-ups (!): this feature was never mentioned in the details of the patch - and defeats the purpose of using Outlook objects embedded in applications.

Dimandja