Anyone else have a problem with this?

[crelf]

I think it was the way it was worded on the NI page in my original post. To paraphrase the way I understood it: "We spent 3000 man hours fixing 100 bugs but YOU have to pay for it ..."

Yeah - I agree that the wording on that webpage should be a little better than it currently is. At least the bugfix and SSP sentances could be spaced much further apart...

[Grampa_of_Oliva_n_Eden]

Yeah - I agree that the wording on that webpage should be a little better than it currently is. At least the bugfix and SSP sentances could be spaced much further apart...

[Emphesis added]

X 5

Ben

[John Lokanis]

1) Buy LabVIEW 8.6 in October 2008 (get one year of SSP)

2) Get all 8.6 bug and maintenance releases.

3) Under SSP, you upgrade to LV2009 when NI releases it in August 2009.

4) You do not renew SSP in October 2009

5) You still get the 2009f2 and f3 fixes, but not SP1 as your SSP has expired

If this is the case, then you paid for one version of LV, got that version, the SP for it and then a whole new version as well, all for one price.

So, if you want to continue getting new versions (and subsequent SP) then you can pay the SSP fee. If you don't want to pay, then you can still use the version you actually bought (8.6) and all it's SP (8.6.1) and consider the LV2009 a bonus.

That is unless you are considering LV2009 a bug fix to LV 8.6.1.

So, when you buy a version of LV, you always get that version and all it's bug fixes.

Any way you look at this, I think NI is being quite fair. I have a lot of software that is constantly being updated and bug fixed, but I only get those updates if I pay for ongoing support.

Now, if for some reason NI found a major bug in LV8.6.1 and released a SP called 8.6.2, then I would expect that to be free to all LV8.6 licence holders.

[PaulG.]

While I'm not in this situation, I can envision a rare one. Both Jeff Phillips and I posted this scenario in our previous posts:

1) Buy LabVIEW 8.6 in October 2008 (get one year of SSP)

2) Get all 8.6 bug and maintenance releases.

3) Under SSP, you upgrade to LV2009 when NI releases it in August 2009.

4) You do not renew SSP in October 2009

5) You still get the 2009f2 and f3 fixes, but not SP1 as your SSP has expired

At that point you are not required to "pay" for SP1 if you don't feel you need, but you also can't install it. But if you do you need it, you would need to "pay" for it by renewing the SSP on your license. The cost for that varies by how long your license has been inactive.

Whether you interpret that as actually paying for SP1 or paying to renew your SSP (and getting SP1 as one of the benefits) is up to the indivdual. Like I said, I think that situation would be pretty rare.

-Scott

Indeed. You and Jeff are right. And it would be pretty rare. But "rare" has a sneaky way of eventually becoming "precedent".

[Gary Rubin]

So, it seems that the hubbub over this is dying down, but there's still something about it that vaguely bothers me.

I think it has to do with the whole upgrade/update vs. patch approach. Let's say I find a bug in LabVIEW. I report it and it gets fixed, but not until either the next version or the next revision (isn't 2009 SP1 the equivalent of 8.0 -> 8.2). So, in order to take advantage of the bug fix, I have to migrate to the newest version.

I think the thing that bothers me about that is the lack of backward compatibility (i.e. I can't open 2009 code in 8.6 (yes, I know I can save back one version, but that's not the point)).

One of our main products is still using LV7.1. When we sell a system, we often include a LV license. Then, if we need to upgrade the system, tweak things, add features, or whatever, the system already has a LV license that we can install and use. If we upgrade to a newer version of LV, then we can no longer use our latest and greatest code on those older systems without upgrading their LV also.

I think this whole "forced upgrade" vs. patch or minor release approach would sit better with me if I could easily pass code back and forth between versions, with newer structures, functions, whatever showing up as broken icons (kind of like missing subvi's) if they aren't common to both the newer and older versions.

Can you imagine the holy hell that would be raised if MS's response to Office bugs was "Tough s#!~, upgrade to the next version. Oh, by the way, you won't be able to share you files with other people unless they upgrade too."?

PS: Maybe my LV usage is unique. I tend to use it for data acquisition and processing. I have no interest in OOP, and tend to not use much beyond the basic primitives. With the exception of the disable structure and queues, which I find quite useful, I don't think I'm using much that hasn't existed for the past few versions (at least diagram-wise; I know that what's under the hood is has improved from version to version). Because of that, I don't see why I should have to upgrade (whether I have to pay for that or not) just to make what I'm using work properly. And no, I haven't found a bug in quite a while - it's just the principle of the thing.

PPS: If I remember right, LV 7.1.1 was a free bugfix patch to 7.1, wasn't it?

Edited March 3, 2010 by Gary Rubin

[jgcode]

isn't 2009 SP1 the equivalent of 8.0 -> 8.2

FWIW, I think 2009 SP1 is the equivalent of 8.2 -> 8.2.1

I think the thing that bothers me about that is the lack of backward compatibility (i.e. I can't open 2009 code in 8.6 (yes, I know I can save back one version, but that's not the point)).

One of our main products is still using LV7.1. When we sell a system, we often include a LV license. Then, if we need to upgrade the system, tweak things, add features, or whatever, the system already has a LV license that we can install and use. If we upgrade to a newer version of LV, then we can no longer use our latest and greatest code on those older systems without upgrading their LV also.

I think this whole "forced upgrade" vs. patch or minor release approach would sit better with me if I could easily pass code back and forth between versions, with newer structures, functions, whatever showing up as broken icons (kind of like missing subvi's) if they aren't common to both the newer and older versions.

This is something that doesn't sit well with me as well, dealing with customers who require source and having to support their LV update schedule. And it gets worse with hardware's software (cFP, cRIO etc...) that needs to be updated too.

Using MS to compare against, Office 2007 superseded Office 2003 so thats ~4yrs between versions. I like the idea that 2009 is interchangeable with 2009 SP1 code (as is e.g. 8.6 and 8.6.1). Maybe it would better if this was the case for longer i.e. all releases for 4 years will be guaranteed to be compatible?

However, given the new yearly schedule I think not.

[Cat]

Version changes concern me. They mean a lot of work for me revalidating my 1800+ vis. That's the main reason I went from 7.1.1 to 8.6.1 and bypassed all the other versions. I figured by the time 8.6.1 came out, all the bugs were out of the version 8 software.

So NI's new "Major Version Release Every Year" paradigm really concerns me. When they release software with a new major number that means to me they have made major revisions/additions/changes. Otherwise, why make it look like a different product?

I don't need a lot of fancy new features every single year; I need to know the code I already have is going to work and not be broken when I upgrade. Even worse, I don't want something to still work, but work *differently* from the way it did before (this one bit me in 8.6.1 -- so much for waiting).

I would much rather see LV2009 SP2 be released next August, not LV2010. And if LV2010 will be, in essence, just more bug fixes for LV2009, then NI shouldn't change the version number. I would actually feel comfortable upgrading then.

[TG]

My only beef on this issue is the number of upgrades that come down the pike in just a few years.

And guess what. I am not going to have a new version just sit there when it comes out. Who would?

Even if I don't use it I am still going to install it

And I am going to look at it when time permits.

and of course when I download an example code snippet here at this forum I'll have to have the latest and greatest version to convert the thing into something I can use.

But the size and timeload of each new installation for each new revision is kind of ridiculous to me personally.

I would not care either way except for that.

[crelf]

For the record, and as an aside, NI isn't forcing anyone to upgrade their verson of LabVIEW every year. I know a number of ppl still stuck on 7.1 because it does everything that they need and nothing that they don't, so they have no real reason to upgrade.

[jgcode]

For the record, and as an aside, NI isn't forcing anyone to upgrade their verson of LabVIEW every year.

What kind of LabVIEW enthusiasts would we be if we didn't upgrade to the latest and greatest!

[TG]

What kind of LabVIEW enthusiasts would we be if we didn't upgrade to the latest and greatest!

Not only that but how can anyone learn anything from this forum if they don't have the latest version

of LabVIEW?

I come here to learn and get example code.

The Latest LabVIEW is needed to learn new stuff here.

[hooovahh]

I come here to learn and get example code.

The Latest LabVIEW is needed to learn new stuff here.

Being the LabVIEW enthusiasts as we are, we usually have many versions installed and can down save. I have 8 at the moment, do I hear 9?

[jgcode]

Being the LabVIEW enthusiasts as we are, we usually have many versions installed and can down save. I have 8 at the moment, do I hear 9?

I have 5. You win.

[Francois Normandin]

Being the LabVIEW enthusiasts as we are, we usually have many versions installed and can down save. I have 8 at the moment, do I hear 9?

That's quite a coming out!

(BTW, betas shouldn't count... yet)

[PaulG.]

Being the LabVIEW enthusiasts as we are, we usually have many versions installed and can down save. I have 8 at the moment, do I hear 9?

List them. Beta's count.

Edited March 9, 2010 by PaulG.

[Rolf Kalbermatter]

I understand the frustration of having to pay for a bug fixing version.

But to be fair I don't think NI (or any other company that ships such a big soft) can wait until the product is 100% bug free. If you want LabVIEW 2010 to be released only when it has no bug at all it will be released in 2020.

Wrong! It will be never released!

Because there is no way to test every possible permutation until it is actually used. And it gets only really used when it is released! And I'm sure even the famous stable versions like 7.1.1 do still contain lots of potential bugs by the criterion that requests 100% bug free LabVIEW versions.

[Rolf Kalbermatter]

The above "release the following year" is how you end up without the SSP for the bug fixes.

I think this gets away from the point, though.

If I release code to a customer, the bug fixes are priced in. If they come back to me in two years and say "Hey, we found a bug that matters to us", I'm going to fix it for them, gratis (and have done so). I consider it to be what professionals do.

You can't possibly support an application for indefinite time without some charge. Even if it is a big fix. We do have a warranty period on our software but if a bug hasn't been uncovered in that period then it wouldn't seem a critical bug. Also where do you consider the limit between a bug and a new feature? What if your application suddenly misbehaves because of some changes to the system you could have foreseen logically? Is this still a bug or is this some other thing that warrants some charges?

Generally if you work for some production environment those people understand that maintenance has its costs. Computers do get older, system parameters do change, once perfectly running code can get affected by all this. If you do this all for no cost for many years after having delivered a system, you do get into problems with your business plan for sure and you might have actual issues defending your rights towards your customers.

Maybe your car gets serviced for free every year where you live and any repairs are for free because the car manufacturer believes that his prodcut should run 10 years without any failure but it is not how things work here. That RPM sensor that failed two times causing system check errors? Well normally charged both times! Does it sound like a possible systematic error? One could argue that way as two times the same error in just 4 years is a bit strange. But it is how business works today.

[crelf]

And I'm sure even the famous stable versions like 7.1.1 do still contain lots of potential bugs by the criterion that requests 100% bug free LabVIEW versions.

Ahhhh 7.1.1 - one of my favorite version (5.1.1 is up there too).

[jzoller]

You can't possibly support an application for indefinite time without some charge. Even if it is a big fix. We do have a warrenty period on our software but if a bug hasn't been uncovered in that period then it wouldn't seem a critical bug. Also where do you consider the limit between a bug and a new feature? What if your application suddenly misbehaves because of some changes to the system you could have foreseen logically? Is this still a bug or is this some other thing that warrants some charges.

Generally if you work for some production environment those people understand that maintenance has its costs. Computers do get older, system parameters do change, once perfectly running code can get affected by all this. If you do this all for now cost for many years after having delivered a system, you do get into problems with your business plan for sure and you might have issues defending your rights towards your customers.

Maybe your car gets serviced for free every year where you live and any repairs are for free because the car manufacturer believes that his prodcut should run 10 years without any failure but it is not how things work here. That RPM sensor that failed two times causing system check errors? Well normally charged both times! Does it sound like a possible systematic error? One could argue that way as two times the same error in just 4 years is a bit strange. But it is how business works today.

Fascinating that you chose cars as an analogy.

Did you know Toyota's expected loss is around $7.7US billion dollars? Just this quarter? It's their first loss in 70 years. Think how much they could have saved, had they fixed their "bug" in timely fashion.

Do you sell products, or do you sell reputation?

Reputation is worth a lot more.

Joe Z.

[crelf]

Did you know Toyota's expected loss is around $7.7US billion dollars? Just this quarter? It's their first loss in 70 years. Think how much they could have saved, had they fixed their "bug" in timely fashion.

Well... yes and no. I find it interesting that the Toyota issue is being made much more of an issue here in the US than anywhere else in the world. Maybe it's because I'm in Detroit and it seems that Toyota pretty much all the local media can talk about right now. Perhaps a nod to the big three?

Do you sell products, or do you sell reputation? Reputation is worth a lot more.

But you can't have one without the other

[Rolf Kalbermatter]

Do you sell products, or do you sell reputation?

Reputation is worth a lot more.

We sell mostly services. Not a product or some hot air.

And as crelf said the Toyota issue, while showing a problem in the way they handled it, is also for a big part propaganda. Its publicity is a lot about fingerpointing and saying look how bad they are, completely forgetting that each of them had also major issues in the past whose costs went in the billions too. The difference is that Toyota might have a chance to survive this, while many others would have been dead by now.

[Grampa_of_Oliva_n_Eden]

Well... yes and no. I find it interesting that the Toyota issue is being made much more of an issue here in the US than anywhere else in the world. Maybe it's because I'm in Detroit and it seems that Toyota pretty much all the local media can talk about right now. Perhaps a nod to the big three?

But you can't have one without the other

Intersting that the majority stock-holder in Government Motors is highlighting flaws in the competion's quality?

Ben

[crelf]

flaws in the competion's quality?

Speaking of which, can anyone remember when the definition of the word "quality" changed from "it's a good product" to "it's an exact duplicate of the previous one"? The ISO quality standard is about that something is guaranteed to be made to a spec and a process, not about whether it's something that is function or will last. It seems that there's more concentration these days on verification, yet little on validation. Or, at least, some companies seem to interpret validation only as it applies to verification.

So when a car company spouts about how their quality is high, they're not saying that their cars are good or that they will last a long time - they're saying that they're all made to spec. So, if that spec has a flaw in it (eg: accelerator pedals sticking), as long as they all have that fault, then it's still a high quality product. Yet I'd suggest that the common person that their advertising is aimed at doesn't understand this subtlety.

More info here: http://en.wikipedia.org/wiki/V%26V

Meh, maybe it's just me.

[Grampa_of_Oliva_n_Eden]

Speaking of which, can anyone remember when the definition of the word "quality" changed from "it's a good product" to "it's an exact duplicate of the previous one"? ...

Meh, maybe it's just me.

I once read/heard a story of when a company first went to a vendor in another country to supply resistors (?). They spec'd it at 100 ohms plus or minus 5%. ..... The vendor was inserting resistors that were 95 adn 105 ohms plus or minus 0.1% to meet the spec.

In that case as well as the one you are speaking about, language may be playing a part.

Maybe we should be asking for fail-safe cars instead of quality cars.

Speaking for myself I concider LV a quality product with some versions having a higher quality than others. As long as we don't bend over backwards, a license comes with updates that fix the worst problems as long as we don't introduce any new stuff when applying the fixes.

Years ago people didn't want to buy cars of the first model year assuming there would be problems. It was assumed you would get a better product with the next year. Same applies to LV and we do get a more powerful and robust development environment with each update.

But as they evolves over the years changes to the design can introduce problems. In both cases crashes are bad and should and are fixed through recalls or updates.

But in the case of cars you never hear an add that says "Buy the new 2010 model, it does not crash!" (Yes I'm getting to a point).

Adds that claim "Our new software is not as buggy as the old stuff!" have probably been copyrighted by MS.

Ben

[jzoller]

Unfair as it is, it's still going to cost Toyota jobs, market share, and $billions. My point is simply that perceptions matter.

Good product with a bad rep would be Microsoft, Apple, or Linux (take your pick). Bad product with a good rep... things don't work in that direction for long.

About quality vs. reproducibility: yep. My contention is that overuse of systems like Six Sigma leads to reproducible products that no one really wants.

From Wikipedia's Six Sigma entry: "A BusinessWeek article says that James McNerney's introduction of Six Sigma at 3M may have had the effect of stifling creativity. It cites two Wharton School professors who say that Six Sigma leads to incremental innovation at the expense of blue-sky work."

The next wave seems to be officially sanctioned, process driven "Innovation", complete with consultants and management retreats.

Adds that claim "Our new software is not as buggy as the old stuff!" have probably been copyrighted by MS.

Ben

Well, I suppose it's better than MS' old motto: "Our new software is *much* buggier than the old stuff!"

Joe Z.

Edited March 10, 2010 by jzoller