LabVIEW subscription model for 2022

[Ants_at_work]

Anyway LV is not the main source of income for NI. Why not make LabView OpenSource = boost Hardware sales + decrease dev costs?
Or give subscription for free to anyone committing at least 1 push request.

[daphilli]

Please tell me more about the hybrid compiler. What is it? What are it's advantages and disadvantages?

[daphilli]

How is Emerson calculating that? R&D/Revenue or R&D/GrossProfit? 20%-30% R&D/GrossProfit is normal in the Semiconductor Industry space.

If Emerson believes they will yield sustained growth for investors by cutting R&D 50% to 10% R&D/GrossProfit in NI's market space then they've strayed too far from their core-market expertise. This is not a static market, like the Electrical construction hardware market, where product requirements have minimal changes over long spans, such as 30 years. The failure of Emerson's management to comprehend this distinction demonstrates a lack of advanced business skills.

NI's R&D requirements are driven by the needs of the industries they support, such as a Semiconductor Industry. High percentage R&D investments will be required until Moore's Law runs out from collision with insurmountable limits in materials Physics. Until then, advancements in semiconductor process technologies will ripple through the market as changes in chips, interfaces, operating systems, end products, etc., requiring ongoing R&D investments from the companies that support them.

LabVIEW is a mission-critical tool for the many strategic industries that depend on. If Emerson has no competent vision for advancing LabVIEW profitably, then what are they buying NI for? Perhaps they would be better off investing in a manufacturer of hardware for brewing beer, or something of that sort consistent with their business acumen.

[daphilli]

I agree, maybe. Whether LabVIEW is a main income source for NI or not is irrelevant. What is relevant is whether it is profitable or not. If LabVIEW is not profitable for NI, then taking it Open Source could be the best solution. The viability of that solution depends on whether the community of contributing developers is big enough to keep pace with OS rollouts from Microsoft, Apple and Linux. Making the best strategy choice depends on numbers that are not available to me. One of those sets of numbers is the contribution that availability of LabVIEW makes to hardware sales.

This discussion reminds me of the business case history when National Semiconductor released the first 32bit microprocessor but failed to yield sales because there was no accompanying development software infrastructure to support it.

[rolfk]

---

@Ants_at_work wrote:

Anyway LV is not the main source of income for NI. Why not make LabView OpenSource = boost Hardware sales + decrease dev costs?
Or give subscription for free to anyone committing at least 1 push request.

---

I would love to get a chance to try a few things in the LabVIEW source code but open sourcing LabVIEW is most likely a wet dream.

1) There are not many people out there who know LabVIEW well enough AND know C++ on a level that they make even a small chance to change anything on that code base that doesn’t cause at least half a dozen problems for each bugfix or improvement they try to implement.

2) Some of the code is licensed by Ni and they don’t own the right to distribute its source code at will.

3) Closed source projects tend to accumulate over the course of time all kinds of artifacts that are not suited for public consumption. Developer remarks that may have been considered acceptable 25 years ago but are nowadays seen as rude or derogatory, references to internal bug databases, private crypto keys, passwords, etc. etc.

Cleaning all that up would require a massive investment. The entire source code needs to be carefully reviewed, both by legally knowledgable people as well as developers for general sanitation. Parts that can’t be legally open sourced need to be either cleanly removed with the result of less functionality or try to replace it with an open source compatible solution.

These points alone make it already very difficult. Who pays that huge effort for source code review and legal investigation? Why should NI invest that much money to then throw it away? Without a significant contribution by a fully paid team of professional developers, that project would simply end up filling massive amounts of server space on many user created clones where nobody ever looks at anymore after having peeked in once and coming to the conclusion that they only understand Bahnhof,

[Yndigegn]

If curious about the hybrid compiler introduced in LV 2010 SP1 then please read the full thread :

https://forums.ni.com/t5/LabVIEW/LabVIEW-2010-slow-vi-save-performance/td-p/1223632/page/6

Regards 

[Ants_at_work]

---

Why should NI invest that much money to then throw it away?

---

It's called corporate strategy and marketing. You invest 10% of the company to gain x2 value from other business income sources. 

1. NI hardware is expensive comparing to other alternatives. Adding the support for the easy-to-use no-cost graphical IDE into the sale pitch will make it competitive again.
2. NI RnD team would gain more orders, as more companies will want to use NI Hardware, but some would like to outsource LV programming.
3. Increase the ecosystem popularity, so statistically, there is a higher chance of anyone stumbling upon NI hardware for their rigs and setups.
4. Decrease dev costs to managing 1 main git branch and NI Hardware support.
5. Decrease the costs for support team (emails, telephone). Now most of the questions will be solved by community.
6. Decrease the costs of distributing and managing different licenses through the network: student, community, base, pro...
7. Now NI has a base of customers highly invested into hardware and users who still know how to use LabView and will use it for the next 1-2 years (until ChatGPT clones will take over). When small and mid size devs will leave there will be less people to dig into the core code. 
   
   We all can agree that current future prognosis for LabView with modern subscription politics is the decrease in overall popularity and ecosystem. 
   https://www.youtube.com/watch?v=TAsdr4ypBko
   
   At the core of the reasons is management introducing slow pace development of the main product, that is LV (NGX, green lady, multiple side products based on LV/NGX to make a few $). With no budget, NI devs are unable to dig into the core of LV to make critical changes like vector graphics, so they patch minor UX updates like additional right click menu actions instead. 

   after having peeked in once and coming to the conclusion that they only understand Bahnhof,

But if LV share in the market value is more than ca. 10% then it won't work.

[Konan__]

Your proposal is a failure guarateed 100%

There is no value in Labview Opensource, because nobody except NI RnD would be able to edit & compile that code.

Also, Labview itself is just a massive abstraction that had a value in 1990-2010 decades, but today any decent programmer can code .NET or Python, so it would just be more convenient to create opensouce libraries and test frameworks.

Guess what? 

Someone else already started doing that: OpenTAP.

There is no future for NI LabVIEW, it's officially a dead-end techology stack.

Any new project is not done in LabVIEW software, more and more once libraries and frameworks will mature.

I could see a point in using just Teststand, but not labview anymore.

And even TestStand is about to be obliterated within 5 years

[Intaris]

---

@Konan__ wrote:

Your proposal is a failure guarateed 100%

There is no value in Labview Opensource, because nobody except NI RnD would be able to edit & compile that code.

Also, Labview itself is just a massive abstraction that had a value in 1990-2010 decades, but today any decent programmer can code .NET or Python, so it would just be more convenient to create opensouce libraries and test frameworks.

Guess what? 

Someone else already started doing that: OpenTAP.

There is no future for NI LabVIEW, it's officially a dead-end techology stack.

Any new project is not done in LabVIEW software, more and more once libraries and frameworks will mature.

I could see a point in using just Teststand, but not labview anymore.

And even TestStand is about to be obliterated within 5 years

---

Lol. We'll see.

[AeroSoul]

I think you underestimate old people/big business resistance to change.

Any new project might not be started in 5 years (tho i doubt that too), but all the legacy code will sure as hell not be migrated anywhere.

In 30 years you'll find an old piece of essential tech that'll be running labview code.