LabVIEW subscription model for 2022

[WavePacket]

One thing that has struck me (as a newcomer) is that all of "senior devs" that I know who have been involved deeply in LV for many years on this forum are all pretty united in their concerns. Those optics alone make me concerned.

[Jay14159265]

WOW things are happening fast!

So yesterday my business got word that the large DoD contractor that we work with has dropped the internal guideline that all new T&M systems for R&D, Reliability, and Production groups should provide a software interface for test stand and labview. The new guideline says that all new T&M systems prefered api is to be written in ... wait for it ... it costs nothing to install and use ... the IDE is free for commercial use ... it starts with a p ... it's not perl ... it's not php ... its python!

So contractors no longer have to deliver any labview code for T&M systems, this is HUGE!

Apparently it's not just the developers that think having to pay a subscription for your own code base is a bad idea. 

[WavePacket]

^wow. Some damage has already been done...

Edit to add that I'm someone who really enjoys LV. Even beyond whether it's value justified (and I haven't seen how this benefits anyone except NIs stockholders at the moment), does LV really have the leverage to do this over what .net and python offers? I'm not sure it really does, and that's what worries me most about investing myself as deeply into LV as I thought I was. 

I want LV to succeed, do hear me on that. I'm worried this will drive people and companies away, which I would find really sad.

[BertMcMahan]

---

@Jay14159265 wrote:

WOW things are happening fast!

So yesterday my business got word that the large DoD contractor that we work with has dropped the internal guideline that all new T&M systems for R&D, Reliability, and Production groups should provide a software interface for test stand and labview. The new guideline says that all new T&M systems prefered api is to be written in ... wait for it ... it costs nothing to install and use ... the IDE is free for commercial use ... it starts with a p ... it's not perl ... it's not php ... its python!

So contractors no longer have to deliver any labview code for T&M systems, this is HUGE!

Apparently it's not just the developers that think having to pay a subscription for your own code base is a bad idea. 

---

That's interesting; as someone who's done work for DoD contractors, Python is a bit of an issue since you can't really compile it into an executable, as I understand it. Apparently it's some kind of security risk due to modifiable code, but I'm not a Python guy so maybe I'm misunderstanding what our IT guys told us.

[ConnerP]

---

@BertMcMahan wrote:

---

@Jay14159265 wrote:

WOW things are happening fast!

So yesterday my business got word that the large DoD contractor that we work with has dropped the internal guideline that all new T&M systems for R&D, Reliability, and Production groups should provide a software interface for test stand and labview. The new guideline says that all new T&M systems prefered api is to be written in ... wait for it ... it costs nothing to install and use ... the IDE is free for commercial use ... it starts with a p ... it's not perl ... it's not php ... its python!

So contractors no longer have to deliver any labview code for T&M systems, this is HUGE!

Apparently it's not just the developers that think having to pay a subscription for your own code base is a bad idea. 

---

That's interesting; as someone who's done work for DoD contractors, Python is a bit of an issue since you can't really compile it into an executable, as I understand it. Apparently it's some kind of security risk due to modifiable code, but I'm not a Python guy so maybe I'm misunderstanding what our IT guys told us.

---

Without further knowledge from Jay, my guess is they want python bindings, not necessarily for the system to be developed in python. Most of the big name python packages are just APIs for accessing libraries written in C(++).

[Jay14159265]

---

@BertMcMahan wrote:

That's interesting; as someone who's done work for DoD contractors, Python is a bit of an issue since you can't really compile it into an executable, as I understand it. Apparently it's some kind of security risk due to modifiable code, but I'm not a Python guy so maybe I'm misunderstanding what our IT guys told us.

---

So this relates to hardware, Test and Measurement equipment. For T&M equipment they need to be able to talk to it so they used to prefer a lvlib with all the hardware interface VIs for the API, and now they dropped that preference. They want the hardware interface drivers to be in, or have a python wrapper, which is a huge shift. It sounds like they are moving away from test stand and labview as the defacto standard for hardware interaction at least in the R&D, Reliability and Production groups. 

[Jay14159265]

---

@ConnerP wrote:

---

---

Without further knowledge from Jay, my guess is they want python bindings, not necessarily for the system to be developed in python. Most of the big name python packages are just APIs for accessing libraries written in C(++).

---

Bingo

[Taggart]

I read the writing on the wall several years ago and started learning Python and focusing on transferable skills, like TDD, unit testing, Refactoring, CI and all the DevOps stuff. Someday I will no longer be a LabVIEW Dev and just be a general software consultant. In the end, I'll be ok, but it makes me sad. I quite enjoy LabVIEW, but the end just seems inevitable. 

I still enjoy programming in LabVIEW and I'll ride the LabVIEW train until it derails, but that point is quickly approaching.

Any new people who are jumping on that train now, I don't what they are thinking. It's pretty obvious it is heading for a brick wall. NI has the power to change that, but seems blinded by its ambition not for engineering, but for short-term monetary gains. I'll say it again, there is a reason they picked green as their new color, that appears to be all they can see.

The fact that they finally saw the error of their ways with NXG gives me some hope. NI is capable of changing directions. I just hope it's not too late.

[RTSLVU]

---

@Jay14159265 wrote:

The new guideline says that all new T&M systems prefered api is to be written in ... wait for it ... it costs nothing to install and use ... the IDE is free for commercial use ... it starts with a p ... it's not perl ... it's not php ... its python!

So contractors no longer have to deliver any labview code for T&M systems, this is HUGE!

Apparently it's not just the developers that think having to pay a subscription for your own code base is a bad idea. 

---

Yep as I said before, I have been with this company for >30 years and it ALWAYS comes down to money.

NI will lose this battle in my company too, I am preparing to freeze on LabVIEW 2021.

[Kevin_Price]

[out of context remark below.   I queued it up in the morning but didn't get a chance to get back to it until now.   Meanwhile, lots of other discussion.  Anyway, here it is, remarking on my prior comments about needing to keep subscribing even to be able to "look at" your source code]

To be fair, I hadn't accounted for the debug license option in my prior remarks.

It would be an additional one-time cost, but it *would* allow long term access for code examination and bug fixes.  As I understand it, you'd still need a fresh subscription license if you wanted to add new features or modify code to accommodate a new replacement instrument.

I expect these debug licenses would be version-locked though.  So I'd think that for each LabVIEW version used for development under the subscription model, you'd be considering a distinct version-specific debug license.

-Kevin P