Moving away from GitHub readiness plan

[ssddanbrown]

This is not something I've decided to action or currently plan to go ahead with, I just think it's wise to think and plan something like this through in the event we want/need to migrate. Better to be ready in such circumstances.

This post is intended to evolve over time.

Motivation

As time goes on, and as GitHub develops under Microsoft, it feels increasingly uncomfortable to be on the platform.
Here are some of the reasons for this in the context of managing BookStack:

• Being a self-hosted open source platform, a significant portion of our audience will be those that value their privacy and rights. Using a platform, and agreeing to terms, from a large company like Microsoft may be a barrier and/or an unfavourable element in getting involved with the project.
• Being an open project, it would be favourable to use open and support open platforms ourselves.
• The consumption of all public code on GitHub, without opt-in or proven regard to license, to provide AI services reflects the balance of GitHub's drive for revenue vs their respect to authors.
• They now seem to be willing to sacrifice UX to chase revenue. Reference.
• They seem to be increasingly be pivoting to be an "AI platform" over that of being a open source development platform.
  • They now describe themselves, on their homepage, as "The AI-powered developer platform to build, scale, and deliver secure software."
• They've started swapping out logical/functional features with "AI" or "Algorithm" based features. Reference.

At the time of writing, none of these reasons have been specifically raised to me as concerns from community members, and none specifically are major to the point where I think a change is required, but they show an unfavourable direction I'd like to be prepared for if it continues.

Benefits of GitHub

There are some benefits we get from GitHub that it's important to consider:

• They serve as a monetary-cost-free host & platform for our code, and management of code and issues.
• The platform has significant popularity and market share, which does help involvement/access.
• Quite subjective, but I think the UI is relatively friendly with features like issue forms that help user UX and issue management.
• We get monetary-cost-free access to CI process via GitHub actions.
• GitHub sponsors has served me well, with a significant portion of my income from the service.

Our Attachments to GitHub

The below list the ways that the project is entwined with the GitHub platform, that we'd need to consider for potential migration:

Note: Actions & potential plans are not listed for these yet, but I plan to outline ideas for those out in future. I am aware for each of these there will be solutions and options.

• We maintain 6 active repos for BookStack. There will be links to these from external sources for from within our own content.
• We've made heavy use of GitHub issues, and have many open and closed issues that are quite valuable (along with all the comments). Additionally, there's a lot of cross-referencing of GitHub issue IDs within commits which do have a good amount of value.
• We use GitHub actions for our CI processes.
• I get significant income from generous folks via GitHub sponsors.
• Our installation and update process specifically uses git via the GitHub address.
• We have composer within our install/update process which I believe heavily makes use of GitHub on usage to download package code (This is more tangential relative to our own direct use of GitHub, but still something to consider).
• We make use of easy integrations of external systems with GitHub (Crowdin, Codeclimate).
• I believe some community projects (like linuxserver) watch for changes via GitHub release changes.
• We use GitHub PRs for contributing code.
• Minor factor, but GitHub stars are somewhat nice to track relative growth over time.

Alternatives

Here are potential alternatives along with my very high-level thoughts:

• Codeberg
• sourcehut
  • I respect the platform and vision, but always felt the UX is targeted at a developer audience that is not me (Personal preference).
• GitLab
  • Not sure on their direction. Hosted GitLab for a number of years, felt their focus was increasingly put on commercializing & enterprises, with wilting focus on the open core.
• Gitea

[jsreynolds]

I've had success hosting GitLab on-prem internally for years. Their upgrades and updates for me at least have never been problematic, but then I don't use a tenth of the "devops" deploy stuff.

However, about the time I was finally ready to migrate from GitLab's on-prem to their cloud, they suddenly did a huge price-hike almost overnight. They have had even more changes since then. Some people had invested heavily in their product due to the features and reasonable prices... suddenly many were left with double or triple the monthly cost. Since then, I've been wary of their motivations.

I have a separate instance of Gitea which I keep fully updated and ready for the moment when either I get time to convert over, or GitLab pulls some other stunt. However, Gitea has its own "potential" issues with the community. This happened back in Oct 2022 and I'm not sure why people were so upset, but nevertheless... https://blog.gitea.com/open-source-sustainment/.

However, of all the ones I've tested, I keep coming back to Gitea for the simplicity of maintenance and "enough" features.

"AI" is the new "Cloud" is the new "whatever". People are required to market it like crack and I see it turn up literally everywhere, even when it has no place being there whatsoever.

[c0shea]

The energy from the broader community still seems to be with GitHub, so I think it makes sense to stick with it until such time as there is a large pivot to another service. While some of the other alternatives that have popped up seem attractive from time to time, they all suffer from the main issue of needing to make enough money from the service to stay alive as a company, and they have consequently made disruptive changes to their platforms as a result. That's hard to rival Microsoft in this space.

[lefuturiste]

Lately, there is a new project that aim to create a true community-driven open-source alternative to big platform like github or gitlab. Forgejo is an active fork of Gitea, supported by codeberg https://forgejo.org/. I think it's great but you will need to find the right 3rd platform to host you, or host it your self.

[ssddanbrown]

Thanks @jsreynolds @c0shea @lefuturiste for your input here.

@jsreynolds I also used to maintain a GitLab instance for a while, and also become wary about their motivations over time, when seeing their choices & their categorization of what goes into the open offerings. I'd generally want to keep away from anything VC-funded nowadays.

@c0shea I agree that it makes sense to stick with GitHub for now, I just want to be ready so that process of pivoting won't be too painful, or we're not overly tied down by GitHub.

GitHub recently doubled-down on their AI commitment, with the following:

Just as GitHub was founded on Git, today we are re-founded on Copilot.

Overall, if we were to move, I'd probable prefer to use an existing site like codeberg, rather than self-host, to avoid having an extra platform for us to maintain, and to contribute (via donations and user-base) to their establishment/growth, and to use a site that might have established users (or at least be familiar with users).

---

Over the last few days I've been thinking specifically about the GitHub-based git URL that's currently used to pull the code, and how we can put that under our control so it doesn't matter what platform we're using for management.

Just testing for now, I've hosted some mirrors of the repos here: https://source.bookstackapp.com/
The HTTP UI is the one built into git itself (GitWeb).
I'm thinking we can keep repos mirrored here and potentially use this as the main git endpoint used in our guidance & scripts, so this becomes under our control and we can just re-point the mirrors when required. This also means people don't have to trust/access third parties (like GitHub/microsoft) to get the code.

The HTTP UI is not really meant for project management/develop, but does serve as an alternative for people that would prefer to avoid third parties to browse the codebase and version control in the browser.
I'm gonna trial this to see how easy it is to maintain, and see if there are any suprises/issues with this kind of setup.