Would you like to bring your addon under the main org

[timabell]

Hiya, would you like to put this repo under the org I created for for the original repo? could call it something like github.com/msaccess-vcs-integration/msaccess-vcs-addon

I'm thinking this would make it a little more discoverable, forks not being the easiest thing to navigate.

Let me know what you think. Feel free to chase me on tim@timwise.co.uk as I don't read the github notifications regularly.

[hecon5]

I thought about just doing it; this would also allow a larger group to help manage issues and review changes, as well.

The biggest issue I see is that because of how GitHub does repo tracking, to do that would mean you'd need to basically start from scratch for version history OR have a separately managed branch; neither of which are ideal.

I toyed with truncating the history from the point at which the divergence really happened (about 3 years ago), but that also caused difficulties and led to some weirdness in version history (incorrect attribution, though at this point the thing has been almost 100% rewritten).

[joyfullservice]

Hiya, would you like to put this repo under the org I created for for the original repo?

Thanks, @timabell for the suggestion! I have thought long and hard about this in the past, and appreciate you reaching out with the offer. There are pros and cons, and I wanted to share a little background on my thoughts for this.

The obvious pro is that you have greater visibility for people looking for a version control solution for Microsoft Access. It also sounds a little more official to have the matching organization and project name. I like those aspects.

The cons have more to do with the overall development philosophy and project leadership. If you look at the development history on the parent project, comparatively little has been done over the past several years. From all appearances, development has basically stagnated. Here and there a few people have made a few tweaks, fixed a few bugs, etc... I don't fault anyone for that. People are busy and most of us developers are focused on other projects.

Eight years ago I forked this project and began making some changes to adapt it to a more streamlined workflow. I refactored it as an add-in and changed the overall architecture to what I felt would be a more scalable model as we added support for more and more Access components. Building from source was a major milestone, as well as adding the UI, and now the Ribbon interface. Sanitization was heavily reworked, bringing massive performance gains. Standardizing on UTF-8 encoding and JSON data file greatly helped the international support for the project. The integrated index allows highly performant change detection and fast exports of only changed files.

Because this has become such an integral part of our internal database development processes, I have been able to personally invest hundreds of hours in refining this tool over the years to provide our development team the tool we needed to rapidly develop and deploy updates to dozens of database applications and integrations that we use internally where I work. We have invested a lot in this project, but it has also been a huge help to our development lifecycle.

I am also very grateful for a handful of others that have contributed in a very significant way to this project. People I have never met from around the world have helped solve challenges and push the project forward in areas where I lacked the skills or understanding to do it on my own. That's the beauty of open source software!

But for an open source project to succeed, you also need another aspect. You need someone with the vision to keep the project going in the right direction. Someone has to be willing to make the tough decisions and know when to say "yes" or "no" to feature requests or complex PRs. Someone that will take on a daunting refactoring job that makes it worse before it makes it better.

There are much more skilled and qualified people out there that probably would have done a much better job than me, but I had the unique position of having both the desire to see this move forward (envisioning the benefit it would bring to our team) and the ability to invest a significant amount of time into the project. I think (and hope) this has translated into a meaningful benefit for the Microsoft Access development community.

The other big factor for me is the issue of trust. When you download and run a VBA add-in you have to be pretty confident that there is nothing malicious or dangerous in the code base. The last thing you want is for some little overlooked mistake to wipe out a section of your database or inadvertently open a security hole in your environment. When I build the joyfullservice fork from source, I have the confidence that I have personally reviewed every line of code in this project. Others that download the project build a trust over time that this is a reliable project and legitimate source.

If we move the project to the organization repro, how do we maintain that same level of trust? It's not like we have a company behind the software that is taking responsibility for it, like you have with big name projects like wooCommerce. Who decides who has access to approve changes and merge PRs?

On GitHub among the more popular well-known projects, I see a mix of both organization-led projects and individual based projects. Most of the organization-led projects have companies behind them, while some of the great projects out there are under an individual that has taken it upon themselves to champion an idea and spearhead the project.

I think my leaning would be to continue with that sense of personal ownership, having the project under joyfullservice, but I would also be interested in the thoughts of a couple of Access MVPs that have taken an interest in this project. @bclothier and @mwolfe02, what do you think? Would I be better off snipping the upstream strings on this project and going forward with the stand-alone project, or do you think the organization repro is a better idea?

[bclothier]

Adam,

I can appreciate your position.

I would say that having an organizational repo would be a great way to boost visibility. However, that should come with having a stake in the same organization. If it is possible to make you the owner of the new repository and a part of the organization team so that you still have the same control & stake, then that should work out. I note that Tim suggested msaccess-vcs-integration/msaccess-vcs-addon rather than msaccess-vcs-integration/msaccess-vcs-integration so the implementation would remain separate. That should make it possible for you to have an ownership stake in this repository as you do with joyfullservice/msaccess-vcs-integration.

I will say that for a naive user, it does look weird to be "107 commits behind". I'd rather that there were no such thing, which does implies replacing the original msaccess-vcs-integration or diverging into a new repository not related to it. It's not easy to understand that 107 commits probably will not be compatible and may never be. Not having that anymore would be a gain as well. It's a little unclear to me how the same user would differentiate between the msaccess-vcs-integration/msaccess-vcs-integration and msaccess-vcs-integration/msaccess-vcs-addon and whether they should have to. At least that part can be addressed by having notes in both repositories explaining to help users to make an informed choice between the two different approaches.

I hope that helps.

[mwolfe02]

Maintaining your ownership in the repository seems like it would be a minimum requirement. I don't know the ins and outs of GitHub, but it seems like that should be possible based on Tim's proposal.

That said, combining the two repositories under a single organization would potentially be more confusing to outside users unless there is a concerted effort to coordinate efforts between you and Tim. The impression I get is that you two are cordial but not necessarily close collaborators.

At this point, your version of the project is more "inspired by" Tim's original rather than a mere fork, based on the substantial refactoring the project has gone through. Perhaps the project would be best served by creating a GitHub project with a new name and referencing Tim's original project in an "Inspired By" section of the readme.

Assuming this is technically possible (again, my GitHub knowledge is quite limited), I see several benefits:

• No more "107 commits behind" message (I presume)
• You would maintain full version history (again, I presume)
• Clearer disambiguation between your project and Tim's
• You continue to maintain full control over the project

Of course, there are downsides, such as:

• A new URL that may break existing auto-update code (if that feature exists)
• More confusion in the short term as you would have to redirect users to the new repository
• Possible pushback from your core contributors

Having two projects with the same name--"msaccess-vcs-integration"--that have diverged as much as yours and Tim's does cause some confusion for the community at large. And now would be a great time to make a big move with version 4 just around the corner.

That said, the status quo is not all that bad and maintaining it is likely the least risky approach. Ultimately, I don't feel too strongly about which direction you should go, but since you asked for my thoughts, I wanted to provide them. 😉

[joyfullservice]

Thank you all for the helpful feedback and input on this decision. After thoughtful consideration on this issue, I am planning to go ahead and detach my repository from the parent project, and also rename the project to msaccess-vcs-addin. As @mwolfe02 pointed out, this is a great time to make this change before the release of version 4.

Going forward, this project will be located at: joyfullservice/msaccess-vcs-addin. (GitHub will preserve the child forks, and automatically reroute from the previous name.)

Thanks again for your support for this project! ❤️

[hecon5]

Tough choices are always eased by careful consideration. Sounds great!

[mwolfe02]

Going forward, this project will be located at: joyfullservice/msaccess-vcs-addin. (GitHub will preserve the child forks, and automatically reroute from the previous name.)

Sounds good. @joyfullservice, let us know when the new repo is live and I will update my article.

[joyfullservice]

FYI, the detachment is in process with GitHub support, but they ran into an issue along the way:

Thanks for contacting GitHub Support! While working on this, there was a hiccup during the process which left the children with the upstream and not with your repository.

I'm just letting you know that we're currently resolving this and I'll give you a further update once this is resolved and all is clear 😊

I will post an update here once the transition is complete.

[joyfullservice]

I received an update from GitHub early this morning that the transition was successfully completed. I have changed the project name to msaccess-vcs-addin and made a few updates to the project readme to reflect these changes. We should be set to go! 🚀

The old repository links should still work (for the foreseeable future) but I would recommend updating them to: joyfullservice/msaccess-vcs-addin

Thanks again to everyone for the input and suggestions! 😃

[timabell]

I fully support everything in the above thread, great to see some strong ownership. I hadn't realised just how far the add-on version had come, very impressive! Great work all :raised_hands: :rocket: :heart_decoration: