In light of the recent news that Microsoft aquired Github, for obvious reasons it would be wise and strongly advisable to make moving all bisq code to Gitlab or another platform a priority to continue the safety and security of the program and its peers.
1 Like
I wouldn’t be surprised if Manfred was researching alternatives today, but we will have to wait and see what he thinks about it.
Yes I agree. I don’t think that there will be any real changes soon on GH but it is definitely something we should discuss. Just will take some valuable time which will miss on other stuff. We also use GH quite a lot with integration for Slack etc,… that will likely not work anymore…
I will wait for @cbeams opinion who we will deal with it…
I did read that, since gitlab-CE is open-source, it’s possible to install a own instance.
If there is interest for that, I could give it a try on a VPS ?
[I believe a VPS in Europe would be the best (I have seen some lag with eg VPS in Asia)].
If a move is to be decided in the future, there is probably no need to move everything in a single move.
It could be for instance only moved 1 or 2 non-critical repos at first, just in order to see how it works ?
Having a plan for moving away from GitHub has been on my mind for a long time. The major risk we have always faced with GitHub is the same risk we face with any third-party service provider: the risk of being de-platformed. If for some reason GitHub decides that projects like ours are not welcome, they can just shut down our organization and tell us to go to hell (just as MailChimp did a couple months ago). This would cripple our communications for a time, but the production Bisq Network would be unaffected.
I have considered this risk low until now, because GitHub has had (as far as I know) a perfect record of never de-platforming a project for any reason, political, regulatory, or otherwise.
Now I consider this risk to be increased at least somewhat, perhaps approaching a medium level, because Microsoft is simply playing in a different league than GitHub when it comes to compliance with global regulations. I haven’t researched this deeply (yet), but I can only imagine that MS would be more likely to enforce policies that could lead to Bisq getting de-platformed than GitHub would have been.
Here’s what I am not worried about: that MS is suddenly going to do Bisq harm in some way, just because they’re evil. We have no private repositories under the bisq-network org, meaning that we have no private data (and certainly no user data) for them to exploit, leak to governments, etc. I too was deeply saddened by the news of the acquisition (I actually had nightmares about it that night!), but I do not see any near-term attack vector that we’re now exposed to just because MS is at the helm. The only risk I’m really concerned about is that Bisq and other crypto projects somehow get ground up in the machine of regulatory compliance one day probably not very soon.
If others think that we are somehow facing a more pressing danger than this, please do speak up, but for now, I think what we should do is start getting at least a bit more serious about contingency plans. No need to panic. Trying to move off of GitHub right now, without a good reason—and especially without a good plan—would be a productivity disaster.
In order to put together such a plan, here’s what I see we need:
-
Documentation about how we use all the different features of GitHub to form Bisq’s communication and collaboration backbone. There is the obvious stuff like our repositories and the code and issues within them, but then there is the Slack integration, the use of GitHub teams, the use of the bisq-kitty account to feed notifications into the bisq-github mailing list, and a number of other things. This is all stuff that I plan to document at https://docs.bisq.network, and this week’s news makes doing it that much more high-priority for me.
-
Once we have that stuff written down, then some contributor(s) can spin up an exploratory effort to replicate our use of GitHub on a self-hosted GitLab instance. As far as I know, GitLab is the only contender for a GitHub replacement, by the way. There are other Git hosting platforms, of course, but none have near the feature set of GitHub. GitLab was created expressly as a GitHub clone and alternative, and has done a good job of that, as far as I can tell. Indeed in certain ways they’ve surpassed GitHub’s feature set (with sweet features like being able to properly move issues across repositories, for example). Anyway, the contributor(s) looking into this migration could do a trial, and put together a report / proposal that shows which of our documented uses of GitHub can transition smoothly to GitLab, and which cannot. For those that cannot, they can put together an alternative approach, etc.
The point here is that any such move should be very carefully considered. Even if we can get 100% feature / use-case parity between the two, we have to think about stuff like the hassle of self-hosting, and trying to replicate the basically perfect global availability and low latency that we enjoy with GitHub today. Achieving that same quality of service when self-hosting is by no means easy, and it would be infuriating if our GitLab instance were slow, or going up and down all the time for some reason. This approach would create a level of operational requirements around our communication infrastructure that we haven’t had to deal with at all so far. We would need contributors who are really on top of that GitLab instance to make sure it’s rock solid. Maybe GitLab has options here that get self-hosted instances close to GitHub levels of reliability out of the box, I don’t know. Maybe we could go with GitLab’s hosted service initially, knowing that we can move to self-hosted easily if and when we need to. Again, this is all the kind of stuff that some dedicated group of contributors needs to carefully think through and plan out.
Those are my thoughts on the topic so far. Other feedback welcome of course.
2 Likes
A friend points also :
https://gitea.io/en-US/
https://gogs.io/docs
It pretends to be more simple.
Did anybody here already test ?
It must be pointed that neither gitea nor gogs exists as a debian official package,
while gitlab is (a huge one) : https://packages.debian.org/stretch/gitlab
(yes, I consider being on the official debian package repo as some quality/virtue signaling 
).
Thanks @cbeams for your feedback and overview!
Regarding using GitLabs hosting services:
I fear we would risk to repeat the same story then. Once GitLab (which is a commercial company like Github) would once make an exit we have to move again - though moving hosting only might be easier.
I just feel that those corporate structure are wrong for infrastructure where we need and want independence. As a client of a company you get sold at an exit and are vulnerable to arbitrary politics like it happened with MailChimp.
I would prefer to take the extra costs and possible lower performance in account and go for self hosting. Such a model would also have dependency on the person who is doing the hosting but there we can use our BSQ features to secure us (bonding).
Not super strong opinion here, just my 5 cents.
And I agree we should not rush here, there is not short term risk but as a matter of principle we should prepare for the right thing…
I see no urgency in moving right now but being prepared to move makes a lot of sense. It also seems correct to eventually keep this part of Bisq outside of centralized services.
Making sure not to disrupt the daily work flow is more important than an immediate move. Since everything that happens within the project is open for anyone to see and the worst effect from being kicked off github right now would be the break of work flow the suggested gathering of requirements and eventual move whenever we’re ready for minimal disruption sounds like a good plan.
1 Like