OpenG Library Exported to Github

[Jim Kring]

On 10/3/2019 at 1:23 AM, Michael Aivaliotis said:

I've exported the OpenG sources from Sourceforge SVN to Github.

• It's located here: https://github.com/gcentral?utf8=✓&q=openg

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.

 

 

Michael, can you clarify this?

Most of the key OpenG libraries have been migrated to GitHub over the last couple of years (e.g. OpenG-Variant-Configuration-File-Library), and there has already been a lot of work done to migrate OpenG to NXG.

Is the intent to fork the OpenG libraries?

Thanks,

-Jim

[Michael Aivaliotis]

I can see why you asked that question. It seemed to come out of left field. The intent is not to fork OpenG or create a separate development branch. The intent is to facilitate community involvement and incorporate some of the ideas floating around here on LAVA into new future builds of OpenG. JKI has taken some of the libraries, not most. I counted 5 on JKI and there are around 23 that I found and migrated. Granted, some of them could possibly be merged into new or cleaned up. However, this can be decided by the community.

I think having a location that the OpenG community can call their own is important. Including documentation on how to contribute and providing an open, inclusive, transparent development and deploy process is part of it. Having them on GCentral was my idea. I didn't get official approval from GCentral. I've since moved (and renamed) the repos from where I had them to a dedicated OpenG organization. This way it would truly be separate. If you want me to add you as a maintainer, let me know. If there are any contributions to OpenG that JKI has made on the JKI branch, we should merge them into the new repos.

New location:

• https://github.com/Open-G

[Jim Kring]

I'm still confused by all this, Michael.

You created a fork of OpenG on GCentral without their permission and so they asked you to remove it?  And, now, you've created a new "dedicated OpenG organization" on GitHub?

It seems like this is just moving/stiring lots of things around and nobody who has a vested interest in the ramifications of those actions, is being consulted about it, first.

If the aim is to promote better code and collaboration in OpenG, then what would help is to contribute/propose some ideas, especially around processes and structure for contribution.

A haphazard approach won't work well for building community -- simply creating new GitHub pages/repos and starting forum discussions about forking OpenG will only create confusion.

That all said, I'm happy to have your participation and enthusiasm in making OpenG better.  There are several efforts on the roadmap for OpenG, and we can certainly use some helpful participation.

[ShaunR]

11 hours ago, Jim Kring said:

It seems like this is just moving/stiring lots of things around and nobody who has a vested interest in the ramifications of those actions, is being consulted about it, first.

Who would that be? The maintainer used to be JGCode but when Rolf wanted to update his Zip library, he was pretty much left to do it himself and make a spur. Who is the maintainer of the distribution and where are contributors expected to go with updates?

[Justin Goeres]

1 hour ago, ShaunR said:

Who would that be?

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.

[ShaunR]

5 minutes ago, Justin Goeres said:

I and the whole rest of our LabVIEW community are the ones with the vested interest in OpenG.

Indeed. But I was asking who is the maintainer? Who is it that vets the code, makes the OpenG package for VIPM then uploads it to the Tools Network? How does the VIPM OpenG package get up issued with Rolfs (or anyone elses) code? It used to be JGCode but he went a long time ago.

[LogMAN]

1 hour ago, ShaunR said:

But I was asking who is the maintainer?

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

15 hours ago, Jim Kring said:

If the aim is to promote better code and collaboration in OpenG, then what would help is to contribute/propose some ideas, especially around processes and structure for contribution.

@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)

15 hours ago, Jim Kring said:

There are several efforts on the roadmap for OpenG, and we can certainly use some helpful participation.

• 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:

1. Get the original admins back to the project (unlikely, they left for their own reasons)
2. 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)
3. 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.

Edited October 9, 2019 by LogMAN

[Michael Aivaliotis]

@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?

[Rolf Kalbermatter]

While I can understand Jim's concerns I also think that the current state of OpenG is pretty much an eternal stasis, otherwise known as death. Considering that, any activity to revive the community effort, either under the umbrella of OpenG, G-Central or any other name you want is definitely welcome. And while I'm willing to work on such activities, organizing it has never been my strong point. I don't like politics, which is an integral part of organizing something like this.

There are other problems with initiatives like this: People do usually need a job that pays the bills. They also have a life besides computers. And they frequently move on or loose motivation to work on such an initiative. One reason being that there is so much work to do and while quite a few people want to use it, there are very few wanting to contribute to it. Those who want to contribute often prefer to do it in their own way rather than help in an existing project. It's all unfortunate but very human.