Beyond GVFS: more details on optimizing Git for large repositories

I've said it before, but if I were Atlassian, GitHub or GitLab, I would be very worried of Microsoft about now. I tried Visual Studio Team Service (VSTS) last year, and I wasn't all that impressed. In fact, I found it quite frustrating, since I found navigating within VSTS, quite confusing. Simply importing a repository was non-trival, when compared to Bitbucket/GitHub/GitLab

My initial impression wasn't all bad though, as I was really taken back by how 3rd party developer friendly it was. Having worked in large Enterprise environments, I wouldn't be surprised if this extensibility, was not partly driven by their own internal need, to minimize/eliminate push back from other internal groups.

Now fast forward a year and having remembered how extensible VSTS was, I figured I would re-evaluate integrating my search/analytics engine with VSTS again. I wasn't expecting anything different, since my first impression was quite "meh", but upon revisiting VSTS, I can honestly say, they've come a LONG way.

I personally think their biggest improvement, was simply providing a simple overviews page that lets me see, all the projects that I have permission for. And if memory serves me right, the dashboard was what you were greeted with when browsing a project, and I personally found that to be too overwhelming. Having come from the Bitbucket, GitHub and GitLab world, the dashboard was just too much "new" stuff to process. In this second time around, I see the dashboard is no longer what is thrown at you right away, but rather, the focus is a simple README page, which I think will go a long way to help acclimatize Bitbucket/GitHub/GitLab users to VSTS.

The conclusion that I've come to with VSTS, is it is optimized for productivity. What VSTS doesn't do is social. The social aspect that Bitbucket/GitHub/GitLab has, is non-existent with VSTS, and having worked in Enterprise, I've found social means almost nothing. Most Enterprise programmers, see it as a job and all that they want to do is not have to work late and/or weekends. Since VSTS is quite extensible, programmers/testers/managers/etc. can address edge cases that are unique to them and/or their company, which is what I think will help Microsoft win over enterprise in the long run.

Microsoft has been in the game long enough to know, one solution, does not fit all. And I'm guessing they've learned a lot from trying to get VSTS adopted internally (both technically and politically). With GVFS (driven by their own internal need) and Microsoft working on getting Ubuntu to work seamlessly in Windows, I think they will be a force to be reckoned with.

They (Microsoft) can't shape how Git is developed, but they can shape how it can be used (maybe mono-repos will be the future?) and they are slowly building up quite a bit of technology, that may be too much for GitHub and others to compete with.