NI moves some G libraries to "community source"

[Aristos Queue]

National Instruments has created a GitHub repository to community source G libraries. This move is intended to be a test of a mechanism to enable customers to create customizations of NI source code and share those customizations with each other and for NI to be able to adopt some of those customizations into its core products to benefit the entire LabVIEW community. 

 

We are beginning with just three libraries:

1. The Actor Framework, a library in vi.lib since LV 2012
2. The NI-GOOP Development Suite, a free toolkit add-on for improving LabVIEW class development
3. The AQ Character Lineator, a library not yet in vi.lib to support serialization/deserialization of LabVIEW classes
   

 

If this experience working with the community proves fruitful, NI may expand the number of our APIs that are part of this sharing. 

 

For more information, including instructions on how to access the GitHub repository, please visit this community: 

https://decibel.ni.com/content/groups/community-source-of-ni-code

 

 

For details of how to get access to the GitHub repository and the license agreement covering this project, please visit here:

https://decibel.ni.com/content/docs/DOC-37195

 

I want to make a personal comment on this new development: Opening up LabVIEW to more community participation is something I and a few others have worked on for many years. This is a major advance in that quest. We know that requiring a license agreement for participation is not a typical "open source" arrangement, but this is the best idea we have found to balance the desire of our users to improve LabVIEW while acknowledging that LabVIEW is for-profit software that gets used in sensitive industries. If you have particular objections to the license agreement, please open a discussion thread in the community linked above so we can discuss them. We believe most users will find this arrangement acceptable, but not everyone. I hope, though, that this can be a successful venture, and perhaps will serve as a first step toward more.

[ShaunR]

The big benefit for developers that I see here is that it may highlight some of the source control issues that we have suffered for many years. It may prompt changes in the core so that we can use these powerful tools (like github) much more effectively. I dare say that once you have 20 branches all pushing their changes, the nightmare of merging, cross-linking and phantom recompiles might be laid to rest once and for all That alone should be enough of an incentive to participate, if only because pushing changes will cause such havoc for the people merging the Master that they have to do something before they tear [the rest of] their hair out

Edited June 5, 2014 by ShaunR