LabVIEW Roadmap 2022 Q3

[billko]

---

@rwunderl wrote:

---

@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...

---

To put it bluntly, it's legally sanctioned ransomware.

[EricR]

Thanks @OneOfTheDans .

I normally don't want to "solution" on something but I am interested in checking for my understanding.

Would a "smaller-window-of-time subscription, at a lower price", fill in those potentially missing rungs in your metaphorical ladder? 

[Jay14159265]

---

@EricR wrote:

Thanks @OneOfTheDans .

I normally don't want to "solution" on something but I am interested in checking for my understanding.

Would a "smaller-window-of-time subscription, at a lower price", fill in those potentially missing rungs in your metaphorical ladder? 

---

You are trading your developer community for higher profit margins. There are people that enjoy writing code and do it in their free time but will not do it if they have to pay for it. Any way you slice it the software subscription service is a burden for those in, and those interested in joining the LabVIEW developer community.  So while subscription services that block access make total sense for business, they don't make much sense for developers, so developers will go elsewhere.

Perhaps a better community edition license will make things better. How about you open it up and say you can use LabVIEW community edition free for business and individuals that do less than <insert number here> in revenue per year. 

[OneOfTheDans]

---

@EricR wrote:

Would a "smaller-window-of-time subscription, at a lower price", fill in those potentially missing rungs in your metaphorical ladder?

---

Yes, I think it could. For someone using LabVIEW occasionally (once or twice a year for a month), it's much more reasonable to pay only for what you use. In turn they'll hopefully start using LabVIEW more often and become a full-time developer and advocate.

But don't overlook the convenience factor - if you're expecting end users to be starting/stopping subscriptions throughout the year, it needs to be dead simple. Right now I need to get a formal quote from NI, submit that to our purchasing department, get approval, have them generate & send a PO, then NI will send back a license key.

[BertMcMahan]

Autodesk's Fusion 360 has a free community edition AND a "startup" edition that's free for businesses under $100k in revenue (IIRC) AND a free academic version.

In other words... basically everyone uses Fusion 360 unless they have another CAD package through work (or are so used to Solidworks that they ponied up for a license).

Granted there are some people using the FOSS CAD tools, but you don't see nearly as many people using that as using Fusion360. IMHO, it's a great license model that would be cool to see here too.

Since NI is very much focused on their super big clients, I can't imagine they'd lose too much revenue by giving it to hobbyists or very small startups for free. I have no insight to their numbers though, so what works for CAD might not work for a programming language.

[cy...]

@EricR wonder if you can consider exploring tokens for simplifying licensing and subscription. Developers subscription to be given set number of tokens per annum (per tier subscription and can carry forward if unutilized) to use NI software, tokens are spent based on hours of usage and software used.

For example, tier 1 allocates N tokens (N = sum of n's) totaled in hours of utilization per year, which developers can use for let say:

• n for LVP
• 2n for LVP + RT or LVP + VDM or TS + LV
• 3n for LVP + RT + FPGA (local compiler doesn't count)
• a reasonable top up amount to accommodate sudden spike of n demand
• a reasonable annually deductible amount of n to maintain active status to continue access, receive upgrades and updates

tiers can range from light (single developer) to heavy (team of developers). a license server could probably be useful in this case to check in/out licenses, and can double as a local repository for keeping NI software packages up-to-date. and the annual subscription cost should probably be less than that of active SSP, since subscribers have to lose perpetual access.

maybe this can offer much more applicability, simplicity or even incentive for proficiency and efficiency; and make subscription more palatable for some users

[Intaris]

---

@Jay14159265 wrote:

---

@EricR wrote:

Thanks @OneOfTheDans .

I normally don't want to "solution" on something but I am interested in checking for my understanding.

Would a "smaller-window-of-time subscription, at a lower price", fill in those potentially missing rungs in your metaphorical ladder? 

---

You are trading your developer community for higher profit margins. There are people that enjoy writing code and do it in their free time but will not do it if they have to pay for it. Any way you slice it the software subscription service is a burden for those in, and those interested in joining the LabVIEW developer community.  So while subscription services that block access make total sense for business, they don't make much sense for developers, so developers will go elsewhere.

Perhaps a better community edition license will make things better. How about you open it up and say you can use LabVIEW community edition free for business and individuals that do less than <insert number here> in revenue per year. 

---

Ma son actually started programming in the last few years. He had dabbled in using the game engine "Unreal Engine". Their blueprint portion of their code reminds me a lot of LabVIEW, graphical connections between individual functions.

Anyway, my point was: Unreal engine is free to use. If a game is published and earnings rise above X, only then does Epic get paid. They are then entitled to a certain % of profits. Aside from that, the development suite is completely unlimited and free.

Spoiler

Text taken from: https://www.unrealengine.com/en-US/eula/unreal

a. Royalty-Free Distribution
As described in this Section 3(a), you may Distribute certain Products to certain persons or entities without any obligation to pay us royalties, even if you are monetizing that Distribution.

i. Non-Engine Products (e.g., Rendered Video Files)
You will not owe us any royalty payments for Distributing Products that (i) do not include any Engine Code, (ii) do not require any Engine Code to run and (iii) do not include Starter Content in source format (“Non-Engine Products”) to any person or entity.

This means, for example, you will not owe us royalties for Distributing:
● rendered video files (e.g., broadcast or streamed video files, cartoons, movies, or images) created using the Engine Code (even if the video files include Starter Content) or
● asset files, such as character models and animations, other than Starter Content, that you developed using the Engine Code, including in Products that use or rely on other video game engines.

Please note that certain assets that we make available under separate agreement are available for use only with Unreal Engine.

ii. Indirect Revenue
You will not owe us any royalty payments for Distributing Products to any person or entity if the Products do not directly generate revenue -- i.e., no revenue is attributable to any Product access, including features and functionality within the Product, or to any in-Product benefits.

This means, for example, that Distribution of a free car configurator app (a Product) used to sell cars will not result in royalties owed on sales of the cars themselves, even if the sales are made via the configurator app.

iii. Other Royalty-Free Distributions
You will not owe us any royalty payments for Distributing Products:

A. To the legal entities that are part of your company group, such as a parent company or a subsidiary, for their private use, so long as those entities do not further Distribute the Products outside of your company group. *

This means, for example, applications (which would be Products) you create for internal use within your company can also be shared with your parent company, your subsidiary, or another subsidiary of your parent company.

B. To clients who hired you to develop the Products for them, for their private use, so long as your clients do not further Distribute the Products. *

This means, for example, if you are hired to create an application (a Product), you can share that application with your client.

C. To other third parties who are separately licensed by us to use the Engine Code, through either the Unreal Engine Marketplace or through a fork of Epic’s GitHub UnrealEngine Network.

This means, for example, you may Distribute a plugin, modding tool, or editor to end users through the Unreal Engine Marketplace or through Epic’s Unreal Engine GitHub repository.

* If your Product includes Engine Tools, it may only be Distributed pursuant to (C) above.

“Engine Tools” means the (i) editors and other tools included in the Engine Code; (ii) any code and modules in either the Developer or Editor folders, including in object code format, whether statically or dynamically linked; and (iii) other software that may be used to develop standalone products based on the Licensed Technology.

b. Royalty Bearing Distribution
You may make other Distributions of Products, but unless described in Section 3(a), all Distributions of a Product will be subject to the terms of the attached Royalty Addendum. Additionally, any advance royalty payment you receive to develop such a Product will be subject to the Royalty Addendum. However, as described more fully in the Royalty Addendum, you will never owe us royalty payments under this Agreement unless a Product directly generates more than $1,000,000 USD in gross revenue.

This means, for example, that you may owe royalties to Epic for Products that are sold to the general public or for off-the-shelf Products that you sell privately to third parties, whether directly by you or through a distributor or publisher.

I'm not saying it's a model which would work with LabVIEW (market sizes are significantly different I would assume), but there are precedences like this out there. The ability to download and perfectly legally use the "Unreal Engine" suite (which is an incredibly impressive piece of software BTW) is a great way of getting people into that toolchain.

[Kiwi-wires]

A Pro Test workflow license in my currency is approx. $7200  / year. I only really need/use LabVIEW & TestStand.

For a full time dev, at 45 weeks per year is $160 per week. $32 per day, per hour $4.  

However I work at a smaller businesses. My product engineering role has many other tasks that are not test development. 

• Dealing with rejects
• Sourcing alternatives
• PLM management / ECOs
• Test Data analysis
• NPI
• Designing & Fabricating test systems / hardware etc
• Creating Work instructions
• Maintaining older LabVIEW code / test systems and test systems written in other languages (C# mainly)
• Actually doing some Teststand and LabVIEW dev. 

I am the only guy who knows LabVIEW/TestStand and that is a risk if I get hit by the preverbal bus, so the other product software guys would prefer me to develop in a language that they know / is easier for them.  I am also quite interested in SystemLink for getting all our test data into the cloud, but my manager is already questioning the cost of LabVIEW license. If I paid $50 for 24 hours access (or $200 per week) as I needed it, it would easier to get past manager and would be more a software as a service. I would have to work 144 days (26 weeks) before its more expensive than the annual sub, and that isn't going to happen. 

When I joined a previous company they did an update every 5 years (I got them to switch to SSP - as it was a similar cost over the same time frame). At the end of that time, we still had access to the older version. While its nicer for NI to only support the latest versions (and we devs get new features), I have had some issues updating older LabVIEW code in past. 

At an another company I did a project in NXG - I felt it was starting to get useable and had some good merits (The frustrating part was LabVIEW features that had not been ported across yet). Then NXG got canned as soon as I finished the project. I am not sure how many more years dev it required to get more parity with LabVIEW features, but I felt it was not too far off. 

At my current company, two products that use TestStand are EoL, which only leaves one mature product that uses TestStand. At this stage I am intending to evaluate alternates to TestStand (not sure if they even exist). Which then means you risk losing the potential of hooking me into SystemLink as well... The company is migrating to salesforce and I intend to have a look to see what SystemLink competitors are. Also the software guys do a lot of cloud work so will see what they suggest. 

If you check out my thread here: https://forums.ni.com/t5/LabVIEW/ChatGPT-AI-Assisted-Programming-with-LabVIEW-Discussion/td-p/428522... it is also much easier for me to change to another language than the software guys to learn LabVIEW. So as much as I enjoyed programming in LabVIEW the last 20 years... its seems time to brush up on my C# & Python skills. 

I understand that NI has to make money - but there are external pressures that are making re-evaluate the value proposition of NI products. In the past I felt the value proposition has been worthwhile. My feeling from reading this thread is that LabVIEW devs are concerned about "walling" in existing users and holding their source code to ransom with a 1 year SSP, while preventing more widespread adoption of LabVIEW due to the cost barriers vs alternatives. Sometimes I just need a look at the test code to confirm what its doing when I am inspecting reject data from a unit and figuring out what happened. If its going to cost a year's SSP to do that I just won't look at the source code. 

TLDR: NI has to evaluate is value proposition against the competition, rather than what their existing customers have in the past and are prepared to pay today. 

[BertMcMahan]

---

@Kiwi-wires wrote:

Sometimes I just need a look at the test code to confirm what its doing when I am inspecting reject data from a unit and figuring out what happened. If its going to cost a year's SSP to do that I just won't look at the source code. 

---

I fully agree with the rest of your post, but just FYI they have stated they're updating the license of the Community Edition to include reviewing commercial code without modifying it. They are ostensibly trying to permit viewing of old source code without requiring a paid SSP.

[TiTou]

Yes, but currently it is incredibly difficult to - both - download AND activate the community edition.