20 comments

[ 5.0 ms ] story [ 50.7 ms ] thread
Interesting observation - the pricing stays constant at $21/user/month till 2999 users. It changes to 'Contact Us' zone after this.

On the other hand, Atlassian's enterprise offering, Stash, has a different pricing structure with only a one-time payment. Infact, for 2000 users, the upfront costs are 48K versus Github's 2000 user pricing at 500k per year.

I wonder about this large discrepancy in pricing structures between two kind-of-close competitors..

It's much easier to lower prices then raise them?
A company that has 2,999 developers is spending about $450 million per year to keep them employed, now it costs them $450.5 million. As you can see their pricing is a rounding error.

If you pick up the phone and mention Atlassian I'm sure the price will drop to something comparable.

That 0.5 is not a rounding error.
(comment deleted)
I don't get it, is the value of hosting projects on your own servers worth the substantial leap in cost over GitHub.com?
Keeping their code within their own firewall is a big deal for many companies.
Yeah, and in some cases "big deal" == "legal requirement"
We've considered it for the research department I'm part of at a university. The nice part is that we all know and like github, but need to keep the repos private or on premise, depending on the grant. Further, a lot of research code is based on another project's code, and a git fork is so much nicer than mailing around tarballs, particularly after having had the task of taking a project, and trying to incorporate several teams' individual modifications back in into the core to base further research on it.
The campus site license at $2500/year license seems cheap relative to the normal price
You can do your own logins such that every employee immediately has their own login and ability to create infinitely private and public repos visible only by others in the org.

Stuff like that.

A previous employer was dead-set against using Github's public site and insisted on using Github Enterprise. They were simultaneously resource-stingy and thus we had to bend around in all sorts of uncomfortable ways to minimize the amount of employees we had with Github Enterprise logins to keep costs to the bare minimum. Needless to say, this was a messy and stupid situation.

Perhaps there are some companies for which Github Enterprise makes sense, but it seems like the number of potential matches for it being a really good fit is small. Most companies should just use Github.com or if they really need to keep the code out of "the cloud", just use plain old git with gitlab, gitorious or plain old ssh access control.

Disclaimer this is a shameless but timely plug for my company's product.

I've been building a solution to enterprise GitHub's pull request model for the last year. I believe they have a great product but their current pull request system will never meet a large organizations requirements which are process heavy.

For example it's not easy to assign something like a risk value to a pull request. You also can't assign a required approvers list to a pull request. Basically you can't assign arbitrary meta data to a pull request. Enterprise is driven by process and everybody seems to want to do things there way so you'll have to have a very flexible system. You can probably hack something together with tags but this will never fly in a process heavy enterprise which adheres to strict ISO standards.

Also GitHub's pull request/code review doesn't handle large changes well. When the number of changes get's into the few dozens, hundreds or thousands, using their interface is just impossible and impractical. And yes changes of this size is not uncommon in the enterprise world.

I've attached some screen shots that shows how I'm planning on improving GitHub's pull request model. Note I haven't included any examples that showcases my programmable context aware smart attributes technology as I'm still keeping this under wraps. But the smart attributes are what should allow GitHub's pull request model to work in any process heavy enterprise environment. In a nutshell, you can think of the smart attributes as meta data that you can attach to a GitHub pull request, a file, a diff, etc. These meta data are context aware, programmable and can be assigned a value based on the smart attribute data type.

Searching for pull requests across multiple branches

http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e...

Viewing the pull request detail

http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e...

Viewing the code churn that is generated by the pull request as a churn tree

http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e...

Viewing the commits that are part of the pull request. Note the revisions tree on the left. It'll show you all the revisions that in all the commits.

http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e...

Is this your own plugin, or your own service?
It's my own product/service. I have my own diff, commit and source viewer. With my setup, the only time that you would use GitHub is to make comments.

Here are some additional screen shots of the other tools.

Unified diff view

http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e...

Side-by-side diff view

http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e...

Blame source view with timeline highlighting

http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e...

Creating your own custom diff view.

http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e...

Commit view

http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e...

Edit.

Added source tree screenshot

http://6b507fb6377c7b2ce0ed-f6f6a52addfcf546a4b633fce1dd247e...

Looks great, but the price is exorbitantly high for a large number of users :(
The target demographic for this product does not feel that way :)
GH pricing is on-par with other enterprise VCS offerings.

Kind of disappointing really, having "cheaper than XYZ" is a nice feature to sell to management.

If you're competing on "awesome", being cheaper isn't an advantage, and also damages the brand.
(comment deleted)