It's nothing to fancy. I added a few things to the UI to support more features and in preparation of adding the VI renamining/relinking step that was done seperately in the OpenG DEAB tool before calling the OpenG package builder. But I never got around to really add the deab part into the package builder. It's kind of extra difficult as the DEAB compononent doesn't currently support newer features like lvclass and lvlib at all and of course no mallable VIs etc.
I can post what I have somewhere, but don't get to excited.

One of the main topics of the 2018 CLA Summit was the need to improve access to open source code in the LabVIEW community.  This is something that I have tried to do in the past with limited success.  After hearing what others are doing and discussing the issues, I am inspired to take on the task of getting as much of my code that is shareable out into the open for others to use, improve, learn from and critique.  So, the point of this thread is to figure out how best to do that.
I have tried posting code to forums in the past.  I have even posted to the code repository here on LAVA.  I have used code posted here and via the tools network and VIPM in my own projects.  But I am not sure if any of those avenues are the right path forward for me.  There was much discussion about different open source repositories on the interwebs that we could leverage.  There was also some discussion about how to help others discover the code you shared.  What I did not hear was any definitive conclusions on how best to do this.
So, the point of this thread is to try to solicit feedback on code sharing and come to some sort of consensus on the best options out there.  If you have an opinion on this please join the conversation and share what you think is the best solution.   Here are some questions I am trying to answer:
1. Where should we share code?  What system works best for LabVIEW code and is user friendly enough to not discourage people from using it?  Please share links and how-to documents for your preferred site/system.
2. How should we license code?  I heard some discussion about the various type of licenses.  I am not interested in retaining any rights to code I share and do not want to put any burdens on those who want to use and learn from any code I share.  What licence is accepted in the open source community that supports this kind of sharing?
3. Once we post, how do we make our code discoverable?  Do we need to post links all over the place or is there a better way?  Here is one attempt at making that better you should check out if you have not already: 
 
I am not just interested in putting the code out there, but also trying to explain why I think it is worth your time to take a look.  I am willing to post on forums, create a blog, even produce some vlogs on YouTube if it is the best option.   Please let me know what format would motivate you to take the time to learn about the open source code out there.
Either way, thanks for taking the time to read this thread and contribute what you can, even if it is just to follow the discussion and learn from others like I am trying to do.
-John

I've been working a lot lately with by-reference architectures that still cooperate completely with LabVIEW's implementation of OOP and polymorphism. I've also recently taken an interest in trying to speed up development with secondary providers (similar to GOOP) to enable automatic creation of accessor VIs hidden behind the DVR, automatic creation of the private data type and constructor/destructor, etc. within the project window. I'm generally not a fan of the extra stuff that goop adds in to classes, I'd prefer to keep the source code looking as close to a normal class as possible.
That said, I've started on my first ever XNode and it's a cross between an unbundle by name node and the -> operator in C. It functions just like a normal UBN, however it was also pull items out of DVRs. Having to plop down a UBN to pull out the reference from the class, an in place node to dereference, and then another UBN to pull the data out gets tiresome after about the 100th property VI gets written.
So far I've gotten the node drawing completed (except for data type coloring of the labels), the type inferencing from the input wire, and the popup menu for selecting an item. Next up will be the menu selection code so that the names will finally show up in the terminals! Then I get the daunting task of scripting up the GenerateCode ability >_>
Anyone interested in something like this? Following this will be a match to the Bundle by Name node that serves the same purpose except to write the items.

Hi,
 
I would like to play an idea out to you about having a composite class put itself back in its owning object by a DVR. Is that a good or a terrible idea?
 
Background
I need a class that represents some different LabVIEW files, and which can offer some operations on those files; LVFile.lvclass. LVFile.lvclass has some children (LV file types) and it owns a composite object LVFileRefs.lvclass:
 

 
LVFileRefs
LVFileRefs contains the following:
 
- An enum stating the file type.
- A reference to the LabVIEW file (class reference, library reference, project reference, or VI reference).
- The path to the file on disk (if it is saved to disk).
- Info if the refnum was created by the object or passed in from the outside (used by the Close method).
 
I need LVFileRefs as a composite object (instead of that data living inside LVFile) since New starts by instantiating an LVFileRefs object before New can decide which child to instantiate:
 

 
One of the responsibilities of LVFileRefs is to keep disk path and file reference synchronized. This means that you could start out with a VI in memory for instance, and create an LVFile object for that. This does not yet have a File Path. If you then save that VI, then LVFileRefs will update its internal File Path field from <Not-A-Path> to the proper path. If for whichever reason the original file refnum goes stale, LVFileRefs will also be able to open a new refnum from File Path if possible. All transparent to the user. So LVFileRefs maintains a firm grip of the file whether it being in memory only or on disk, and it can tell you which type it is (some types take more programming to tell apart than others, and type can change as well). All stuff that makes writing apps that handle many different file types simpler.
 
No DVR approach
Normally I wouldn't expose a naked refnum to the user, but one of the features of LVFile is actually to serve the proper refnum, so in this case I do. That is currently done with accessors on LVFile, and then an LVFileRef method:
 

 
Since LVFileRefs can update its embedded refnum it is important to write the LVFileRefs object back into the owning LVFile object (or else Close for instance wouldn't close the correct refnum, and several other issues).
 
DVR approach
Having to write back the LVFileRefs object is error prone - the user could forget to do it, and having to do it in the first place is irritating. I'd rather you could omit the write back step:
 

 
The idea is to have LVFile embed a DVR to itself inside its LVFileRefs object, with which LVFileRefs can write itself back into its owning LVFile object with whenever LVFileRefs has updated itself. There shouldn't be any racing possible, as LVFileRefs is actually the representation of the LV file, and DVR access is mutexed.
 
Am I insane considering this?
 
Cheers,
Steen

I am playing with GitHub as a possible replacement for our current SCC tool.
 
Do you guys use Git or GitHub?  What client app do you use?  Any recommendations?
 
I am specifically leaving the topic scope open, so feel free to praise/rant/headscratch.