LabVIEW subscription model for 2022

[JimB.]

---

@Jay14159265 wrote:

---

@alexderjuengere wrote:

---

@crossrulz wrote:

As far as other dev tools that do not build into an executable: Python.

---

kudos for pointing this out.

---

I think this is an interesting point for some use cases. 

If your code never leaves the company, you might want to make an executable to make the code more portable because you don't want a dev system on every computer. for many reasons but notably because running LabVIEW on every company computer is expensive. 

If your code does leave the company and has some IP in it you might want to compile so people cant see it.

What if IP is not an issue? You can run a Python dev system on any computer for free and you can package, distribute, and install python apps on any computer. So is the ability to generate an executable only of interest if you have some IP you want to protect (or if you just like having an executable)? 

I would guess there are more LabVIEW applications that are internal and never get distributed than ones that are distributed / sold. 

---

 I actually thought about Python as I was posting that comment and figured someone would bring it up. A few things that, in my mind, make that a little different:

1) As far as I know, Python itself does not have any capability to create an exe. It's not as if you need to upgrade to a higher tier.

2) If you don't want to distribute source then the closest thing would be to distribute compiled bytecode (.pyc files). This adds some additional things to consider, but the ability to do so is present.

3) If you really want to create an exe, projects like PyInstaller exist. I admit that this isn't an area I'm very familiar with and a tool I haven't played with. Not sure what additional considerations our this entails or just how self-contained that executable is.

I guess the short, and less specific to Python, version is that interpreted languages are fundamentally a different discussion. You can't run a VI simply by installing a G interpreter. Browsers include JavaScript engines, but not G engines.  

As for the question of whether there are reasons aside from protecting IP to want to create an exe, there's also the question of whether the user can change the application. I support manufacturing environments in a regulated industry, and the operators shouldn't be able to simply change the behavior of the program.  

For Python that means I can't just sling around .py scripts in user accessible locations where any joker can easily edit them in Notepad.  

For LabVIEW... Debatable. I could probably sell QA on the idea that password protecting block diagrams is sufficient deterrent, but I personally wouldn't really like to give every production line tech a dev license. I'm also not the only person setting these stations up, so a neatly packaged program with installer is really what I want to be handing off. Aside from those practical concerns, there is the question of cost that others have mentioned. We'd probably have to buy (sorry... suscribe to 🙄) a couple dozen development licenses for people that actually only need to - indeed are only allowed to - run code.

[santo_13]

---

@RTSLVU wrote:

---

@rolfk wrote:

---

@Jay14159265 wrote:

---

What if IP is not an issue? You can run a Python dev system on any computer for free and you can package, distribute, and install python apps on any computer. So is the ability to generate an executable only of interest if you have some IP you want to protect (or if you just like having an executable)? 

Well, installing an executable on a test machine is considerably easier as getting LabVIEW installed properly, all the drivers setup right, the LabVIEW source code installed in the right location, OpenG Toolkit, JDP Science Libraries, JKI Libraries, NI Labs Libraries this and that, and a myriad of other Toolkits and libraries installed on a machine. That in itself is a main selling point for creating executables, not to speak about an untrained operator messing up your program because he though changing that front panel just this little bit would be making the program run faster.

I would guess there are more LabVIEW applications that are internal and never get distributed than ones that are distributed / sold. 

---

Can't speak for the rest but we develop test systems that are working on manufacturing floors and the clients would be pissed if they had to deal with LabVIEW details to operate our machines.

---

I deploy my LabVEW executables on 10 ATE systems and countless other tests going on in the lab.

Can you imagine having to buy a LabVIEW license for every single computer that is running a test?

---

That might be one reason why NI has retained perpetual licenses for NI STS (NI's official ATE offering for Semiconductor Test) alone.

I agree, for custom ATE solutions, it is still subscription-based. Maybe if you're a large enough user of NI products, you might be able to negotiate a perpetual/lower-cost license with NI for those ATEs.

[billko]

Just when you think NI is trying to make LV ubiquitous by releasing a free version, they go and do something like yearly subscription and shoot themselves in the foot.

[BigApple0]

Just learn other languages.  There are plenty of good open source options out there.

[HorseBattery_Stapleguy]

---

@BigApple0 wrote:

Just learn other languages.  There are plenty of good open source options out there.

---

This.

I work in a company that has used LabVIEW Professional for a while and it was already hard to convince management to renew the SSP, at least occasionally. With this new model and the price increase, that's now officially gone out the window.

Now all our equipment that uses LabVIEW is in "legacy" and I'm being pushed to slowly replace everything and phase LabVIEW out of the workplace.

I've heard similar things from buddies in other companies / factories.

[WavePacket]

Huh. As a youngish LV programmer, this does give me pause. Is the only hard business benefit of LV the large number of stable libraries for instrument control?

[Kevin_Price]

I wouldn't say that's the *only* benefit.  But I also wouldn't say the instrument control libraries are universally excellent and stable.  Generally decent to pretty good though.

I've been doing LabVIEW for over 20 years and am in a company with a a big volume license agreement, so I expect to ride things out for the foreseeable future.  But to my thinking, the subscription model imposes a pretty extraordinarily high long-term commitment cost.   If you're first starting out, you have to seriously consider that you're committing to paying forever more in order to maintain your source code IP.   And that's a pretty steep price.

Sadly, much as I've liked LabVIEW, I really don't think it'll be a wise option for most newcomers under this new subscription model.   Hence my new signature.

-Kevin P

[WavePacket]

Yeah, I can understand that. It's ~2x to ~3x the cost of Matlab or visual studio IDE professional subscription, and I think both of those still offer a perpetual license too. That's concerning b/c I had been trying to prof. develop my labVIEW side. The main thing that I'm worried about is that you do not receive a perpetual license if you stop, you should just be frozen at that version.

I can't imagine this helping other new companies adopt LV for their needs, and tying myself to just LV seems like it would be risky. My work also does some .net ecosystem development, perhaps I should pivot my professional development to this side too. 

[Kevin_Price]

---

@WavePacket wrote:

The main thing that I'm worried about is that you do not receive a perpetual license if you stop, you should just be frozen at that version.

No, it's actually much worse than that, at least from my understanding.  When your subscription stops, so does all access to any LabVIEW dev environment licensed under the subscription model.  So you could no longer even *examine* your code, let alone modify it.

-Kevin P

[billko]

It's like ransomware, except instead of paying a one-time fee for getting everything to work again, you're paying an annual fee to keep it working.