Jump to content

The State of OpenG (is OpenG Dead?)


Recommended Posts

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?

Link to comment

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

Link to comment

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 by smithd
Link to comment

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.

Link to comment
1 hour ago, ShaunR said:

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

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:

image.png.e86638434712055251ad58624c42350d.png

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 by smithd
Link to comment

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.

Link to comment

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 by smithd
Link to comment
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?)

Link to comment
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.

Link to comment

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 by Mads
Link to comment

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.

Link to comment
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 by ShaunR
  • Like 1
Link to comment
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.

Link to comment
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 by ShaunR
Link to comment

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.

Link to comment
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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.