GitHub Enterprise

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

I don't get it, is the value of hosting projects on your own servers worth the substantial leap in cost over GitHub.com?

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

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.