LabVIEW Roadmap 2022 Q3

[rolfk]

---

@cy... wrote: Are partners obligated to fix/patch deployed user applications should NI issues a bug/fix/update?

---

How would you expect this to work? Either your customer has an ongoing support agreement with you or they have to negotiate with you or whomever they like to do such maintenance. What you are obligated to do depends entirely on your agreement with that customer. Even “just” installing a bug fix release is an effort that nobody is going to do for a smile alone. 😀

In the case of an NI driver bug fix the customer could do this on their own, but of course assumes the risk when things fall apart. If they want expertise and assurance they have to find someone who can and will do it for what they want to pay.

[cy...]

I believe some degree of support is expected especially if the err/bug was discovered to be from the subscribed software; which can be discovered very early or just as recently. But, normally fixes comes a 'season' after (if not more), unless it is also a norm to expect users to accept 'workarounds' or warranty-less programs

if partners are not obligated, and users cannot fix codes even if they get the debug/deployment license, then the question users may have is why LV?

[rolfk]

Put yourself in the shoes of a developer for just a second. You developed a great application for a customer that works for them and they are happy (or maybe not because they wanted to pay for a VW but expected a Rolls Royce 😀). Then half a year later NI releases a bug fix for the LabVIEW version used. And your customer comes to you and tells you: “There is a bug fix for the used LabVIEW system. We want that applied and our application reexamined to work the same as before By the way you are obligated to do that for us as your agreement with NI says so! And of course it has to be done right now and we are so generous to pay nothing since you are obligated to do it!”

You see anything wrong with that? I certainly do! NI can’t obligate someone else to do something like this and will leave these things to the agreement you and your customer make. You might feel like putting such guarantees in the contract with your customer but you better make sure he pays a premium for such warranties or you are out of business faster than you can finish that project! Generally, customers would love such warranties but not so much the associated costs, and the result is almost always that they will rather go for the lower cost and negotiate maintenance work as and when it comes up with an according payment.

And this is totally independent of the used development environment. There is no programming language where a developer is obligated to apply bug fixes for the used IDE over all ever developed applications. If there would be it would be a major reason for developers NOT to use it! But it’s an academic exercise anyways since, such an obligation is neither enforceable by the manufacturer of the software nor would it stand much chances before a court.

[cy...]

@rolfk I can understand from the POV of external developer (partners), just that the current subscription model and limitation of debug/deployment license, it doesn't really work well for in-house developer

[rolfk]

Not sure what you mean. Are you talking about a typical company using LabVIEW for its test stations in production? In that case you either have ongoing development and want to have ongoing LabVIEW support or you have a one off development that once developed only needs maintenance. In the second case the debug license works fine but the bigger challenge always is to find someone in the company who knows LabVIEW and can do this maintenance without letting the system explode rather than fix something. But that is independent of the license and happened with the old perpetual licenses in the past all the time too!

And even the instrument manufacturer providing some drivers for his instruments has in the past often not maintained their drivers no matter that they had a perpetual license to do so. The standard excuse always was that they had nobody internally who could maintain them.

But generally I don't see why an internal developer should be considered fundamentally different than an external one. They are neither a God or something, nor the piss pole where the rest of the company can look down upon as that crazy person who will pull their leg out to make everything work.

[EricR]

By the way, I am very interested in this dialog with both of you.  Understanding how both you as the original "developer" and the customer you sold it to as the "user" view this scenario is very educational.  I think understanding this scenario and all of the facets to it helps me understand if there are gaps created with the current usage of the Debug/Deployment licenses.  This is exactly the type of scenario I was looking for when I posted that information.  While I had a very clear scenario in my head when we first created these debug/deploy licenses, we might find that there are specific scenarios that we are not handling, or at least not handling completely. 

If anyone in this discussion would be interested in a 30min discussion, please let me know and I'll work on setting something up.

[cy...]

@roflk I may have made an assumption that all developers are partners, hence having access to the partner software bundle. my bad.

a non-partner could be using/maintaining SPB, hence there would be a significant difference in maintenance cost as a result of the switch to subscription. such developer could have been used to be able to develop new and maintain (including migrate 8.5-ish ones to 21) with LVP, modules & TS; now, the developer might have to choose which is the only other one to be kept with LVP

[rwunderl]

The watermark I saw a while back may have been due to a trial license of the Debug/Deployment license or something, I’m not sure anymore. In any case my main point was the mental state that this annual expiration date puts me in as a developer. How do I know I can afford my license in a year’s time? Will I finish the project on time? When do I need to start collaborating with Purchasing folks to avoid a lapse? Why do the toolkits expire a few days before my developer seat when I bought them on the same PO? Annoying.

Here’s a real-world-ish scenario: I want to start a big internal development project in LabVIEW 2020 (because I don’t like the bugsfeatures introduced in later versions). Let’s say this development effort will take the better part of a year. I will then support this code for the foreseeable future, let’s call it 10 years total. There is no consideration whatsoever given to upgrading the code anytime soon (the next 5 years), because we wish to have a stable codebase to go into production with. The code won’t change substantially after that because we don’t want to disrupt the manufacturing process.

Meanwhile, I want to continue to develop other smaller projects at my desk to support other R&D efforts at the company. I don’t want to upgrade my own LabVIEW version because then it’s harder to support the production system and maintain multiple versions of the software and all the drivers and licenses, blah-blah. I’d like to keep things simple for the near term (let’s call it 3 years). Remember I didn’t even want the latest-and-greatest version to begin with.

Bottom line: last year I would have budgeted 1 Development license (perpetual) with all the toolkits I need for about 10k and a Debug/Deployment license (perpetual) and toolkit deployment licenses (perpetual) for the test stand(s) for about 5k. Everything for 15k for the next 3 years. Say we re-up the licenses every 3-4 years (twice in 10 years) just to keep up with the Jones’, so we’re in for 45k for the life of the project (4.5k per year). Fine.

Using the new pricing model, I need to buy all the same Debug/Deployment stuff (15k in 10 years) but now I’m on the hook to renew my developer seat every year for 10k (since the prices didn’t change much). So now the project is on the hook for 10*10+15=115k all-in (about 12k per year) for no added benefit to the company (still upgraded only twice to keep risk reduced). (edit: math issue after changing the timeline)

Repeat this scenario a couple of times within a company and multiply over all companies and I can clearly see why NI has adopted the new pricing model. Three times the income with no measurable increase in effort on NI’s part. Please explain to me how this could be spun as a benefit to the customer. I have always been a big fan of NI, but I feel like I am experiencing a crisis of faith here.

[OneOfTheDans]

@rwunderl, your scenario includes two different uses of LabVIEW: develop/deploy/debug a 10-year LabVIEW program AND tinker in small R&D projects for 9 years. If you look at it that way the main program's cost doesn't increase but NI has decided to eliminate the secondary benefit of tinkering on small side projects.

NI's new licensing structure has little effect on existing full-time LabVIEW developers, it just kneecaps anyone who's learning, tinkering, or part-time developing. I'm pretty sure that's how everyone learned LabVIEW, so we'll see how NI manages to grow the developer base without that on-ramp.

[tst]

---

@OneOfTheDans wrote:

NI's new licensing structure has little effect on existing full-time LabVIEW developers...

---

I disagree. Being a full-time dev does not necessarily mean you are always up to date. It's certainly possible to upgrade only every N years. Even if you did upgrade every year, many people were on SSP, which was still perpetual. And even if you were on subscription, you had the perpetual option which meant you didn't have the threat of deactivation hanging over your head. Now you don't have that choice.