NI's New Software Subscription Model

[hooovahh]

Today NI announced a new subscription model for all NI software, with special exceptions for perpetual licenses for things such as debug and deployment licenses.

https://www.ni.com/en-us/landing/subscription-software.html

I don't really have a whole lot to contribute to the discussion just yet, but I just thought I'd make the community aware of it in a separate post so people can discuss it if they'd like.

[ShaunR]

If I buy a subscription license and then decide not to renew, what happens to my software?

With subscription software, you will need to renew at the end of each term to maintain access to your software and associated services.  

 

Yikes. Software as a service?

[Bryan]

1 hour ago, ShaunR said:

Yikes. Software as a service?

I was wondering when NI would go this route - seems like every entity that used to produce software as a product is going this way. 

I like to minimize dependencies as much as possible in everything I do.  Software as a service is one additional dependency that I am not looking forward to dealing with.  

Since my license is provided via VLA (for which I'm not the administrator as I was at my previous company), I guess it's more of the same.

Wouldn't surprise me if sometime in the future, some sort of NI subscription is required to use the RTE in order to run executables.  The day that happens is the day that I move to another programming language as my primary. 

National Microsoft... err... Microsoft Instruments... I mean... National Instruments is becoming more like Microsoft each year and I'm not liking it. 

Edited December 14, 2021 by Bryan

[bbean]

1 hour ago, ShaunR said:

If I buy a subscription license and then decide not to renew, what happens to my software?

With subscription software, you will need to renew at the end of each term to maintain access to your software and associated services.  

 

Yikes. Software as a service?

This isn't enticing you to upgrade from LV 2009?😀

[hooovahh]

6 minutes ago, bbean said:

This isn't enticing you to upgrade from LV 2009?😀

Good point.  I wonder if people are going to go out and buy a perpetual 2021 license while they can.  I currently get my license from a VLA that we renew each year.  Depending on the options we may just renew like normal.  I do suspect the price will go up compared to what we currently pay but we'd get access to lots of other software we currently don't.

[ShaunR]

2 hours ago, bbean said:

This isn't enticing you to upgrade from LV 2009?😀

It's enticing me to downgrade to Python 

[Jordan Kuehn]

It seems to me that if you already maintain SSP it's not a big change aside from the point above should you choose to stop and no longer have access to LV. 

[Rolf Kalbermatter]

2 hours ago, Jordan Kuehn said:

It seems to me that if you already maintain SSP it's not a big change aside from the point above should you choose to stop and no longer have access to LV. 

Actually it is! If you stop paying your SSP fees you can still continue to use the LabVIEW version that was current when you stopped paying. With the subscription model if you stop paying, any software version will stop working at the end of your subscription term. No loading up an old program to fix this little bug that would anyhow be to much of a hassle to port to the greatest and latest LabVIEW version. Any LabVIEW version you have installed simply stops working.

You could of course install LabVIEW with the Community Edition license then, but that violates the license agreement you entered when signing up for the Community Edition if your program is used in any professional capacity. And the Community Edition does not include things like RT, FPGA, and just about every other thing with a paid license including the Application Builder.

And if NI decides to shutdown their license server altogether, or for certain older versions of LabVIEW you are equally hampered. It's unlikely that they will let you activate LabVIEW 2009 indefinitely under a subscription model. I'm not even sure if you can activate older versions if you sign up for a subscription model now.

Yes it is how every software provider is heading nowadays. Greater revenues and user lockin are tempting. Once they got a user, be it Office 365, Altium and now LabVIEW the user has only the choice to keep paying or stop using the software platform altogether with all the hassles of trying to port existing solutions to a different platform which simply does the same anyhow. So the challenge is to get people to sign up and start using it, after that it is a safe business that is not so easily going away unless you totally start to f*ck them. Rising prices? If you do it in regular small steps, except for new users, you are not likely to lose many users! Nobody wants to end up with Office documents that he can't open anymore!

Edited December 15, 2021 by Rolf Kalbermatter

[mahgust]

In carrot and stick method NI chose stick.

Active IDE improvement and grow, new features lead users to go to newer versions. (Just an example - Win11/Ubuntu/Mac M1 support in time).

Switching to subscriptions is an option for SW-only products, for HW products going to subscription can be wrong choice imho.

This is just "engineering" point of view, marketing staff at NI have different one)

[Jordan Kuehn]

51 minutes ago, Rolf Kalbermatter said:

Actually it is! If you stop paying your SSP fees you can still continue to use the LabVIEW version that was current when you stopped paying. With the subscription model if you stop paying, any software version will stop working at the end of your subscription term. No loading up an old program to fix this little bug that would anyhow be to much of a hassle to port to the greatest and latest LabVIEW version. Any LabVIEW version you have installed simply stops working.

You could of course install LabVIEW with the Community Edition license then, but that violates the license agreement you entered when signing up for the Community Edition if your program is used in any professional capacity. And the Community Edition does not include things like RT, FPGA, and just about every other thing with a paid license including the Application Builder.

And if NI decides to shutdown their license server altogether, or for certain older versions of LabVIEW you are equally hampered. It's unlikely that they will let you activate LabVIEW 2009 indefinitely under a subscription model. I'm not even sure if you can activate older versions if you sign up for a subscription model now.

Yes it is how every software provider is heading nowadays. Greater revenues and user lockin are tempting. Once they got a user, be it Office 365, Altium and now LabVIEW the user has only the choice to keep paying or stop using the software platform altogether with all the hassles of trying to port existing solutions to a different platform which simply does the same anyhow. So the challenge is to get people to sign up and start using it, after that it is a safe business that is not so easily going away unless you totally start to f*ck them. Rising prices? If you do it in regular small steps, except for new users, you are not likely to lose many users! Nobody wants to end up with Office documents that he can't open anymore!

I think we said the same thing here, albeit mine was far less comprehensive. Are there other caveats other than the switch getting flipped off on the software when you stop paying? I'm not diminishing that one, but in terms of practical impact if you currently maintain an SSP there is no real change.

[Rolf Kalbermatter]

22 minutes ago, Jordan Kuehn said:

I think we said the same thing here, albeit mine was far less comprehensive. Are there other caveats other than the switch getting flipped off on the software when you stop paying? I'm not diminishing that one, but in terms of practical impact if you currently maintain an SSP there is no real change.

Well, it depends a little on the duration of use. With the perpetual model you paid a hefty initial price and then a yearly SSP for as long as you wanted to be able to use newer LabVIEW versions, have access to technical support (which for a few years has been next to useless but it seems it has improved considerably in the last year). With the subscription model you pay a lower initial price but a higher early subscription price than what the SSP used to be. If you have a current SSP you can initially transition to a subscription license for the cost of your current SSP (and lock that in for to up to three years) but after that is over, you pay significantly more per year than what you did with the SSP.

It seems the break even point is at about 4 years. If you intend to use LabVIEW for less than that you pay more with the perpetual model. After that the total cost of the subscription gets higher than with a perpetual license and yearly SSP payments. In a way this sounds like NI is making incentives to use LabVIEW more on pure project base and after the project is done forget about it.

The software lease costs on average about double of what the SSP cost and the perpetual license without the included 1st year of SSP about the double of what the software lease costs. But you can't buy a perpetual license without at least 1 year of SSP.

Edited December 15, 2021 by Rolf Kalbermatter

[Jordan Kuehn]

11 minutes ago, Rolf Kalbermatter said:

Well, it depends a little on the duration of use. With the perpetual model you paid a hefty initial price and then a yearly SSP for as long as you wanted to be able to use newer LabVIEW versions, have access to technical support (which for a few years has been next to useless but it seems it has improved considerably in the last year). With the subscription model you pay a lower initial price but a higher early subscription price than what the SSP used to be. If you have a current SSP you can initially transition to a subscription license for the cost of your current SSP (and lock that in for to up to three years) but after that is over, you pay significantly more per year than what you did with the SSP.

 

Gotcha. That's with the pricing structure as it stands today right? Theoretically they could meet in the middle or change things in other ways as that lock-in rate starts expiring for *lots* of users all at once.

[Rolf Kalbermatter]

58 minutes ago, Jordan Kuehn said:

Gotcha. That's with the pricing structure as it stands today right? Theoretically they could meet in the middle or change things in other ways as that lock-in rate starts expiring for *lots* of users all at once.

You can always dream 😀. But what would be the incentive to lower prices once everyone who is still wanting to use that platform is locked in? A competitor maybe, but who would that be? There is nobody to be seen, unless you consider jumping the ship completely and go with other solutions, even Python maybe, which is nice but not an option for a lot of work done with LabVIEW nowadays.

[X___]

I'd be curious to know what will happen to released applications (standalone) and toolkits.

[hooovahh]

As far as I know built applications use the run-time engine which requires no license, just a EULA for installing it.  If you are talking about things like FPGA and the Real-Time module then I'm not sure but I suspect they too will use an annual license strategy.

[Rolf Kalbermatter]

30 minutes ago, hooovahh said:

As far as I know built applications use the run-time engine which requires no license, just a EULA for installing it.  If you are talking about things like FPGA and the Real-Time module then I'm not sure but I suspect they too will use an annual license strategy.

Yes, built applications will continue to work like they did so far. This means for the LabVIEW runtime you can install it and your executable on any computer you want and run it.

Eventual Runtime licenses such as for IMAQ Vision etc, will still be per machine licenses and not leases, just as they are now.

The Realtime and FPGA Module will be also a software lease but you only need them to write and build the compiled code, after that you can run them on any licensed hardware just like you do now. Deployment will of course only work from a licensed LabVIEW Development system with activated Realtime Module but once it is deployed, the target can run for as long as you want without limitations by a software lease. If they ever would change that that will be the day our company will definitely stop to use LabVIEW. We can not have a machine stop execution because the NI license server takes some vacation or some software lease has expired.

The Debug Deployment licenses of the different NI software products will also stay as perpetual licenses. They are in principle the same as the Development system but you only have the right to use them to debug an application, not to write and build it. They are meant for the computers on the factory floor where you want to run your built application but may need to be able to also execute the VIs in source code to debug problems on the real hardware instead of on your development machine.

Edited December 15, 2021 by Rolf Kalbermatter

[X___]

Sounds reasonable. In this scheme, it seems that you can hold off on upgrades, as long as you pay your subscription. So, for most practical purposes it is a cleverly framed price cut...

[ShaunR]

18 hours ago, Rolf Kalbermatter said:

A competitor maybe, but who would that be?

Python.

I know of very few LabVIEW positions in Europe for T&M. Very few vacancies are for LabVIEW now, generally. This seems to be a move to specific corporate customer types, like CERN. This will hit consultants. start-ups and small niche suppliers the hardest and say goodbye to most open source toolkits.

With no new growth in uptake of LabVIEW and walled-off, future-proofing for existing customers, I see this as the death-throes of LabVIEW as eventually  the corporate customers move away.

Edited December 16, 2021 by ShaunR

[Rolf Kalbermatter]

3 hours ago, ShaunR said:

Python.

I know of very few LabVIEW positions in Europe for T&M. Very few vacancies are for LabVIEW now, generally. This seems to be a move to specific corporate customer types, like CERN. This will hit consultants. start-ups and small niche suppliers the hardest and say goodbye to most open source toolkits.

With no new growth in uptake of LabVIEW and walled-off, future-proofing for existing customers, I see this as the death-throes of LabVIEW as eventually  the corporate customers move away.

I agree with all you said, but don't see Python as a viable competitor to LabVIEW. It's getting ubiquitous in many ways, being on every IoT device nowadays, having libraries for just about anything you can think off, even more than Java ever had. But it's still interpreted (yes I know about JIT but that is besides the point), and I really hate to do UI programming by scripts, otherwise I might have stayed with LabWindows CVI. And while crunching large data sets in LabVIEW can be challenging due to its data flow forced data copies, trying to do the same in Python is generally causing me to fall asleep or check if the computer hasn't frozen up.

And it can be a challenge to find the pearls in the many Python libraries. A lot of what is posted out there is mediocre and shows that the person having done it didn't even understand what they were doing, but for some miraculous reasons managed to get to a point where it did something.

If anything I see Python mainly as a competition to .Net. While not the same in many ways they are much closer to each other than any of them is to LabVIEW. The advantage (and disadvantage) of .Net is that Microsoft is behind it. They are powerful enough to make or break a platform but at the same time also do not want to lose control of it, which has caused some strange acrobatic decisions in the past about announcing to open source it, but not quite doing it anyways.

Edited December 16, 2021 by Rolf Kalbermatter

[ShaunR]

2 hours ago, Rolf Kalbermatter said:

I agree with all you said, but don't see Python as a viable competitor to LabVIEW. It's getting ubiquitous in many ways, being on every IoT device nowadays, having libraries for just about anything you can think off, even more than Java ever had. But it's still interpreted (yes I know about JIT but that is besides the point), and I really hate to do UI programming by scripts, otherwise I might have stayed with LabWindows CVI. And while crunching large data sets in LabVIEW can be challenging due to its data flow forced data copies, trying to do the same in Python is generally causing me to fall asleep or check if the computer hasn't frozen up.

And it can be a challenge to find the pearls in the many Python libraries. A lot of what is posted out there is mediocre and shows that the person having done it didn't even understand what they were doing, but for some miraculous reasons managed to get to a point where it did something.

If anything I see Python mainly as a competition to .Net. While not the same in many ways they are much closer to each other than any of them is to LabVIEW. The advantage (and disadvantage) of .Net is that Microsoft is behind it. They are powerful enough to make or break a platform but at the same time also do not want to lose control of it, which has caused some strange acrobatic decisions in the past about announcing to open source it, but not quite doing it anyways.

The market has spoken. While you may be correct from a technical point of view, Python is now dominant in T&M and for everything else, there is Matlab. That leaves FPGA and Hardware still in NI's wheelhouse with regards to LabVIEW.

UI isn't a strength in LabVIEW and I take your point about Python with regards to WISIWIG component forms but when you do everything with an HTML interface-it's just a back-end choice with Python being a lot easier to interface to. The question to ask is...if I wanted to create an application that produced a walled garden like NI are now doing (a service in the cloud); how easy would it be with LabVIEW? I can guarantee that a lot of the services they are now promoting have very little LabVIEW programming in them and this is where many industries, including NI now, have already moved to.

[Jordan Kuehn]

4 hours ago, ShaunR said:

The market has spoken. While you may be correct from a technical point of view, Python is now dominant in T&M and for everything else, there is Matlab. That leaves FPGA and Hardware still in NI's wheelhouse with regards to LabVIEW.

UI isn't a strength in LabVIEW and I take your point about Python with regards to WISIWIG component forms but when you do everything with an HTML interface-it's just a back-end choice with Python being a lot easier to interface to. The question to ask is...if I wanted to create an application that produced a walled garden like NI are now doing (a service in the cloud); how easy would it be with LabVIEW? I can guarantee that a lot of the services they are now promoting have very little LabVIEW programming in them and this is where many industries, including NI now, have already moved to.

At risk of derailing this topic I've seen you make many arguments as such, but they rely on the assumption that the user is utilizing an HTML "View" and can plug and play LV or Python or whatever behind it. In your workflow I 100% believe that is the case. However, I do not think that is common. Certainly I will admit my knowledge of python driven UIs is lacking. However, flawed and outdated as LV UIs are, they are still an advantage from my perspective. I have dabbled with your approach and do see the positives there, but it's not dissimilar to having to program a host application for an RT target and adding an additional layer to every application.

[ShaunR]

2 hours ago, Jordan Kuehn said:

However, I do not think that is common.

This is true but that is only because LabVIEW features are about a decade behind other offerings. We only got TLS in LabVIEW 2020!

What LabVIEW does well is hardware control and acquisition but for a long time now, NI has traded off the back of their instrument drivers. Beyond that, LabVIEW has a lot of competition that is open-source and free (as in beer) and easily extendible. If you want a nice UI with theming, LabVIEW is a poor choice.

2 hours ago, Jordan Kuehn said:

Certainly I will admit my knowledge of python driven UIs is lacking

Python is much worse for UI's. But it doesn't matter if you have an HTML UI because Python is fantastic at webservers, services and TCP. The main advantage of Python over, say, PHP or Javascript is that you don't need an Apache or Nginx webserver.

However, the point I'm obviously failing to make is that Python has already conquered one niche space that used to be a strong selling point for LabVIEW and making it  Software-as-a-service will make it even more unpalatable going forward. Don't get hung-up on Python though. Javascript is a contender also. However Python is more ubiquitous in T&M at present.

Anyhow. That's enough of the black-pills. Someone gimme some white-pills with this "progress"

Edited December 16, 2021 by ShaunR

[Jordan Kuehn]

55 minutes ago, ShaunR said:

However, the point I'm obviously failing to make is that Python has already conquered one niche space that used to be a strong selling point for LabVIEW and making it  Software-as-a-service will make it even more unpalatable going forward. Don't get hung-up on Python though. Javascript is a contender also. However Python is more ubiquitous in T&M at present.

I agree with you here. Community edition of LV is one step forward, while SaaS is a few steps back in terms of pursuing market adoption. Python is ubiquitous because it is free and people can copy/paste code bits they find on sourceforge together to get something to work while playing around with a Pi at home/university. Then they find those skills actually have value in the market.

[ShaunR]

52 minutes ago, Jordan Kuehn said:

Community edition of LV

That's a point. What happens to that? Is that outside of this subscription model?

[hooovahh]

13 minutes ago, ShaunR said:

That's a point. What happens to that? Is that outside of this subscription model?

It is still free (as in beer of course) for all non-commercial use.  It might only be licensed for one year at a time, and it is linked to your NI account.  It does make the SAS model a bit easier to swallow, along with the 3 year locked in price.  As an individual I can still keep up with LabVIEW and use it for all the stuff I want.