With regard to their "what if all the cloud providers block us" issue, it's is a good indication that they're fine. (Page 30 "We rely on third-party hosting providers that may be difficult to replace.") I don't think that's a serious risk.
For the Github thing, you're right, it's a different situation.
You dont see a chilling effect when the choice is either host your content on github or be blasted off the internet?
Lets not forget this wasnt an easy thing for github to handle. Their service still isnt running at 100% normal. Not to mention the cost burden they're currently dealing with.
You're overstating the risks a bit and it's not great to posit implausible motives and means for bad outcomes... Like, Fossil devs could "turn evil", and ship an update that destroys your museum and any copies it can find. Github could "turn evil" without notice, and permanently nuke all of someone or some org's accounts for no good reason and yes, that'd catch a lot of people with their pants down. It's better to first focus on outcomes, not means. Of course anyone actually concerned about losing their github issue data (or having their museums corrupted) should at least be making backups. (And it's not exactly an implausible outcome on its own, you can think of a variety of means that achieve it and discover one may be rather more likely for your situation, like if I was a Russian in Russia right now I'd have already made arrangements in case GH changes their mind or is legally forced to drop the ban hammer.)
The desire to move off github (and therefore any additional services besides hosting you were using, which issues are just one -- new ones keep getting added to try and cement your dependence) is something more worthwhile of thought than the idea of github turning evil. Fortunately that desire is an actual thing that's very common, or at least the desire to not be wholly dependent, and is why many people don't even use github issues to begin with even if they use github itself for hosting (or some other non-issues features). So there's not a big problem, and even if you start with using github issues, there are various migration tools to move github issues out to [alternative]. (And of course github issues have their own merits, people frequently want to switch to them! So similar migration tools exist to move from [alternative] to github issues, I wrote one for Jira years ago.)
It is brilliant to integrate things with the decentralized source control itself, you get free backups and deciding to migrate to something different in the future is easy, I think it's an overlooked approach for a lot of people. (It seems less overlooked when it comes to documentation in various forms like developer-focused .md files, or broader full static html websites which github can conveniently host for you.) Fossil is well-worth investigating for this free integration to see if it meets one's needs. But of course nothing stops you from doing it with git yourself in various ways. For personal projects, I'm pretty satisfied with being as minimal as having an issues.md file and moving things to an issues-closed.md file when I close one. I've also used the git-issue extension (https://github.com/dspinellis/git-issue -- see also its bottom section of Related Work).
But despite its brilliance it's not always the right approach. It's very easy and reasonable to want more than what is realistic for something deeply integrated with the source code itself to provide, if only for inherent conflicts of desire, let alone any question of manpower. There are very good reasons to have entirely separate (and even multiple partially overlapping/integrating/cross-referencing) systems for source code management, issue tracking, code review, forums, IM communication, wikis, public websites, docs (of whatever kinds and types for various audiences and authors, or public or not, or team-level spikes or plannings or retrospectives)... One aspect of Fossil I found weak was its user capabilities (https://fossil-scm.org/home/doc/trunk/www/caps/ -- no custom user categories alone is a deal breaker for so many things) but flaws in the execution of a fully integrated thing isn't really my point, my point here is just that full integration despite its overlooked benefits and brilliance when applied to certain things is still not necessarily the right choice for something.
True - I'm not necessarily agreeing or disagreeing with it. It will send a good message to some people and a bad one to others.
To other government agencies, they may see github as a liability and end up leaving github altogether - I think that's the 'lunacy' part from a business perspective.
Corporations know there's always a chance that they'll get an internet pitchfork mob going after them for some (justified or unjustified) reason, and the last thing they want is for their cloud providers to pile on and further add to the fire.
5. Github as a commercial entity is pretty unlikely to abuse their (indeed worrying, but not scary yet) ability to censor unless some suits decide that they are big enough to not worry about the very community that made them big (IOW, I won't worry until they do a reddit).
I'm not really a GitHub user anyway, but that to me is a complete red flag.
Even if you completely trust the company is doing the right thing with regards to being a man-in-the-middle by design, you're also dependent on them being financially successful and interested in this platform for the app to be useful long term.
Honestly the 'server' part sounds like a solution looking for a problem.
If other ISPs start following the same, you are right in saying I'm downplaying the situation.
But I also mentioned it is unlikely to happen since all major IT Consultancy firms in the country rely on GitHub for their work in one way or another. And not just with their code but also with their client's code.
I doubt that. Github is a paid service and has several enterprise level clients. If it's ever going to flip flop, there will be quite a few warnings before hand.
I doubt that. Github is a paid service and has several enterprise level clients. If it's ever going to flip flop, there will be quite a few warnings before hand.
The PRC's DDoS of GitHub seems a little risky.[1] If GitHub is inventive (or desperate) enough, they could call on their users for aid. The perpetrators would immediately draw the ire of vast numbers of talented programmers. And GitHub is positioned to direct this ire toward useful ends. They could encourage users to contribute to GreatFire, or even start other initiatives and projects to stymie censorship. The outcome could easily be worse for the PRC than if the attack had never happened.
1. Even if this isn't a PRC-ordered or sponsored attack, large parts of their infrastructure are being co-opted. If they aren't criminally involved, they're criminally irresponsible.
For the Github thing, you're right, it's a different situation.
reply