Moving away from GitHub readiness plan

[ssddanbrown]

This post is intended to evolve over time.

Status

• July 27th 2024: Our secondary repos have now been migrated to BookStack on CodeBerg, with the GitHub originals archived with links to the equivalent codeberg project.

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.
  • They've started adding AI for PR description inputs, showing a future where they'd be encouraging the time we'll be reading/responding to AI generated content rather than human context
• Our LFS access got temporarily revoked due to bandwidth limits that can't be controlled on public repos AFAICT.

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.
  • Although I consider them to be harmful in a wider context due to encouraging star-chasing and growth hacking around this to perpetuate the idea they're an indication of value.

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.

[daffydock]

Out of curiosity since I saw them on the list, what are your personal thoughts since originally posting, about Codeberg and Gitea?

[ssddanbrown]

@daffydock I don't really have any major opinions right now, as I haven't delved too deep into either. From a quick look over, Codeberg seems to be more aligned with what I'd want to move to (community focused, user membership with donations) compared to gitea (appears focused on enterprise/commercial).

[ssddanbrown]

Received this notification from GitHub:

Git LFS has been disabled on the organization BookStackApp because you’ve exceeded your data plan by at least 150%. Please purchase additional data packs to cover your bandwidth and storage usage:

As far as I can see, we have no ultimate control over LFS bandwidth on a public repo since public clones/downloads consume this 🤦.

Additionally, GitHub have started adding AI for PR description inputs, I can only imagine they'll want to bring this to issues too, encouraging the time we'll be reading/responding to AI generated content rather than human context.

---

I've now moved much of my personal stuff over to Codeberg, with a few things left on GitHub for historical access or because of some complications to deal with before migrating over.
I've moved my private repos to a self-hosted Forgejo instance.
Will soon start a migration of most BookStack repos to Codeberg (website, hacks, devops, etc...).
For this main BookStack repo, I'm going to take this one slow. I'll look to move the direct download (for install/updates) to use https://source.bookstackapp.com.
Then management may be on Codeberg, mirrored to source.bookstackapp.com and GitHub.

[ssddanbrown]

All secondary BookStack GitHub repos have now been migrated to BookStack on Codeberg. GitHub repos have been archived, with descriptions/URLs pointing to the new codeberg project.
Website references to old GitHub locations have been updated where found, although some sneaky references may remain. Will just update as we find them.

[robderickson]

As the user base grows, I imagine the burden on yourself also grows. Are you concerned that, without GitHub sponsorships, it may no longer make sense for you to maintain the project? To be clear, I'm not suggesting you should compromise your values for the sake of the project. I just hope you don't sacrifice yourself for the sake of the project 🙂

[ssddanbrown]

@robderickson I don't need to completely give up GitHub sponsorships as part of a move, they're just noted as a form of GitHub attachment. I'd retain an account (and probably a mirror for BookStack due to existing use of the repo URL). It does mean maybe less traffic/access to that potential route of donation.

My sponsorhips via other means (KoFi + stripe/paypal) is growing though, and donations/sponsorships are becoming are less vital (although still very much helpful and appreciated) since support services are becoming a large income source so the financials are becoming more diverse in general which I think is healthy overall (regardless of GitHub being a factor).

Thanks for your care/consideration though!