Version Control System
Version control systems (VCS) are widely used by software developers these days for a good reason. By keeping track of all changes to a set of code, and allowing developers to create different “branches” or “trees” of the same base piece of code, a VCS can speed up the whole development process. It can save a lot of headache especially for projects that are being developed by a team of people (though anyone trying to learn Git – one of the VCS’s – for the first time knows it can cause its own fair share of headache too). The two most popular VCS’s these days are Git [http://en.wikipedia.org/wiki/Git_(software)] and Mercurial [http://en.wikipedia.org/wiki/Mercurial] . By popular, I mean that if you are a developer about to start a new project, high chances are you going to be choosing one of these two for your VCS. But, notice though that I said “anyone trying to learn Git for the first time.” Git is definitely the dominant force. VCS’s are one of those things strongly influenced by network effects, and it seems for the time being, Git is the winner of the hype war. It has gotten to the point where if you are first learning how to use VCS, you are going to be taught Git. Then later on if you are interested, or want to work on a project that is using Mercurial, you can learn that. Keep in mind I am talking about for the majority.
I won’t try to get into the history of how Git managed to become the more popular (For starters, it was created by the same person who created Linux, who really pushed it at a crucial time). But, via the lens of ECON 2040’s material, it is clear to see why it is staying that way, and why it will continue to stay that way for the foreseeable future. The reason VCS is so strongly under the influence of network effects is that any code project really only uses one (e.g., either Git or Mercurial). Thus, anybody who works on that project will have to understand how to use the VCS that that code project chose. So, if you are starting a new project, and you want to make sure that your choice of VCS will least-deter someone from working on your project, you are going to choose the most popular one out right now, which is Git. You will both directly benefit from having less friction of getting new developers involved, and given the popularity factor, you know that there must be some reason that the majority of others are using it. It is the safe bet. If you are a company and you are trying to make sure the least amount of time is spent into getting employees achieving maximum productivity on your software products, you are going to try to maximize the number of people who don’t have to learn how to use a new tool, so you are going to use Git. It seems clear that this is a case of the rich getting richer for the time being.
There is a lot more to dive into in that side of things, but there is also the websites that host these VCS-backed code projects on the internet, that help people find, explore, and contribute to other people’s projects. The two most popular repositories (again, defining popular by where the bulk will go) are BitBucket [http://en.wikipedia.org/wiki/Bitbucket] and GitHub [http://en.wikipedia.org/wiki/GitHub]. GitHub is by and large the winner right now, being the largest code host in the world [http://flosshub.org/sites/flosshub.org/files/lean-ghtorrent.pdf]. However, there is a bit more interesting material to look at under the ECON 2040 lens. Despite GitHub’s dominance (for solid reasons too, I think I can say quite objectively without trying to dive too far into that topic), BitBucket has managed to stay relevant for several reasons, two of which I will mention here. One is unlimited private repositories. This means you don’t have to pay anything to store any number of code projects privately (no one else can see them), while as for GitHub, you are allowed zero (instead, they offer unlimited public repositories). Also, BitBucket supports Git and Mercurial, while GitHub only supports Git. Thus, it seems both seem to serve quite different markets. For example, a common use case these days is for one to host all their personal private projects they want to keep private on BitBucket, and ones where they want to collaborate with others on GitHub. Recently, a big open source programming language spearheaded by Google called “Go” announced they were moving to GitHub four days ago, citing “Mercurial has served us well, but it’s time to move on. The world today is quite different from the world then. Most members of the Go community use Git and host their work on GitHub, and we should join them.” There have been bit moves like this more recently, but it seems like both BitBucket and GitHub have managed to past the big hurdle of the initial turning point, and gained popularity for different use cases and developers. If they both served the same purpose, it would likely make sense for everyone to just switch to the one everyone else is on. But, by having different pluses and minuses, while staying extremely useful for their users, both stay popular — and continue to gain popularity.