mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-08 11:19:36 +03:00
Moving away from GitHub readiness plan #4215
Open
opened 2026-02-05 08:16:01 +03:00 by OVERLORD
·
13 comments
No Branch/Tag Specified
development
further_theme_development
l10n_development
release
llm_only
vectors
v25-11
docker_env
drawio_rendering
user_permissions
ldap_host_failover
svg_image
prosemirror
captcha_example
fix/video-export
v25.12.3
v25.12.2
v25.12.1
v25.12
v25.11.6
v25.11.5
v25.11.4
v24.11.4
v25.11.3
v25.11.2
v25.11.1
v25.11
v25.07.3
v25.07.2
v25.07.1
v25.07
v25.05.2
v25.05.1
v25.05
v25.02.5
v25.02.4
v25.02.3
v25.02.2
v25.02.1
v25.02
v24.12.1
v24.12
v24.10.3
v24.10.2
v24.10.1
v24.10
v24.05.4
v24.05.3
v24.05.2
v24.05.1
v24.05
v24.02.3
v24.02.2
v24.02.1
v24.02
v23.12.3
v23.12.2
v23.12.1
v23.12
v23.10.4
v23.10.3
v23.10.2
v23.10.1
v23.10
v23.08.3
v23.08.2
v23.08.1
v23.08
v23.06.2
v23.06.1
v23.06
v23.05.2
v23.05.1
v23.05
v23.02.3
v23.02.2
v23.02.1
v23.02
v23.01.1
v23.01
v22.11.1
v22.11
v22.10.2
v22.10.1
v22.10
v22.09.1
v22.09
v22.07.3
v22.07.2
v22.07.1
v22.07
v22.06.2
v22.06.1
v22.06
v22.04.2
v22.04.1
v22.04
v22.03.1
v22.03
v22.02.3
v22.02.2
v22.02.1
v22.02
v21.12.5
v21.12.4
v21.12.3
v21.12.2
v21.12.1
v21.12
v21.11.3
v21.11.2
v21.11.1
v21.11
v21.10.3
v21.10.2
v21.10.1
v21.10
v21.08.6
v21.08.5
v21.08.4
v21.08.3
v21.08.2
v21.08.1
v21.08
v21.05.4
v21.05.3
v21.05.2
v21.05.1
v21.05
v21.04.6
v21.04.5
v21.04.4
v21.04.3
v21.04.2
v21.04.1
v21.04
v0.31.8
v0.31.7
v0.31.6
v0.31.5
v0.31.4
v0.31.3
v0.31.2
v0.31.1
v0.31.0
v0.30.7
v0.30.6
v0.30.5
v0.30.4
v0.30.3
v0.30.2
v0.30.1
v0.30.0
v0.29.3
v0.29.2
v0.29.1
v0.29.0
v0.28.3
v0.28.2
v0.28.1
v0.28.0
v0.27.5
v0.27.4
v0.27.3
v0.27.2
v0.27.1
v0.27
v0.26.4
v0.26.3
v0.26.2
v0.26.1
v0.26.0
v0.25.5
v0.25.4
v0.25.3
v0.25.2
v0.25.1
v0.25.0
v0.24.3
v0.24.2
v0.24.1
v0.24.0
v0.23.2
v0.23.1
v0.23.0
v0.22.0
v0.21.0
v0.20.3
v0.20.2
v0.20.1
v0.20.0
v0.19.0
v0.18.5
v0.18.4
v0.18.3
v0.18.2
v0.18.1
v0.18.0
v0.17.4
v0.17.3
v0.17.2
v0.17.1
v0.17.0
v0.16.3
v0.16.2
v0.16.1
v0.16.0
v0.15.3
v0.15.2
v0.15.1
v0.15.0
v0.14.3
v0.14.2
v0.14.1
v0.14.0
v0.13.1
v0.13.0
v0.12.2
v0.12.1
v0.12.0
v0.11.2
v0.11.1
v0.11.0
v0.10.0
v0.9.3
v0.9.2
v0.9.1
v0.9.0
v0.8.2
v0.8.1
v0.8.0
v0.7.6
v0.7.5
v0.7.4
v0.7.3
0.7.2
v.0.7.1
v0.7.0
v0.6.3
v0.6.2
v0.6.1
v0.6.0
v0.5.0
Labels
Clear labels
🎨 Design
📖 Docs Update
🐛 Bug
🐛 Bug
:cat2:🐈 Possible duplicate
💿 Database
☕ Open to discussion
💻 Front-End
🐕 Support
🚪 Authentication
🌍 Translations
🔌 API Task
🏭 Back-End
⛲ Upstream
🔨 Feature Request
🛠️ Enhancement
🛠️ Enhancement
🛠️ Enhancement
❤️ Happy feedback
🔒 Security
🔍 Pending Validation
💆 UX
📝 WYSIWYG Editor
🌔 Out of scope
🔩 API Request
:octocat: Admin/Meta
🖌️ View Customization
❓ Question
🚀 Priority
🛡️ Blocked
🚚 Export System
♿ A11y
🔧 Maintenance
> Markdown Editor
pull-request
Mirrored from GitHub Pull Request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/BookStack#4215
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ssddanbrown on GitHub (Sep 15, 2023).
This post is intended to evolve over time.
Status
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:
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:
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.
Alternatives
Here are potential alternatives along with my very high-level thoughts:
@jsreynolds commented on GitHub (Sep 15, 2023):
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 commented on GitHub (Sep 25, 2023):
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 commented on GitHub (Oct 5, 2023):
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 commented on GitHub (Jan 10, 2024):
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:
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 commented on GitHub (Jun 23, 2024):
Out of curiosity since I saw them on the list, what are your personal thoughts since originally posting, about Codeberg and Gitea?
@ssddanbrown commented on GitHub (Jun 26, 2024):
@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 commented on GitHub (Jul 25, 2024):
Received this notification from GitHub:
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 commented on GitHub (Jul 27, 2024):
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 commented on GitHub (Sep 26, 2024):
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 commented on GitHub (Sep 26, 2024):
@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!
@ssddanbrown commented on GitHub (Mar 17, 2025):
I've now added an alternative system to download PHP dependencies from just a BookStack domain, instead of using composer in production which would normally download from GitHub (and my packages from Codeberg).
This system is detailed here: https://github.com/BookStackApp/BookStack/issues/161#issuecomment-2711914254
@ssddanbrown commented on GitHub (Sep 9, 2025):
I don't think there's ever going to be a perfect time to switch across, so I've been thinking I'll just go ahead and import the project into Codeberg at the very start of 2026.
Until then I'm attempting to clean up the issues a fair bit (would like to get below 500 open issues again), while also reviewing remaining attachments and the best approach for things.
This repo will remain up, maybe in an un-archived state (since I'm not confident on all the effect of archiving) but it will effectively become a mirror. I need to think the best ways to signpost to the main codeberg project, and handle potential issues/PRs. I know we can flat out disable issues on GitHub, but might not want to do that if it stops all existing issue links working.
@ssddanbrown commented on GitHub (Jan 24, 2026):
Just an update on this, I did plan to migrate this main repo over at the start of this year, but faced technical issues with the import process.
I raised a discussion on Codeberg, and am currently waiting for some changes to be merged to attempt the import again:
https://codeberg.org/Codeberg/Community/issues/2295#issuecomment-9888278