15 comments

[ 2.7 ms ] story [ 24.5 ms ] thread
Microsoft's acquisition of Github hasn't closed yet, so the company is still operating independently. There is no reason to think that this has anything to do with Microsoft.

To be honest, it seems like a fairly simple mistake that was cleaned up within 48 hours. Certainly a pain in the ass, but these things happen.

The Microsoft-fear in this article isn't justified.

However, the author does point out several good practices:

* Don't host your code only in one place

* Don't host your services only in one provider

* Don't host your backups only in one provider

I suppose you could argue the second one, but the other two are important to follow.

Yeah, treat code as any kind of data.

If it's worth a lot of time and cannot be replaced easily, back it up.

imho he mostly talks about vendor/provider lock-in.
Is it even legal to allow the acquiring company to direct your activities before the deal closes?

It seems like it could run afoul of anti-trust laws if you are functioning as one company in a situation where the merger might not get government approval.

I also wonder if it could cause liability issues because, until the deal closes, you are obligated to do what your current owners want you to, not your hypothetical (but probable) future owners. Especially if you are a public company and those owners are shareholders that you probably have certain legal obligations toward.

Regardless of legality it doesn't seem like they are running this show. Take for example the fact that Microsoft projects in Github are STILL undergoing verification. If MS was pulling strings there'd be no reason for that at all. Just instant verifications all around.

There may be some unspoken preference towards MS or something, but, if so, it's not super evident. And given the pre-existing relationship between devs at both companies, it could also just have been there beforehand. It would be pretty impossible to know.

Their Github account at https://github.com/prowriting looks boringly normal. I wonder what could have caused Github's systems to flag it and a customer service rep to decide it was not legitimate.
There doesn't seem to be much going on there? Over 13 repos, there are like 5 issues, all open, with one response that seems to be from some other user who just randomly wandered in? There are a few commits and a couple of branches, but no releases. Also a couple really ancient forks. This looks like a random person's GitHub page, not a software company's.

They also don't have any links to their GitHub pages on their site. This isn't how organizations normally use GitHub. One suspects they're just using it as a CDN without engaging with any of the coding or social features. Perhaps GitHub has some sort of trigger when particular resources get requested over and over without any referer? Why not just use GitHub normally? Failing that, why not just use a CDN?

CDNs cost money. The whole point of most businesses lately seems to be externalizing costs while providing the least amount of service that they can get paid gobs of money for. I understand that's a sound business model in a race to the bottom, but eventually you hit the bottom and the whole market losses.
They don't cost enough money to justify this whole embarrassing episode. Probably they're just a little bit harder to configure than it was to just dump everything on GitHub.
But now, think this whole thing in this way: Should GitHub block them because of all that?
That's really up to GitHub. They have to weigh the cost of being the lazy dude-bro's CDN against the bother of dealing with entitled whinging like TFA. To be clear, they certainly are justified in blocking this user. GitHub is for collaborative development, not code distribution.
(comment deleted)
(comment deleted)