The State of OpenG (is OpenG Dead?)

[Michael Aivaliotis]

In this thread, a user makes a suggestion for an improvement to an OpenG VI.

Let's say we all agree and want to make changes to the OpenG ini VIs. Now what? What is the procedure to do this? How is this package managed and by whom?

In this thread @rolfk states the original authors have moved on and the library is pretty much archived. On the other hand, JKI has migrated the OpenG code to LabVIEW NXG. So there is some interest to keep it alive. What is the state of the union on OpenG? How are changes and improvements made, then released?

Is OpenG a dead library?

[0_o]

Admin:

0. Choose Functionality Admins + API + Requirements + Setup GIT

Functionality Admins:

1. Scenarios (according to API + Requirements) + Documentation

2. Black Box testing around a function (empty VI with connector pane filled according to API) + benchmark

3. Update GIT with the empty function and its tests

Users:

4. Users solve each functionality

Functionality Admins:

5. Each function admin approves the tests under his/her control back to the main trunk if the requirements are holding 

Admin:

6. Approves a new stable version

[Michael Aivaliotis]

@0_o, thanks for the morning laugh! ? I guess I deserved that.

[smithd]

Just for myself, I don't really use openg and never have. I've definitely been using lv for shorter than many on here, so I'm curious if thats part of it (ie lv has picked up the slack over the years) or if its just me. Distributing code that uses it to other people always ends up being annoying. I'd rather write a for loop  to remove duplicates from an array than try to explain to some coworker that they need to first install vipm and then look for the specific package and then when it asks to install 17 other dependencies install those too, etc. The for loop is easier.

Edited November 15, 2018 by smithd

[Michael Aivaliotis]

Well, your comments are definitely valid for any tool distributed as a package. Not just OpenG. Also, for OpenG specifically, NI has started to incorporate some of the functionality of VIs from OpenG into the default distribution. There are numerous examples. It makes it even less attractive to use it. There are a handful of VIs in OpenG that I use that I wouldn't miss and could easily be replaced by creating replacements and dropping them into my own library. If there is no development or improvement of OpenG, then it becomes less useful and it just encourages people to roll their own.

I think if there is to be any development of OpenG then it should be moved from SourceForge into a different repository system like GitLab or GitHub. This way others can contribute. That would be a good start.

[ShaunR]

2 hours ago, smithd said:

so I'm curious if thats part of it (ie lv has picked up the slack over the years) or if its just me.

I don't think it's just you. For my part. I work with companies that require approved suppliers so using any third party software is an admin nightmare. Because of that and the length of my whispy white beard,  I have accrued my own software which is unencumbered by other licences and can be used by the aforementioned companies because I am approved.

Certainly there are some features that have been added to LabVIEW when before only openG had those features (getting type def info and auto indexing array springs to mind) and Rolfs zip package is much, much faster than NIs. But a lot  of the functionality was just replication of NIs (like most of the string functions).

There were a few gems in there like the inifile being able to write anything (but I think MGI toolkit outpaced that and besides, I moved to SQLite a while ago now). And, as you mentioned, removing array duplicates and it's ilk. But, like you say, they are not hard to write and the incestuous dependencies means that when you want a banana you get a banana, the gorilla holding the banana, the tree the gorilla sits in and the whole jungle surrounding it. Package that with some BSD 2/3, LGPL, GPL and god knows what else ad nauseum and it makes an otherwise fine package difficult to actually use in anger.

Edited November 15, 2018 by ShaunR

[Michael Aivaliotis]

4 minutes ago, ShaunR said:

the incestuous dependencies means you that when you want a banana you get a banana, the gorilla holding the banana, the tree the gorilla sits in and the whole jungle surrounding it.

I love this analogy.

[ShaunR]

5 minutes ago, Michael Aivaliotis said:

I love this analogy.

Yeah. I can't claim that one. It was originally a criticism of OOP

[smithd]

1 hour ago, ShaunR said:

Yeah. I can't claim that one. It was originally a criticism of OOP

I thought it sounded familiar

2 hours ago, Michael Aivaliotis said:

Well, your comments are definitely valid for any tool distributed as a package. Not just OpenG.

Thats definitely true, I just think that in the case of openg theres no real reason not to merge a lot of them (bool, string, error, comparison, array, data, numeric, time, file) because all of those are basically vilib++. While people might not really want all of them, I doubt many would object to "too much bloat".

But to that point, any attempt to modernize openg would have to look hard at whats there. For example, from the error lib:

Labview has all of the red items on the palette already, filter error codes is just a for loop around clear errors (from 2014+), and the case structure is...just a case structure with error wires in and out. Personally I use this, although admittedly it took me >5 minutes to find it and I'm the one who wrote it.

And this error lib is a dependency of pretty much every other package, because its also a dependency of the string library.

Edited November 15, 2018 by smithd

[hooovahh]

Yes many OpenG functions have native equivalents, but usually lacking in some way or another when it comes to what it can do.  I made several idea exchange requests for Array, File IO, and Clear Errors to act more like OpenG.  I heard rumors about a few things that might make their way into new versions of LabVIEW since VIMs are not a thing.  Having my customer be my boss means I can get away with using any 3rd party tools I feel comfortable with (license permitting) and OpenG is one of those things I've just always installed on all development machines.  I have a single VIPC that has all the OpenG, MGI, internal packages, and various LAVA things.  As for OpenG being dead, looking at the last date of package releases makes it pretty clear development has basically stopped.

[smithd]

https://github.com/jkisoftware pulled a few of the repos over to github but it doesn't look like any work has been done (the updates shown are just licenses/readmes). 

 

42 minutes ago, hooovahh said:

I made several idea exchange requests for Array, File IO, and Clear Errors to act more like OpenG. 

I definitely agree with most of those as 'this would be nice'

 

 

Also, and I realize this is kind of petty...but why green? Why on earth...snowy mint?

Edited November 15, 2018 by smithd

[Michael Aivaliotis]

I don't know if JKI is now managing the packages from within GitHub or if those are dead repos. I guess JKI should chime in to explain.

For one thing. All the links to open.org are dead. So at least the packages need to be updated to remove that crap.

[JKSH]

16 hours ago, Michael Aivaliotis said:

Is OpenG a dead library?

Dead is a strong term. I'd say it's stagnated and left behind the times, but it still offers some benefits.

My company still uses parts of it regularly (like Create Dir if Non-Existent and the VArray/VCluster VIs), even with LabVIEW 2017.

 

2 hours ago, smithd said:

Also, and I realize this is kind of petty...but why green? Why on earth...snowy mint?

Probably similar to why websites from 20 years ago used garish clashing colours with cartoony animations ('Cos it was stylish at the time?)

[Michael Aivaliotis]

3 hours ago, JKSH said:

Create Dir if Non-Existent

NI create directory does this already.

[JKSH]

7 minutes ago, Michael Aivaliotis said:

NI create directory does this already.

This falls under @hooovahh's earlier quote, "many OpenG functions have native equivalents, but usually lacking in some way or another when it comes to what it can do." NI's Create Folder node throws an error if the directory already exists.

[Mads]

We use OpenG quite a lot. Mainly the zip, array, directory and configuration file functions (the latter partly due to legacy issues, but also because it makes the configurations as readable as they can be). The zip functions are the only ones available for Real-time, and it is a big effort to make and maintain something like that (Thanks @rolfk?). Other functions have very useful subtleties, making them more useful than the alternatives (and sometimes the subleties are a problem instead, but then the functionality is not found elsewhere so they are just an acceptable downside). Of course you can write equivalent functions yourself, but that is a bit silly unless you have some requirement forcing you to reinvent wheels (thankfully we are not in that kind of business).

There is not much development done on the official version, in the world of product life cycles I guess we would call it "mature" instead of dead (obsolete) though?

We had quite a good discussion about the array function back in this thread https://lavag.org/topic/15980-openg-filter-array-revised/, where yours truly even posted a complete update, without any of it making it into the official version...Others here have made Xnode and VIM versions of that library too, utilizing the new conditional auto-indexing function now that it is more optimal than the old ways of doing it....so perhaps the official update path is dead (I remember butting my head in some logon issues the one time I tried contributing that way...), but the product is not? The old 80/20 rule is quite flawed when used to justify removal of code...but I do agree that some of OpenG could be removed at least if the dependencies were changed.

Edited November 16, 2018 by Mads

[Michael Aivaliotis]

So were the VIM versions ever incorporated into the latest OpenG?

[LogMAN]

We used the OpenG library a long time ago, when LabVIEW was still new to us and we could leverage the power of OpenG to accelerate our development (between LV6.1 and LV2009). This is in my opinion still the strongest point of that library - it provides new developers (or teams) with lots of useful functions at the cost of dependencies.

We have since walked away from it due to incomprehensible copyrights, lack of updates (although it is very stable) and generally because we used few functions to begin with (i.e. Fit FP to largest decoration, filter arrays and some string manipulation). At some point the dependencies mattered more than the benefits. What we needed was rebuild in our own library, removing all dependencies from OpenG.

If the OpenG library were to be cleaned up, just removing functions is not a good solution because it breaks compatibility for anyone who depends on it. On the other hand, dependencies between the libraries can easily be removed.

For example, there is no need for OpenG String to depend on OpenG Error anymore. Instead OpenG String could be updated to remove the dependency (using only native LV functions) and still keep OpenG Error in VIPM.

OpenG Error on the other hand is technically unnecessary nowadays (as pointed out by @smithd above). This library can be archived (while keeping it in VIPM). Here is what we do with our libraries when they become obsolete:

• Remove obsolete VIs from the palette (but keep them in the vi.lib)
• Change icons and documentation to highlight obsolete VIs (similar to how NI does it, by adding red color to the icon - the more the better)
• Explain in the documentation why the VI is obsolete and how to replace it
• Add replacement code to the block diagram of the VI
• Remove password protection
• Enable inlining if possible

That way, when you come across obsolete VIs, you can simply use the "Inline SubVI" command to replace it: https://forums.ni.com/t5/LabVIEW/Inline-subvi/m-p/1279086/highlight/true#M532443

Of course, sometimes changes may destroy the block diagram of the calling VI, which is why those VIs have password protection removed, allowing the developer to inline the VI manually.

[ShaunR]

18 minutes ago, LogMAN said:

We used the OpenG library a long time ago, when LabVIEW was still new to us and we could leverage the power of OpenG to accelerate our development (between LV6.1 and LV2009).

I a similar vein. The toolkit gives new starters a lot of examples on how to use prototypes in LabVIEW - in small, easily digestible chunks IMO it has enormous value as a teaching resource and as an exemplar of coding style.

Edited November 16, 2018 by ShaunR

[Michael Aivaliotis]

The library is still useful. But it can be useful and dead at the same time.

[ShaunR]

1 minute ago, Michael Aivaliotis said:

The library is still useful. But it can be useful and dead at the same time.

No library is dead whilst at least one person is using it.

[Michael Aivaliotis]

10 minutes ago, ShaunR said:

No library is dead whilst at least one person is using it.

Yup, there's so much development in OpenG, it's mind blowing.

If I see a tool, application or library that has no development activity in over 5 years, then I cannot trust that application, tool or library. That is a clear sign of intent on the part fo the developers. The message is loud and clear. This library, app or tool is dead, move on. That is a project risk.

[ShaunR]

33 minutes ago, Michael Aivaliotis said:

Yup, there's so much development in OpenG, it's mind blowing.

If I see a tool, application or library that has no development activity in over 5 years, then I cannot trust that application, tool or library. That is a clear sign of intent on the part fo the developers. The message is loud and clear. This library, app or tool is dead, move on. That is a project risk.

That's a trope initially perpetuated by marketing people. There is no message. If developers discontinue a product they will [almost] always say so in the notes, comments or website unless they were unexpectedly hit by a bus. I have a similar problem with this perception. Many of my toolkits are feature complete at initial release. There is usually a period of bug fixes shortly after release and then no updates because there are no new features and no reported bugs. 

Edited November 16, 2018 by ShaunR

[Michael Aivaliotis]

Based on this discussion thread, there are clearly improvements and restructuring that could be done to make the toolkit better. Even if you look back at old threads for suggestions. Currently there is no mechanism and no plan to do this. Bug reports and suggestions get ignored or go into a void. Documentation is missing or broken with no intent to be fixed. New improvements and efficiencies in LabVIEW have not been incorporated. Etc. I guess my assumption of OpenG was an ongoing community effort to build a great toolkit. I'm not seeing the ongoing community effort part.

21 minutes ago, ShaunR said:

I have a similar problem with this perception.

I don't get that from your site at all. If someone contacts you about a bug to your tool, do you ignore it? I assume no.

[LogMAN]

1 hour ago, Michael Aivaliotis said:

The library is still useful. But it can be useful and dead at the same time.

I agree to what @ShaunR said, but let me add to it:

The library is not dead, because it is still functional and very useful - especially for new developers as mentioned earlier.

The project, however, is dead. As you correctly pointed out:

20 minutes ago, Michael Aivaliotis said:

Bug reports and suggestions get ignored or go into a void. Documentation is missing or broken with no intent to be fixed. New improvements and efficiencies in LabVIEW have not been incorporated.

Technically anyone could fork the project (on whatever platform - SourceForge / GitHub / BitBucket - you name it). Development could even continue under a new name (probably even the same?). Yet the number of licenses being used right now is impossible to maintain, even for experienced developers. OpenG is also tightly coupled with lots of services (i.e. NI and VIPM link to the official repository on SourceForge). To my understanding (although I don't have facts on this), the lack of response in the main repository is the reason to why libraries like MGI were found in the first place. Just look at the bug tracker https://sourceforge.net/p/opengtoolkit/bugs/

This is also not the first time we discussed the (possible) future of OpenG. Here is a thread from two years ago:

The complexity of the main repository (i.e. the folder structure) also sets the bar very high for novice contributors: https://sourceforge.net/projects/opengtoolkit/files/

And let's not forget the difficulties in comparing VI revisions in general.

All things considered, the project is not a simple task anyone could just pick up and get going. Lot's of things need to be considered, which requires lots of experience in LV. Of course, most experienced developers have no interest in contributing to the project if it involves lots of administrative tasks on top of their regular job.

Maybe a shared library like OpenG is not the right solution for LV. A simple place to share VIs might be easier to manage and contribute to in the long run.