4 ms·

Does it really make sense to put your company's intellectual property on another company's servers?

timClicks 11y ago
Sure. Many companies use Gmail, for example. 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.
stock_toaster 11y ago
Github Enterprise[1] is a bundled on-premises offering (virtual machine you host yourself). Atlassian has a somewhat similar offering named Stash[2] (I am not particularly a fan of Stash personally though). [1]: https://enterprise.github.com/home https://enterprise.github.com/home [2]: https://www.atlassian.com/software/stash/ https://www.atlassian.com/software/stash/
- dubcanada 11y ago
  Also gitlab is basically a copy of github and more fully featured then stash.
  - icefox 11y ago
    I must say that the fact that Stash still doesn't have WebHooks is embarrassing. We had to write a custom hook in their weird java plugin system to get a part of this screen that GitLab has. https://about.gitlab.com/images/feature_page/webhooks_full.png 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 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.
    - sytse 11y ago
      GitLab CEO here, thanks for mentioning GitLab. I think a 'tag-only' user is an interesting idea. What do you use these build tags for?
      - icefox 11y ago
        A build tag can be used to rapidly go from a commit to a binary and from a deployment to a sha in cases where the build attribute isn't the sha, but a number or version. 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.
        sytse 11y ago
        Isn't it possible to have developers tag the commit in this case? 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.
        icefox 11y ago
        Binaries are built automatically these days using tools like Jenkins, Travis.ci, etc and not by developers. There are many ways to solve this problem such as the build bot making tags in a repository that isn't the main one, but suffice it to say developers are not making the binaries so using a developer account to push the tag from the build machine seems like a permissions bug and letting developers push tags also would risk someone accidentally deleting a tag or pushing a tag that is wrong or can't be reproduced by the build server. 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-build-git-server.html 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.
zachrose 11y ago
^^on-premise^^ means they give you a VM and you run it on your servers.
tracker1 11y ago
You mean like AWS, Azure, Rackspace, DigitalOcean, Linode...? Many already run their code, most of it very easily reverse-engineered, or in scripted languages already available on another company's servers. It's expensive to get dedicated high speed connections and run data centers... this is just one more tool. 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.
- comrade1 11y ago
  So Github gives their product away to people that don't have enough money to host on their own secure servers, and... what else? Where do they make their money? It seems from the comments here that their enterprise market is trivial.
  - tracker1 11y ago
    They make money both from business accounts and from github enterprise... the actual resource costs for hosting the open-source projects is relatively small... The costs for just the business accounts, not including enterprise, for private repositories probably covers their actual costs. 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.

Sure. Many companies use Gmail, for example. 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.

stock_toaster 11y ago

Github Enterprise[1] is a bundled on-premises offering (virtual machine you host yourself). Atlassian has a somewhat similar offering named Stash[2] (I am not particularly a fan of Stash personally though). [1]: https://enterprise.github.com/home https://enterprise.github.com/home [2]: https://www.atlassian.com/software/stash/ https://www.atlassian.com/software/stash/

dubcanada 11y ago
Also gitlab is basically a copy of github and more fully featured then stash.
- icefox 11y ago
  I must say that the fact that Stash still doesn't have WebHooks is embarrassing. We had to write a custom hook in their weird java plugin system to get a part of this screen that GitLab has. https://about.gitlab.com/images/feature_page/webhooks_full.png 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 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.
  - sytse 11y ago
    GitLab CEO here, thanks for mentioning GitLab. I think a 'tag-only' user is an interesting idea. What do you use these build tags for?
    - icefox 11y ago
      A build tag can be used to rapidly go from a commit to a binary and from a deployment to a sha in cases where the build attribute isn't the sha, but a number or version. 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.
      - sytse 11y ago
        Isn't it possible to have developers tag the commit in this case? 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.
        icefox 11y ago
        Binaries are built automatically these days using tools like Jenkins, Travis.ci, etc and not by developers. There are many ways to solve this problem such as the build bot making tags in a repository that isn't the main one, but suffice it to say developers are not making the binaries so using a developer account to push the tag from the build machine seems like a permissions bug and letting developers push tags also would risk someone accidentally deleting a tag or pushing a tag that is wrong or can't be reproduced by the build server. 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-build-git-server.html 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.

zachrose 11y ago

^^on-premise^^ means they give you a VM and you run it on your servers.

tracker1 11y ago

You mean like AWS, Azure, Rackspace, DigitalOcean, Linode...? Many already run their code, most of it very easily reverse-engineered, or in scripted languages already available on another company's servers. It's expensive to get dedicated high speed connections and run data centers... this is just one more tool. 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.

comrade1 11y ago
So Github gives their product away to people that don't have enough money to host on their own secure servers, and... what else? Where do they make their money? It seems from the comments here that their enterprise market is trivial.
- tracker1 11y ago
  They make money both from business accounts and from github enterprise... the actual resource costs for hosting the open-source projects is relatively small... The costs for just the business accounts, not including enterprise, for private repositories probably covers their actual costs. 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.