Leaderboard

What LogMan already said. Most people who were active in OpenG have moved on, either into other non-LabVIEW related work, or more into management where the daily coding has been replaced by other tasks that don't involve as much direct LabVIEW programming anymore. There are still some watching the list and trying to keep up with the things that are OpenG related, but other paid work usually takes precedence before something like OpenG. Also many have families now, so when away from work and at home, they often spend their time other than behind the computer. The canonical code repository for all OpenG related stuff has been and still is on https://sourceforge.net/projects/opengtoolkit/. Look for the SVN repository, the CVS repository is an old version of the Toolkit before sourcforge supported SVN. However while there haven't been any new packages released since 2011, I still am actively working on some of the pet projects that are mine. Mainly the lvzip library and to a lesser extend the lvpipe and labpython library. I also have committed one or two other bug fixes to other libraries in the past, that users have posted here, but didn't go through the trouble to release a new package for them as there were in fact other areas that I would have liked to improve on for those packages, but with absolutely no other feedback in those years, it does also feel a little bit like pulling a dead horse. While I have been a member from the beginning on sourceforge and still am, I do not believe that I have administrative privileges to add other developers to it. And I don't think it is very common to just add random people to open source projects without a little track report of commitment and code style by them. So the best approach would be in my opinion to try to post some improvements here in this subforum. If they look reasonable, I'm willing to commit them to the repository with proper credit. After a few such patches I think we could convince the project admins to add that person with commit access to the repository. Adding new code to the repository is however only half of the work. You also then have to create a new OpenG or VIPM package of the library and then get the people from JKI to update the list of available packages on their servers, so that VIPM can show them properly for all users. Of course, nobody can prevent you to simply fork the repository and start your own as long as you honor the existing licenses. Notice that most of the LabVIEW related code is BSD style licensed, while the C source code for the binary shared libraries that I have developed in the past is all under the LGPL license. Changing that license to any other license for any of the code without full approval by all of the previous authors is basically not an option. I would however find the forking of the repository the absolutely last measure. It would most likely rest in an obscure place, with no way to add its released packages to the VIPM list, so most users would never be aware that it exists and be able to install it on their systems.