To expand on your point, this CodePlex post mentions there were 350 projects with commits in the last 30 days. I'd venture to guess that number was much larger for GitHub. The people have voted on which service provides the most value.
A `PushEvent` is fired for every open source repository that has `master` updated:
``` SELECT COUNT(*) FROM ( TABLE_DATE_RANGE([githubarchive:day.], TIMESTAMP('2017-03-01'), TIMESTAMP('2017-03-31') )) WHERE type = 'PushEvent' ```
It's over 19 million!
SELECT COUNT(DISTINCT repo.id) FROM [githubarchive:month.201701] WHERE type = 'PushEvent'
I got 1896676, so almost 2M distinct repos with commits in last January.
There's no ambiguity there. It's just how the language works.
Tim: "It's a little known fact that Woodrow Wilson signed the Treaty of Versailles while ice skating on the royal pond." Bob: "That's clearly nonsense. The Treaty of Versailles was signed in June."
It would be very different to say, "the Treaty of Versailles was signed last June." That would imply it was signed in June 2016, rather than June 1919.
"I saw that film last January."
"I saw that film in January."
As the other commenters have mentioned, "last January" may mean January 2016 for them, whereas for others it's 2017. The second example should be a definite 2017, except you always have your occasional smart alec [0].
I would disagree with jasonkester--there is ambiguity here.
_If_ "I saw that film in January", definitely means 2017, it requires quite deep semantics, as chancing it to "My birthday is in January" shows.
What about 'this past', is that used to refer to the latest instance or is that also last complete cycle?
I would interpret "this past" as most recent thing from the current. So "this past January" would, to me, sound like the most recent January (Jan 2017)
Make code reviews your number one priority. Be the place that people want to put their code in, because they can review code, significantly easier on your site, as opposed to GitHub's. Make management your number one priority. Be the place that can provide managers with code metrics and analytics, that GitHub can't. And so on.
To take mind share away from GitHub, you'll have to treat Git hosting, as a secondary thing. You can't be a derivative of GitHub and expect to compete, and succeed. Like Snapchat, Instagram (before acquisition) and others, you can only compete with Facebook, from a completely different angle.
If you can provide a novel solution, that cannot be easily duplicated by GitHub and others, getting users to store code with you, will be significantly easier. With GitLab, Gitea, Gogs, etc., Git hosting has turned into a commodity product, which means you'll need to focus on providing value based on the code stored and not the management of the code.
This isn't really a high bar. Doing more than one iteration of code review with GitHub's tooling is a complete mess. In addition to that, both PR comments and Commit comments exist which can be extremely confusing if you do make one when you meant to make the other.
There is already other tooling which leverage GitHub's APIs to provide a nicer interface for code review.
GitHub provides a list: https://github.com/integrations/feature/code-review
I don't think that that is an exhaustive list; for instance GerritHub is missing (although I'm not a fan of it).
That seems to be Microsoft's approach with Visual Studio Team Services. Whereas Github seems to be focused on code, VSTS is more focused on integrating every step of software development, with version control, work item tracking, continuous integration, etc, all living in one integrated package. Now, this means that the version control aspect of it isn't as good as that of Github's. But, the issue tracking is far superior, and you don't really need to invest in learning separate software (like Travis or Jenkins, or what-have-you) in order to get continuous integration working.