> How does github make money?
GitHub Enterprise[1].
> And if we had to pay for it we never would have.
I think you're the exception.
[1] And private repos, but I'd imagine that 80%+ of their revenue comes from on-premise enterprise deployments.
GitHub Enterprise[1].
> And if we had to pay for it we never would have.
I think you're the exception.
[1] And private repos, but I'd imagine that 80%+ of their revenue comes from on-premise enterprise deployments.
The risk/reward payoff is different for every company, and there are many who will outsource the hosting of much of their IP because the alternative is often a hindrance to companies who want to ship their core product.
https://about.gitlab.com/images/feature_page/webhooks_full.p...
But still all three GitLab, Stash and GitHub have horrible permission capabilities. Looks like GitLab might be the "best" with what they have http://doc.gitlab.com/ee/permissions/permissions.html, but that is still pretty poor. A simple example would be the requirement to only allow a single user the ability to create tags, that user being the build bot. Enterprise's of course have all sorts of unique permission models that they want to abide by and most of them could be supported out of the box with a more fine grain model.
There are many other permission uses cases such as fine grain create and delete branch permissions. Only the release users should be allowed to create release/* branches. No one should be allowed to delete the 'master' branch.
There are projects where I want to give developer access, but they are not allowed to create or delete any branch, they can only push new changes that are "finished". If they want to make a in progress branch they need to do it somewhere else.
We already have the different between master and developer uses on protected branches. But it is an interesting idea to protect release/* and stable-* branches by default.
The third paragraph is a bit of an edge case to me. Either you allow them to participate in non-protected branches or you have them work from a fork. Pushing changes is on the same level as creating branches to me.
Another example is having a machine the mirrors a perforce, svn or other rcs. This bot will push up the mirror to a single branch called say 'svn-mirror'. You want to make sure that the mirror bot is the only one that can ever touch this branch. Again the mirror could be its own repo and no one else could be allowed to do anything, but users like to have the mirror along side the other main branches that they can push to.
I can give you a dozen "edge case" examples, each of which I have seen not only desired, but required. Lack of fine grain permissions are one of the three reason why companies (not individuals) will abandon an existing Git server and replace it with an alternative. (See http://benjamin-meyer.blogspot.com/2014/10/so-you-want-to-bu... for my full writeup) And you can't say it is hard to implement either, these permissions are nothing but cascading ref based permissions. A user or group has permissions to read/write/delete a ref or ref regular expression. Honestly just copy what gitolite (which has no frontend so it constantly being passed over) does and you will be ahead of all of your competition.
Add fine grain permissions to GitLab and I would recommend exploring going through the major hassle and pain of replacing Stash with GitLab, that is how valuable of a feature it is. Eventually Stash and the other Git servers will have this capability, might as well beat them to the punch and take some of their customers.
We want to integrate the mirror bot into GitLab itself, allowing you to track external repo's.
We would love to have the permissions of gitolite if we can implement them without complicating the settings for users that don't need this. I would be happy to look at prototypes how to implement this in the UI (I'm @sytses on twitter).
GitLab is open source, so if someone wants these advanced permissions the best way is to build them.
In the case of Github, source control is their primary business... Their lead-in is free to open-source, and this builds a lot of good will. Not to mention that Github Enterprise is a pretty nice project... if they come around to add better traditional project management support, I think it will be one of the best options around.
It's extremely easy to setup a private git server (Linux + SSH + Git), but the extra tooling and visibility they offer to non-programmers is what sells. Not to mention very transparent tooling with Go and NPM.
I know that some people prefer Bitbucket because they have free private repositories too... but my concern there is what is their business model in the end? Github has a simple, effective business model and strategy that works. The good will in the open-source community (from gh-pages, to easy forking/sharing/pull-requests) has made them the first choice for most (at least newer) open source projects at this point. This brings loyalty, so when you job needs to host private repositories, it's only natural to use the same platform you're already interacting with. This is a pretty significant impact.
The only down side, is their dedicated clients, and tooling that is geared only towards their platform. I don't like lock in, and while I don't think that is their intent, it will lead down that path for some. I also find that GUI tooling for Git in general is kind of crappy, though it's hard to carry the flexibility git offers in a GUI while making the most common workflows straight forward. Dealing in a very small team with few branches working mostly against master is much different than several large teams working on a codebase with many branches/conflicts in play.
As a business strategy, Enterprise software has plenty of room for a profit margin. As it stands, they have mindshare and are probably actually breaking even, or making at least a modest profit. This funding round is probably more about flushing out their enterprise offerings, so they are better in terms of competing with alternatives, or even bringing in better bridge/migration support.
I've seen/used Jira, TFS, SVN and plenty of other systems that integrate project management and source control. There's definitely room for much better tooling here, and Github is in a better position than most to take over this space.