LabVIEW Roadmap 2022 Q3

[OneOfTheDans]

@EricR, yes, counting days of usage would be better than counting days since activation, but it misses the point. The subscription model fundamentally assumes people are using LabVIEW regularly. In the example of the mechanical engineer, he's not going to suddenly change his career path at the end of the trial, but he'll probably stop using LabVIEW. Contrast that with the perpetual model where any company using a LabVIEW program had at least one old perpetual license lying with no strings or cost attached.

Practically, 3 non-developer engineers at my company bought the 1-year subscription to try LabVIEW, like you said. They all dabble with it occasionally, but generally aren't using it for their core work. When their subscriptions end, there is no justification to renew for their light use; NI has just shut the door on all 3 potential LabVIEW developers at my company.

[EricR]

@OneOfTheDans  - Thank you for the continued dialog.  Understanding the point is important to me.

It may be better to take this into a 1:1 voice/in-person discussion and then bring a summary back to the thread but let me make one more attempt here before taking it offline.

To me, there are two different motions in play.  They aren't the same and I don't want to link them together due to their differences.

1. Evaluation of software.  - Regardless of how the software is activated/sold, people want to explore the software to determine if it is something they can use, something that helps them with the job they need to do.  To make this evaluation, users need enough time to actually learn and use the product, given the other tasks they need to do their job. I think we agree that having a way to do this evaluation is important.
2. Usage of the product - Someone who has already made the determination that they benefit from using a tool needs access to the tool.  NI software is available for usage through a subscription.  It allows customers to use it when they need it, and not use it when they don't need it.  I don't consider "the door shut" because the subscription is easy to stop and there is no penalty to restart it at a later point.  This does not replace the need to be able to evaluate the product in the first place.

Both motions have value and I think there needs to be a way to do both, that works for people to do the different tasks.  To be clear, while the price point is lower on a subscription, I don't actually expect people to use it to do "evaluations".  I think being able to do evaluations needs to be independent of any "purchase" or its not really an evaluation. 

Now, related to the scenario where a user doesn't get enough value from a tool to justify using it again, I think that is on the company providing the tool (and the tool itself to some degree) to prove that it has enough value.  If it doesn't, then yes, I would expect any rational person to stop using a tool that isn't providing value.  With respect to a subscription, I have specifically been shown a number of scenarios where an annual subscription cannot be justified as the tasks that the tool is being used for don't fill an entire year.  The tool itself is actually a great tool and does significantly help with the tasks the individual is doing.  The problem is that those tasks are just some of the tasks that person needs to do in a year.  I believe alternatives for this scenario need to exist so that the justification for using the tool for those tasks makes sense.  I don't have an option for this scenario that I think makes sense today, but its one that I can clearly see the gap that needs to be addressed.

[mwatkins]

Hi Eric, 

Will NI allow a individual to host their own copies of runtime engine? 

IE; I'm considering purchasing a perpetual dev license to create a product. This product would require users to download LV RTE. I would like to host a copy of (for example) LV 2022 RTE for customers to download. Any problem with that? 

[billko]

---

@OneOfTheDans wrote:

---

@EricR wrote:

NI introduced the LabVIEW Community Edition specifically for the "tinkerers" back in 2018.  Why is that not a successful on-ramp for anyone looking to explore with LabVIEW right now?

---

As I read it, the Community Edition is for personal/home/open-source use only. It cannot be used for commercial purposes. I agree it's useful for tinkering & learning LabVIEW on the side. The gap is for engineers that are new to LabVIEW and want to tinker/develop code at work.

For example, a full-time LabVIEW developer with a subscription (or SSP) creates and typically supports large programs for his department. Over the years, various non-developer engineers want to try their hand at LabVIEW for a month by adding a new feature into that large program. This is commercial, so the Community Edition cannot be used. This is development, so Debug and Deployment cannot be used.

• With the old model, the non-developer could use an old license we had lying around that was already paid for - it was essentially free.
• With the new model, we need to either buy a subscription for the non-developer, or pay annually to keep a hot-spare license in case somebody wants to use it to learn LabVIEW. It's just enough cost & bureaucracy that we usually decide it's not worth the hassle, since the full-time developer can make the changes much faster anyway. Rinse & repeat; nobody learns or gets exposed to LabVIEW.

I suppose in theory that's what the 14 (30?) day trial is for, but I've never worked somewhere that people sit down to start a project and can commit the full 2 weeks. They'll spend a week installing LabVIEW, setting up Git/SVN, dealing with dependencies, then get pulled back into their normal work. A month later they pick up LabVIEW again and the trial is expired. Fair enough; you can't give indefinite trials. But this is why I think the new licensing model eliminates the on-ramp to LabVIEW.

---

If you are referring to my remarks about the LV Community Edition licensing scheme, I was positing that if we had paid attention to the licensing scheme of LV Community Edition, we would have seen that it was a dress rehearsal for the future of LV licensing.  It seemed to be a convenient way for NI to work out the kinks in the subscription licensing model before it went live.

[EricR]

I'm not sure what you mean by "host" in this scenario.  The LabVIEW RTE has its own "installer" and its own set of package files. You should be able to "include" the LabVIEW RTE with your application when you deploy it.  If you don't do that, LabVIEW has a built-in feature that will attempt to identify the RTE that you need when your executable is run and point the user to the download page on NI.com.  It understandably works better when you just include the RTE in your product installer.

If you are intending to host a download page for a specific RTE on a different website, I would prefer you didn't do that.  We try to keep those installers updated with security patches and bug fixes so I want the google analytics engines to point people to the ones on NI.com as much as possible. 

That said, I don't think there is anything in the EULA or other legal documents that prevents you from hosting the download as long as you don't modify it from NI's original version.  I know of several places where they have an internally-hosted copy because inside the facility the networked computers don't have access to external internet downloads, and that is always totally fine, again, as long as its an exact copy of the NI download and has not been modified.

[OneOfTheDans]

---

@EricR wrote:

To me, there are two different motions in play.  They aren't the same and I don't want to link them together due to their differences.

1. Evaluation of software...
2. Usage of the product...

...a number of scenarios where an annual subscription cannot be justified as the tasks that the tool is being used for don't fill an entire year...

...I don't have an option for this scenario that I think makes sense today, but its one that I can clearly see the gap that needs to be addressed.

---

Learning any language/tool is like a ladder. It starts at evaluation (which NI has excellently covered with the 45 day trial & Community Edition). It ends at full-time usage (which is covered by the current subscription model). But in the middle of the ladder are those part-time tasks/scenarios that don't justify an annual subscription. If there's a gap in those middle rungs, few people will keep climbing toward full-time usage of the tool. This was what I meant originally about the new model eliminating the on ramp.

---

[cy...]

not sure how subscription simplifies things for users, but definitely seemed that "up-to-date application" access cost has increased 1 fold for SPB. SSP maintenance for SPB used to be ranging from 5-6k annually and the switch from perpetual to subscription increases it to 9-10k. the one-time cost offer doesn't make anything better. 

code maintenance and fixes are still possible with perpetual and expired SSP, as long as same version and without future released fixes (although bugs can be from the software itself), can't say the same for subscription. outsourcing seemed to be impossible also, since code acquisition require not only debug/deployment subscription, but module as well

the worst part being the switch is not communicated to the users, hence now SPB users have to decide which codes have to be relegated to EOS status, due to the increased cost

ultimately, users (internal developers) and customers seemed to have to pay more for less, no?

[rwunderl]

Or at least pay more for the same, anyway.

@EricR, you continue to miss (or ignore) my point. @tst, @Kevin_Price, and @OneOfTheDans get me.

---

@OneOfTheDans wrote:

...renewing a perpetual every 3-4 years cost about the same as just keeping your SSP active (by design, I'm sure!). And I consider annual SSP renewals the same as subscriptions (again, not including the new threat of deactivation).

---

My point is that even though the cost with the previous model may have been similar when I upgrade every few years, I didn’t HAVE to upgrade at all. Nowadays I’m FORCED to upgradepay to continue to use the software even if I don’t want a newer version OR your support.

I totally agree with @OneOfTheDans that scrounging around for old perpetual licenses is a necessary pastime when you're trying to get work done without all the red tape.

I’m currently supporting a production application developed in LabVIEW 8.2, and the developer seats are still happily licensed…

[cy...]

I still think it is more for less, for some software, percentage-wise the subscription cost is closer to that of inactive SSP 50% than active SSP 25%. so, it will be more than the previous buy 1 & maintain and buy 1 every 3-4 years; as cost wise, it is closer to buy 1 every 2 years, and no access once expired

[rwunderl]

---

@cy... wrote:

... and no access once expired

---

Punto final. This is the rub. You pay and you pay and it still locks you out in the end.

You lease a car if you want the shiniest toy and you have the money to do so. You buy a less-expensive car if you want something that will last 10 years and not break the bank. (Even if you still need a loan to do it!) But at least those crooked car dealers still give you that option. You are also free to have it serviced elsewhere...