I agree, LabVIEW is dying. But, my opinion is that LabVIEW is still a good, technically viable product and the market share loss is mostly self inflicted through bad pricing and licensing. I've seen companies wreck good products many times through these exact same business tactics. ACIUS killed WebStar by overcharging and imposing weird licensing, for example. There is never collective learning from the business failures. Nobody in business school reviews the case histories and teaches not to do that.
There is nothing intrinsically superior about Python to make it a compelling product other than low cost. It's a dog of a language in several ways. LabVIEW has many advantages over Python, especially for developing software for hardware systems with many concurrent operations. Nothing comes close to LabVIEW for rapid development of software for that R&D scenario. LabVIEW doesn't need to be free to compete; It just needs to offer compelling cost-benefit tradeoffs vs. Python.
If I was in charge at NI, I'd...
1. Drop LabVIEW prices to regain market share vs. Python.
2. Review Erlang to see if some of the fault-recovery and high-reliability philosophies from that environment can be pushed into LabVIEW.
3. Advance development in a systems programming direction in competition with C++ and Rust.
4. Decouple from dependencies on Microsoft products (Silverlight, etc.)
5. Innovate to overcome some longstanding big-project problems, such as the tendency of the code editing environment to bog down when working on deep hierarchies of complex VIs.
6. Review failed efforts to update the codebase. The effort to update the codebase (NXG) wasn't wrong; It was just badly executed. NXG derailed when the project...
a.) Threw away good, well-proven elements of the LabVIEW project R&D environment to ape an environment appropriate for a text language.
b.) Assumed that developers would joyfully throw away their legacy code for a g-like language with trivial benefits of pastel colors and rounded rectangles. The effect was something akin to replacing C++ keywords with Esparanto and syntax with OCamel because someone on the team thinks it sounds cool.
c.) Succumbed to anti-skeuomorphic fanaticism. The primary LabVIEW application space is intrinsically skeuomorphic. Users operating the resulting software need to see something familiar that conveys information how to use the interface. They are not empowered by front-panel interfaces that are so flat, dull and abstract that their first impression is "WTF?"
Initiatives to move in a SAAS direction are mistakes. Some customers absolutely do not want operational LabVIEW systems connected to the internet in any way, for security. There are concerns about espionage, intrusion, cyber-terrorism and IP theft.
A subscription-only model is also mistake. In the present volatile economic and geopolitical context, some customers absolutely do not want dependency on a subscription server or perpetual outgoing cash flow for development, operation or data analysis. War or cyber-attacks could terminate access to the license or SAAS servers. Economic adversity could force end to available cash flow.
Anyway, my decision was to buy a 3-year block of the last permanent LabVIEW licenses. This will cover my operational needs for 5-15 years.
