Leaderboard

@Jim Kring, it seems to me that the export of the code has gotten a positive response from the community. However I may be wrong. If anyone has any opinion either way, please come forward. As you can see in this thread, it appears the community has rallied around this effort. This is why I emailed you to come here and share your thoughts. In the past, OpenG was a great venue to showcase how a bunch of passionate LabVIEW users can come together and collaborate on something useful. The passion is clearly still there, as shown by the numerous discussions here. The general coding community has moved to Git with GiHub being the hub. This seems like the logical next step. Who knows what this initiative will lead to. However, I’m expecting that placing OpenG in a neutral GitHub repo will provide the spark and the tools to facilitate open collaboration, then the community can drive the future. The community is full of smart people who have a desire for clean tested code. And if issues come up, LAVA discussions (or GitHub issues) are there to hash things out. When LAVA offered to host all OpenG discussions back in 2011. it was clear that the community wanted to help. When @jgcode put his standards together for how code should be discussed at that time, It was an exciting time. Since then, many people have come forward with offers to add new code into OpenG and fix bugs. For example @drjdpowell first offered to include his awesome SQLite toolkit for inclusion into OpenG. He got no response either way. It’s a shame to have a platform and forums to allow people to post and discuss OpenG code and then ignore it. If you have ideas on what the future of OpenG is. I’m hoping it’s to be more transparent and inclusive. Providing the tools, resources and some safety checks along the way, is the best way to facilitate passionate individuals to dive in. Do you think keeping the status quo of the past 10 years makes sense? It seems to me that the community disagrees. What do you think?

I've been looking at the GCentral site and visited the Package Index page. While I find it a good initiative I see here the same problem that makes me loath browsing the NI site for products. I'm interested in the list of packages mostly yet half of the screen is used up by the GCentral logo and lots and lots of whitespace. I may be a dynosaur in terms of modern computer technology and not understand the finesse of modern web user interface design, but a site like that simply does not make me want to use it! Maybe this design will be beneficial to me in 10 years from now when my eyesight has detoriated so much that I won't see small print anymore but wait, the text in the actual list is still pretty small, so that won't help at all. It's also not because of the much acclaimed fluent design. The size of the actual screen stays statically the same no matter how I resize the browser window. This kind of web interfaces makes me wonder where we are all heading to. Design above functionality seems to be the driving force everywhere.

I've exported the OpenG sources from Sourceforge SVN to Github. It's located here: https://github.com/Open-G I'm hoping this will encourage collaboration and modernization of the OpenG project. Pull requests are a thing with Git, so contributions can be encouraged and actually used instead of dying on the vine.

Not out of the box. 32 bit LabVIEW interfaces to 32 bit Python. So you would need to have some 32 bit Python to 64 bit Tensor Flow remoting interface. If 64 bit LabVIEW is a requirement the lowest possible version is 2009 on Windows and around 2014 on the Mac and Linux platforms.

According to the activity log @Rolf Kalbermatter is the only active user for at least the past 6 years (log ends there): https://sourceforge.net/p/opengtoolkit/activity/?page=1&limit=100 @jgcode compiled a nice list some time ago. Not sure if all of these are done yet: Here are some ideas that come to mind: Allow the community to participate in the project (create and maintain tasks/issues/features, add maintainers, add admins, etc...) Bring back openg.org (could be a different domain) and allow the community to contribute to the site via pull requests Split the monolithic repository into separate repositories for each project for best practice (and to prevent linking between projects) Convert the SVN repository to Git to allow offline branching, pull requests, etc... Use tags when releasing new versions, this allows everyone to use a prior version if needed. Add documentation for how to deploy new versions (the building process). Add documentation about which LV versions to use and what tests to perform before opening a pull request. Use a single license for all projects. Add a CLA to ensure the license holds for all contributions Work on Feature requests, bugs and change request (there are a lot) Share your thoughts SF is a good place for a small team of developers, working on their project. Users are only meant to report issues and make feature requests. All development is taken care of by the admins/maintainers. Although there are ways to do pull requests, they are very inconvenient and tend to scare potential contributors away. In my own experience, there are a few ways to revive a project like this: Get the original admins back to the project (unlikely, they left for their own reasons) Add new admins/maintainers who have full authority over the project => Requires at least one responsive admin / SF is difficult for contributors (compared to GitHub) Do what @Michael Aivaliotis did. Archive the original code base, move to a simpler platform and build on top of what is currently available. Option 3 is most likely to bear fruit.

I and the whole rest of our LabVIEW community are the ones with the vested interest in OpenG. To me, the new github location looks less like a fork and more like reviving the project. LabVIEW isn't my day job anymore, but it is still my nights-and-hobbies job, and I welcome any action that brings things back to life. For instance, I took a look at JKI's OpenG-NXG github project, and there hasn't been a commit to any branch in over a year, and not to master in 3 years.