If Microsoft buys Github, there are alternatives.

Jun 03 2018

If you're plugged into the open source or business communities to any degree, you've probably heard buzz that Microsoft is considering buying Github, an online service with a history of having a toxic work environment due to pervasive sexual harassment but still remains the de facto core of collaboration of the open source community - source code hosting, ticket tracking, archival, release management, documentation, project webpage hosting, and generally learning how to use the Git version control system.  At this point it's unclear if they're considering merely investing in the company (currently valued in the neighborhood of $5bus) or buying it outright, the way they did LinkedIn.  Github is certainly an attractive property for Microsoft to consider: The service currently has something like 23 million user accounts and 1.5 million organizations.  I don't think anybody's tried to count the lines of code that Github stores and serves copies of.  It's been observed that Microsoft seems to be carrying out a strategy of controlling as many of the access points to the tech job market.  Not only is Github a highly useful service for managing software projects, but if you're trying to get a job in a technical field having a Github account and a couple of repositories is practically a pre-requisite.

There's also the issue that at least some parts of Microsoft have no qualms against stealing things they think will be useful and filing the identifying features off (local mirror), and fuck the license.  By this, I refer to Learna.  But now I'm getting a little off-track.

As one might imagine, once word got around people began expressing their intention to bail on Github if the takeover went through.  Not that there are no alternatives to Github which not only have many of the same features but are self-hosted, meaning that all you need to do is get an inexpensive virtual machine someplace, install the package, set up backups (you DO back your stuff up, right?), pull your stuff out of Github (easy to do because just about everything is a Git repository), and then push it all back up to your new server.  This is possible because when you clone a Git repository, you get the entire history of the repo - every change ever made, from the very first gets copied to your workstation.  This means that if you then do a `git push` to a new repository, you're effectively making a backup copy of the entire thing to that new remote.  This also means that if there is even a single copy of a Git repository someplace, you can reconstitute the entire project.  This is how I maintain multiple copies of my projects' source code repos simultaneously.  Among these self-hosted alternatives to Github are Gitlab (which is a bit of a bear to maintain, I'm told), Gogs, Gitea, and even Keybase's Git support.

There is, however, another option that I'd like to talk about a little, which I think would be a good alterantive to Github.  It's called Fossil.

Keybase and Git.

Nov 27 2017

A couple of weeks ago a new release of the Keybase software package came out, and this one included as one of its new features support for natively hosting Git repositories.  This doesn't seem like it's very useful for most people, and it might really only be useful to coders, but it's a handy enough service that I think it's worth a quick tutorial.  Prior to that feature release something in the structure of the Keybase filesystem made it unsuitable for storing anything but static copies of Git repositories (I don't know exactly waht), but they've now made Git a first class citizen.

I'm going to assume that you use the Git distributed version control system already, and you have at least one Git repository that you want to host on Keybase; for the purposes of this example I'm going to use my personal copy of the Exocortex Halo code repository on Github.  I'm further going to assume that you know the basics of using Git (cloning repositories, committing changes, pulling and pushing changes).  I'm also going to assume that you already have a Keybase account and a fairly up-to-date copy of the software installed.  I am, however, going to talk a little bit about the idea of remotes in Git.  My discussion will necessarily have some technical inaccuracies for the sake of usability if you're not an expert on the internals of Git.