Hacker News Reader

Comment by comrade1 | Hacker News Reader

How does github make money? I read the article but it's only a couple of paragraphs.

Github seems to be mostly personal and open source projects. With good reason since it's trival to set up a git server yourself and so you'd only want to put up stuff that you want public-facing. But it's not so trivial to set up the web ui in git server and so I could see some value there (not sure if $2B of value though)

I used github at a company but only for some code that we wanted to share outside of our company. And if we had to pay for it we never would have used github since we could have spent a 1/2 day setting up a public-facing git server.

We would never have used it for our internal code - again, it's trivial to maintain your own git server and it would also be irresponsible of us to put our internal code on a public-facing server.

So... what makes them valued at 2B? Do they have any revenue at all? Maybe they can hook up with linkedin?

View on HN

I don't understand why McDonald's is valued at $100b. Personally, I don't eat hamburgers, so they get no money from me. After all, it's irresponsible to eat junk food. So I have to ask, do they even have revenue at all? How are they still in existence?

McDonalds has a huge amount of revenue! Are you kidding us?

Whoosh.

I asked about revenue. His ironic comment completely missed the point.

He's satirizing your comment.

The idea being that just because you don't find inherent value in something doesn't exclude others from finding their own value and additionally triviality doesn't necessary preclude others from claiming value.

It's the argument of a two-year-old. I asked about revenue, not about personal value.

If i remember correctly the biggest asset of McD is property they own.

Github is about $25 a month, which is probably worth it for any organization vs. the cost and engineering resources to maintain a redundant and available git server. Sure it is pretty trivial, but so is paying $25 monthly.

Also, if you are a small organization you could pay as little as 7 to have a private repo.

https://github.com/pricing

But why would you put your IP on another company's servers? I guess if the value of your company was something other than your code then it would make sense.

There is a ton of application code out there. Not super secret IP involving a secret new method to compress audio.

It's mostly CRUD applications with some business logic mixed in.

Nobody is trying to steal your CRUD code.

Edit: just to clarify. I don't mean your crud code specifically. Just crud code in general. Maybe you specifically have some super amazing IP to guard.

> super secret IP involving a secret new method to compress audio

Pied Piper?

That ship sailed about a decode ago.

And I know you probably think IP/code is a company's most valuable asset but for most companies that's not even close. A company's most valuable asset is how it goes about delighting customers.

So, no competition doing competitive analysis?

I don't understand.

If you're suggesting that IP/code sitting on GitHub servers is somehow at risk of being divulged then I will disagree.

There have been multiple examples of github's poor security over the years. https://github.com/rails/rails/commit/b83965785db1eec019edf1...

and also poor security on the part of programmers where they submit ssh keys, for example, to publicly facing projects.

>But why would you put your IP on another company's servers?

Not sure I understand this. Isn't uploading your code to an AWS box "putting your IP on another company's servers"?

Unless you host your own email, servers, chat, storage and backups, you are putting your IP on another company's servers.

Yes, it is trivial to run your own email, storage, backups, etc. In fact, you can't even use amazon for email since you can't set up a ptr with them.

But if you do want to use Amazon securely I believe that they have the ability to encrypt your drive.

That said, rack space is incredibly cheap these days, and throwing in a 1u ubuntu server in a 1/4 secure rack is cheaper than hosting a dedicated vps at amazon.

I completly understand starting out using shared services as a startup, but eventually, and soon, you'll want to move to your own systems. It's just an expense for your business, and you would be irresponsible to leave your systems vulnerable.

(my projects have been more sensitive in the past than the typical CRUD app, and so perhaps I'm paranoid)

Except I would rather trust a service like tarsnap to host my backups securely, or amazon with kernel updates than doing it myself. Hosting my own backup server is "trivial" only if I have the expertise to encrypt it properly, and keep the box updated and safe from vulnerabilities.

Moving to our systems only makes sense to me if its a core part of my business or if 3rd party solutions are inadequate. Paying 2 engineers $75/hr to reinvent IRC/git/email poorly is a poor use of time and money.

At the end of the day, if GitHub steals my IP (for whatever reason) I can sue GitHub (if its not morally wrong, they have a legal reason to discourage them from doing so). If my "1u ubuntu server" is hacked due to a poor default, I have no recourse.

Because they handle the hosting, redundancy, backup, etc.

So first you wanted to know if they had revenue. You got our answer and now you want to know why so many people are paying them money.

You know the answers to all of these things. Just come out and say what you think about Github and their business model instead of wasting our time answering these supposed questions.

GitHub for Organisations is $25 a month for 10 private repositories.

More repositories means more money.

Github Enterprise. Turns out that maintaining a git server and the familiar and great (imo) UI is something that medium-large companies generally have no interest in doing in-house and will gladly pay for.

  > So... what makes them valued at 2B? Do they have any
  > revenue at all? Maybe they can hook up with linkedin?

It has been speculated[1] that certain companies/endeavors derive some part of their value from the fact that VC firms and other investors view them as a "force multiplier" for _other_ startups. They have some amount of value simply as being an integral part of the overall software/startup ecosystem, and investors may want to keep a good things going. Further, investors may desire to keep Github from being acquired by some larger company with a different agenda. Investing at a high valuation may result in a lower likelihood of an acquisition.

Certainly Github would qualify, if that is the case.

[1]: http://words.steveklabnik.com/is-npm-worth-26mm

> 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.

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

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.

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

[2]: https://www.atlassian.com/software/stash/

Also gitlab is basically a copy of github and more fully featured then stash.

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.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.

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?

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.

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.

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-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 use GitLab CI to build the binaries and push them. The binary build is triggered by a developer setting a tag.

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.

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

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.

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.

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.

GitHub almost certainly makes almost all of their money selling their on-premise Enterprise product, as I and others have mentioned. Pricing on this product is $2,500 per 10 users per year.

They have a paid tier, the primary feature of which is private repos.

Github Enterprise certainly makes money. How much I do not know.

There is no logical explanation for the valuation. It's pure especulation.

Speculation is based on logic.

Could you explain further?

Reply on news.ycombinator.com