NI abandons future LabVIEW NXG development

[Michael Aivaliotis]

So this was posted on the NI forums:

https://forums.ni.com/t5/LabVIEW/Our-Commitment-to-LabVIEW-as-we-Expand-our-Software-Portfolio/td-p/4101878?profile.language=en

Quote

 

To the NI Community,

Software is a critical differentiator for NI. But software at NI doesn’t represent just a set of products that contribute to our offerings. Our software portfolio connects our entire platform and provides capabilities that set our solutions apart.  

LabVIEW is a vital part of our expanding software portfolio. To build on the success of LabVIEW, we developed the NXG Platform which has enabled an entirely new set of offerings such as the NXG Web Module, SystemDesigner, FlexLogger, InstrumentStudio, VeriStand, and Digital Pattern Editor. You’ve told us there’s tremendous value in these NXG-based solutions, and we agree.  

We also built a new product, LabVIEW NXG, based on the NXG Platform. While your feedback has been positive and there’s been excitement about what you’re seeing in LabVIEW NXG, you’ve also shared with us some of your concerns around migrating to an entirely new LabVIEW product. And although we’ve mitigated some of these issues, we agree and want to empower you to focus on addressing your future test and measurement needs. 

That’s why we’ve decided to take the following steps: 

1. We will integrate the strengths of the NXG platform into our LabVIEW 2021(+) codebase, which will result in the best of both worlds. This means centralizing our investments in LabVIEW in a way that enables us to deliver even more value to LabVIEW users in the years ahead. 
2. We will continue to advance our NXG-based portfolio of solutions such as the NXG Web Module, SystemDesigner, as well as our expanding suite of configuration-based products such as FlexLogger and VeriStand. As part of this commitment, you can expect to see the NXG Web Module and SystemDesigner integrated into other parts of our portfolio.   
3. We will cease development efforts on LabVIEW NXG and release the final version - LabVIEW NXG 5.1 – in 2021. We will not release new versions of LabVIEW NXG starting in 2022.  

Our teams are working on these projects today as well as the significant new investments we’re making across our entire software portfolio, including in Product Analytics and Test Operations. Collectively, our ongoing investments in this well-rounded portfolio give us a unique ability to create a digital thread that follows a product across the development flow and through its entire lifecycle. This allows us to provide new value to you at an even larger scale - like reducing overall time to market, significantly lowering operational costs and helping you address pervasive product and performance issues before they impact your customers.   

The steps we’re sharing today – the long-term commitment we are making to LabVIEW as well as our ongoing investments in configuration-based software, Product Analytics and Test Operations – will bolster our software capabilities and better support you. They are aligned to our software strategy and our commitment to providing all of our customers and partners with the most innovative and powerful software in the Test and Measurement industry. 

Thanks,
Omid Sojoodi, VP of Software R&D
Stefanie Breyer, VP of Product Planning 

 

 

[jhoehner]

Juicy drama...

[ShaunR]

AQ leaves, NXG gets shelved.

Insert your rumour-mongering and conspiracy theories here 

[Bryan]

Hopefully this alleviates any concerns about LabVIEW becoming unsupported in the future in favor of NXG.

[pawhan11]

I am glad that didn't ve time to install NXG 😀

[gleichman]

When do we get vector graphics in LV?

[gleichman]

1 minute ago, pawhan11 said:

I am glad that didn't ve time to install NXG 😀

The boot time was almost worse than the install time.

[hooovahh]

In 2014 I had the privilege of being in on one of the early discussions around what would be NXG, before I was a Champion, and I think I was just a CLAD.  They were interviewing each person one at a time with a set of questions and the last one was "What is your biggest concern with this decision by NI?" and my answer was some thing like "What are NI's plans if this fails?"  Saying that this is my career they are potentially messing with, along with the negative effects internally at NI.  They sorta laughed it off and said how unlikely it was but that they would do their best to go back to supporting the more classic LabVIEW.  It probably is the right decision for them to make, but also a very difficult one.  If it were me I'm not sure I would be able to see past the sunk cost fallacy.

[pawhan11]

I guess it is time to reopen some ideas from idea exchange marked resolved in NXG

[Mads]

Here's hoping the right lessons have been learned, and that things will jump and move in a better direction from now on.

Edited December 3, 2020 by Mads

[gleichman]

I'm starting to wonder if this decision was driven by the New NI that we learned about earlier this year and NI's updated vision of selling turn key systems instead of software and hardware that enabled engineers and independent system integrators.   

 

 

[dadreamer]

I just hardly understand, how new features of NXG could be integrated into classic LabVIEW editions, given that a classic is written on C/C++, whereas NXG is made on C# mostly. It's also worth mentioning, that some code pieces of classic LabVIEW were not updated for decades, so it would take years literally to rework them and reimplement some NXG possibilities (as zooming, Unicode support etc).

[smidsy]

I am happy that they finally realized, that the NXG idea is a way far from being somewhat practical or pragmatic. I am very sad it took NI so long to understand it.

If I were NI I would probably go for changing the underlying engine and software stack and would rewrite LabVIEW completely, if I realize that the LabVIEW source code has reached it's end-of-life state and is very hard to maintain. This was one of the driving forces according to the information I got from NI during CLA Summit 2019.

But I would never ever change (at first) the interface to the Users and to Developers and re-invent core concepts of LabVIEW just because I can. Then I would probably start adding new features and slowly adding value to the community. I would not ever threaten people by saying that "NXG is the Future",  "Programming is optional" and "It is better to start switching to NXG now, because one day we will inevitably stop LabVIEW development". 

 

 

Edited December 4, 2020 by smidsy

[Neil Pate]

I think this is a great decision. Admitting they made a mistake is a bold and courageous step.

Onwards and upwards from here.

[Jordan Kuehn]

3 hours ago, smidsy said:

I am happy that they finally realized, that the NXG idea is a way far from being somewhat practical or pragmatic. I am very sad it took NI so long to understand it.

If I were NI I would probably go for changing the underlying engine and software stack and would rewrite LabVIEW completely, if I realize that the LabVIEW source code has reached it's end-of-life state and is very hard to maintain. This was one of the driving forces according to the information I got from NI during CLA Summit 2019.

But I would never ever change (at first) the interface to the Users and to Developers and re-invent core concepts of LabVIEW just because I can. Then I would probably start adding new features and slowly adding value to the community. I would not ever threaten people by saying that "NXG is the Future",  "Programming is optional" and "It is better to start switching to NXG now, because one day we will inevitably stop LabVIEW development". 

 

 

That's what I understand NXG was supposed to be.

[X___]

Can't say that the rationale for the decision is put particularly convincingly... We'll have to wait for the dust to settle to really figure out what this corporate double-speak means. Do they even know themselves?

[Michael Aivaliotis]

41 minutes ago, X___ said:

Can't say that the rationale for the decision is put particularly convincingly... We'll have to wait for the dust to settle to really figure out what this corporate double-speak means. Do they even know themselves?

I agree. I can't see this as anything other than a complete PR disaster for them. I don't have any confidence they know what they're doing. It's gonna take a couple years for the dust to settle.

[Mike Le]

On 12/3/2020 at 11:57 AM, Bryan said:

Hopefully this alleviates any concerns about LabVIEW becoming unsupported in the future in favor of NXG.

Alleviates that concern while greatly heightening the concern that NI isn't positioning itself for relevance in the 2020s.

[Mefistotelis]

Tough decisions are definitely required to put LV back on its feet. But those also have to be correct decisions - and that's not easy to judge at this point.

Approach to some features may change now, as "this design flaw was solved in NXG" is no longer an argument.

 

[Maciej Kolosko]

Well my 2 Cents.

This is bad for the future of the G programming language in my opinion. I've not used NXG in production as it was never ready enough and it did feel like a constant prototype. However the overall experience with working with it as an IDE at least in the capacity I've used was a positive one. I've used it for the European CLA summit presentation back in 2019 and exercised mainly the C/C++ interface to connect Current Gen and NXG with Zero MQ. The changes in NXG in that area, in my estimation, have been logical and it was really easy to work with and made a lot of sense.

Killing off NXG, which was constantly not ready for production makes sense after all these years. The truth is it was not possible to use it on a real project in a significant way. However this is a huge effort is now basically flushed down the toilet, and I'm quite pessimistic about redirecting the effort and reusing the components developed as part of NXG and integrating them into the LabVIEW current gen.

I love graphical programming, and it is a very refreshing way of thinking about code, but current gen is clunky and 30 years old. And it is very painful to use for small team development (3-5 members) and is completely not suitable for large teams (10+ developers).

In reality my biggest concern is that the G language and the IDE of LabVIEW are joined at the hip and that is I think the crux of the issue. In order for G to survive as a viable option for the future it would need to be de-coupled from the old IDE of LabVIEW. But it seems to me like now they will be entangled together till the bitter end... until the user base of LabVIEW retires, and no new cutting edge projects will be created in G, not because G sucks but because LabVIEW IDE is holding it back.

Cheers,
Maciej

Edited December 6, 2020 by Maciej Kolosko

[ShaunR]

35 minutes ago, Maciej Kolosko said:

Well my 2 Cents.

This is bad for the future of the G programming language in my opinion. I've not used NXG in production as it was never ready enough and it did feel like a constant prototype. However the overall experience with working with it as an IDE at least in the capacity I've used was a positive one. I've used it for the European CLA summit presentation back in 2019 and exercised mainly the C/C++ interface to connect Current Gen and NXG with Zero MQ. The changes in NXG in that area, in my estimation, have been logical and it was really easy to work with and made a lot of sense.

Killing off NXG, which was constantly not ready for production makes sense after all these years. The truth is it was not possible to use it on a real project in a significant way. However this is a huge effort is now basically flushed down the toilet, and I'm quite pessimistic about redirecting the effort and reusing the components developed as part of NXG and integrating them into the LabVIEW current gen.

I love graphical programming, and it is a very refreshing way of thinking about code, but current gen is clunky and 30 years old. And it is very painful to use for small team development (3-5 members) and is completely not suitable for large teams (10+ developers).

In reality my biggest concern is that the G language and the IDE of LabVIEW are joined at the hip and that is I think the crux of the issue. In order for G to survive as a viable option for the future it would need to be de-coupled from the old IDE of LabVIEW. But it seems to me like now they will be entangled together till the bitter end... until the user base of LabVIEW retires, and no new cutting edge projects will be created in G, not because G sucks but because LabVIEW IDE is holding it back.

Cheers,
Maciej

Well. Aren't we a ray of sunshine nowadays 

[X___]

 

27 minutes ago, ShaunR said:

Well. Aren't we a ray of sunshine nowadays 

Isn't this serious stuff though? Most of us may have had disagreements with NI on some of the paths they had chosen to go down to, and were lamenting the crawling pace of their progress, but at least we all agreed that the current LV IDE/UI development toolset was outdated.

The official statement (by two top brasses, not a mere webmaster) is not particularly crystal clear as to what is forthcoming. Coming right after the Green New Deal campaign and in the midst of the pandemic, it might just as well be a forewarning of major "reorganization" within NI... The surprise expressed by AQ in a different thread would seem to support this hypothesis.

At least it gives me something to speak about in my next "how do we use LabVIEW in the lab" intro session...

Edited December 6, 2020 by X___

[ShaunR]

2 hours ago, X___ said:

Isn't this serious stuff though?

Just welcoming an old friend to the forum 

[Michael Aivaliotis]

14 hours ago, Maciej Kolosko said:

This is bad for the future of the G programming language in my opinion.

Yes, it's bad.

[Bryan]

On 12/5/2020 at 2:47 AM, Mike Le said:

Alleviates that concern while greatly heightening the concern that NI isn't positioning itself for relevance in the 2020s.

Very true.