LabVIEW subscription model for 2022

[Newton_TP]

I think you're taking a sizeable risk. I suggest focusing on a text based language and getting really familiar with it. That should translate pretty well to other text-based languages as the landscape of programming changes over the years. Going to LabVIEW from a text based language is relatively trivial once you get dataflow down. I'm like you - I learned VHDL before LabVIEW and being familiar dataflow model made it easy.
If you focus on LabVIEW the whole time I think it would be a harder transition going the other way.

But, I'm just one guy and my opinion is worth 2 cents at best (probably less). Might get a couple bucks worth of opinions before you buy into any of it. 🙂

[Will_Crowe]

Thanks a million, Rolf.

I actually didn't know about the 'community edition'...which by the sound of it would allow you to continue to run a daq application that doesn't need to be edited, which in the real world is never the case, but could be the case for a few months?

It's just odd that I found out about the new licensing model whereby LV becomes un-usable unless you keep paying, and then there are other versions which you can 'kind of' use...to do 'some stuff'. It's oddly vague, isn't it? And I'm finding it hard to get good answers from the local vendor where I am, so I appreciate your insights.

Will

[Kevin_Price]

I'm one of the old-timers who groused about the new subscription model early on and adopted a forum signature that continues expressing my opinion.  

    Let me present a partially unfair analogy -- but only partially.  Let's suppose it was the 1980's, you loved tinkering with cars and were planning a career as a mechanic.  Let's also suppose that you especially enjoyed tinkering with carburetors.  Should you have made carburetors your specialty skill as you prepared for a career as a mechanic?   And in a partially similar way, should you make LabVIEW your specialty skill as you prepare for a career in programming?  

    I fear that LabVIEW today is on a trajectory somewhat like carburetors were on about 35 years ago.  Staying fairly common for a while to support a very large legacy installation base.  But increasingly less common for new builds, which will gradually replace today's installed base.

    As time goes by, being primarily a carburetor expert becomes less of a resume-enhancer and more of a red flag out in the general job market.   While there will continue to be specialty shops that will value your legacy expertise, they will keep being fewer and farther between, harder to find and get into.

    I call it a fear, but I don't think it's an outlandish one.  I think it's pretty plausible and thus would not actively steer people toward a LabVIEW-centric career these days, not if you want it to propel you for a couple decades or so.  Look before you leap and all that.

    In my opinion, it isn't LabVIEW itself that's the problem.  It's the combo of subscription-only and fairly dramatic price increases that are building a large barrier to entry.  And for those that have already entered and have a big stake in the game, there are now much larger ongoing cost pressures to reduce licenses, which leads to reducing the number of dedicated developers.  It turns into musical chairs where seats keep getting removed and not everyone finds a place to land.

    Another thing to consider:  while every programming language is uniique to some extent, LabVIEW is more unique than most.  The graphical nature in general, the dataflow model, the near-absence of arcane syntax rules, the binary file format that leads to difficult diffs and merges, etc.  There's a fair bit of special knowledge one needs to be good in LabVIEW that doesn't really carry over to common text languages.  It's less of a head start toward learning C# than if you were coming from Python.  

-Kevin P, 

P.S.   Mine is a fairly pessimistic view.  Consider other opinions too, such as the recent more optimistic one from NI insider and forum contributor extraordinaire Darren Nattinger.  He's certainly better situated to know more than I do, and you can count on the opinions he shares to be genuine.

[beuvink]

My 2 cents on this topic.

cent 1: LabVIEW is a great tool, bad NI is making it a bad choice for future investments…

cent 2: indeed there are many legacy systems that will need maintenance. Not looking at it as carburetors. But COBOL comes to mind. As the places that really need to maintain LabVIEW systems get less, so will the amount of people that will be able to do so..

so for the next decade, with good knowledge there are definitely opportunities, maybe under new management things might change. If you already have significant knowledge, keep up the skills. But don’t make it the only piece of knowledge you have..

[Taggart]

---

@Kevin_Price wrote:

I'm one of the old-timers who groused about the new subscription model early on and adopted a forum signature that continues expressing my opinion.  

    Let me present a partially unfair analogy -- but only partially.  Let's suppose it was the 1980's, you loved tinkering with cars and were planning a career as a mechanic.  Let's also suppose that you especially enjoyed tinkering with carburetors.  Should you have made carburetors your specialty skill as you prepared for a career as a mechanic?   And in a partially similar way, should you make LabVIEW your specialty skill as you prepare for a career in programming?  

    I fear that LabVIEW today is on a trajectory somewhat like carburetors were on about 35 years ago.  Staying fairly common for a while to support a very large legacy installation base.  But increasingly less common for new builds, which will gradually replace today's installed base.

    As time goes by, being primarily a carburetor expert becomes less of a resume-enhancer and more of a red flag out in the general job market.   While there will continue to be specialty shops that will value your legacy expertise, they will keep being fewer and farther between, harder to find and get into.

---

Things fail gradually, and then suddenly...

[Taggart]

---

@Kevin_Price wrote:

    Another thing to consider:  while every programming language is uniique to some extent, LabVIEW is more unique than most.  The graphical nature in general, the dataflow model, the near-absence of arcane syntax rules, the binary file format that leads to difficult diffs and merges, etc.  There's a fair bit of special knowledge one needs to be good in LabVIEW that doesn't really carry over to common text languages.  It's less of a head start toward learning C# than if you were coming from Python.  

-Kevin P, 

 The positive side to this statement is that if you can figure out how to do software engineering in LabVIEW, then doing it in a text-based language is trivial. It's kind of like engineering school where you learn to do everything the long way and then at the end they are like "oh here's a shortcut." LabVIEW is the long way.

[billko]

---

@Taggart wrote:

---

@Kevin_Price wrote:

    Another thing to consider:  while every programming language is uniique to some extent, LabVIEW is more unique than most.  The graphical nature in general, the dataflow model, the near-absence of arcane syntax rules, the binary file format that leads to difficult diffs and merges, etc.  There's a fair bit of special knowledge one needs to be good in LabVIEW that doesn't really carry over to common text languages.  It's less of a head start toward learning C# than if you were coming from Python.  

-Kevin P, 

 The positive side to this statement is that if you can figure out how to do software engineering in LabVIEW, then doing it in a text-based language is trivial. It's kind of like engineering school where you learn to do everything the long way and then at the end they are like "oh here's a shortcut." LabVIEW is the long way.

---

I've found that the paradigms are so different (dataflow versus procedural) that they aren't directly translatable, and that something easily done in LabVIEW can sometimes be hopelessly (for me) difficult in a text-based language.

[JimB.]

---

@Will_Crowe wrote:

Thanks a million, Rolf.

I actually didn't know about the 'community edition'...which by the sound of it would allow you to continue to run a daq application that doesn't need to be edited, which in the real world is never the case, but could be the case for a few months?

It's just odd that I found out about the new licensing model whereby LV becomes un-usable unless you keep paying, and then there are other versions which you can 'kind of' use...to do 'some stuff'. It's oddly vague, isn't it? And I'm finding it hard to get good answers from the local vendor where I am, so I appreciate your insights.

Will

---

As I recall, a tweak to the Community Edition license was made allowing you to view your code. This was in response to the outcry of folks that brought up the point that the subscription model essentially holds your source code hostage since you cannot even look at it without a working copy of LabVIEW. Previously, the license did not allow for commercial use in any context.

I believe you would be out of compliance if you use the Community Edition to run your (commerical) application. Ideally, I would say you should be using standalone executables to run most of the time, but NI puts LabVIEW into a very strange area with some of these policies:

• You can only use the IDE if you pay a subscription. Okay... that's not so bad and just like many other paid IDEs.
• You can compile a standalone executable and deploy that with no further ongoing costs; access to the runtime engine is free. Again, a lot of other programming environments work this way.
• You are only able to create an executable in the highest priced version of the IDE, or with a pricey add-on license... Say what now? That's table stakes for any other programming environment for a compiled language! (If there is something else similar out there, I'm not familiar with it.)

LabVIEW is unique in many ways, not least of which is that your code runs inside of the IDE itself and that it seems, judging by posts here, that many people actually use it that way. I don't, but I can certainly see how the licensing model almost seems to encourage it. For users that do use it this way, it does indeed make the move to subscriptions even harder to swallow.

[billko]

---

@JimB. wrote:

---

@Will_Crowe wrote:

Thanks a million, Rolf.

I actually didn't know about the 'community edition'...which by the sound of it would allow you to continue to run a daq application that doesn't need to be edited, which in the real world is never the case, but could be the case for a few months?

It's just odd that I found out about the new licensing model whereby LV becomes un-usable unless you keep paying, and then there are other versions which you can 'kind of' use...to do 'some stuff'. It's oddly vague, isn't it? And I'm finding it hard to get good answers from the local vendor where I am, so I appreciate your insights.

Will

---

As I recall, a tweak to the Community Edition license was made allowing you to view your code. This was in response to the outcry of folks that brought up the point that the subscription model essentially holds your source code hostage since you cannot even look at it without a working copy of LabVIEW. Previously, the license did not allow for commercial use in any context.

I believe you would be out of compliance if you use the Community Edition to run your (commerical) application. Ideally, I would say you should be using standalone executables to run most of the time, but NI puts LabVIEW into a very strange area with some of these policies:

• You can only use the IDE if you pay a subscription. Okay... that's not so bad and just like many other paid IDEs.
• You can compile a standalone executable and deploy that with no further ongoing costs; access to the runtime engine is free. Again, a lot of other programming environments work this way.
• You are only able to create an executable in the highest priced version of the IDE, or with a pricey add-on license... Say what now? That's table stakes for any other programming environment for a compiled language! (If there is something else similar out there, I'm not familiar with it.)

LabVIEW is unique in many ways, not least of which is that your code runs inside of the IDE itself and that it seems, judging by posts here, that many people actually use it that way. I don't, but I can certainly see how the licensing model almost seems to encourage it. For users that do use it this way, it does indeed make the move to subscriptions even harder to swallow.

---

Way back when, the only way to run LabVIEW was through the IDE.  There was no such thing as executables.

[Yndigegn]

Hi

The Application Builder was introduced quite early in the LabVIEW (r)evolution story.

Attached is the release notes for version 3.1 which came out in 1994. It refers to an even earlier 3.0.1 version ( probably released in 1993 ).

The original file was in WRI format. I saved it in WPD format which opens fine in Word.

The document includes this paragraph :

"Providing Help Information

As a VI developer, it is your responsibility to document your VIs for users, including all information necessary to load and operate the VIs. The regular LabVIEW 3.1 documentation set is copyrighted material and should not be shipped with the applications you create."

Regards