Fisheye is $800 for 10 users, $1200 for 20, plus the required JIRA install, which is $1200. Add a Wiki component (Confluence) and you can add another $800. The proper code reviewing tool (Crucible) is $800/$1200. Thats (roughly) the feature set of Github, without the source hosting/ssh-key-management stuff.
So summed up:
10 Users: $3600
20 Users: $4400
So, they are definitely cheaper, but I'd say that $5000 for 20 users is a competitive price for such a huge infrastructure.
Atlassian also has bitbucket, which is a direct competitor to github and priced at $10/month for 10 developers or $25/month for 25 developers. So, it's only $240 a year for 20 developers (https://bitbucket.org/plans). It may not have all the features of github, but they provide basic git hosting, wiki, and issue tracking. Do the extra features of github justify 20x higher price?
They also have a free plan for up to 5 developers.
The Starter Program covers the first 10 users for all but one of their products for $10 (each product, downloadable version) with proceeds going to Room to Read:
FishEye actually has built-in git management as of the last release, but everything else stands. Plus, FishEye's git handling has always been a bit odd, particularly how it handles branches.
A bit confused why you think that is the same feature set of Github. The core product here is JIRA and everything else is accessories. What does Github give you in the way of project/ticket management? Also what is the Crucible equivalent?
I would say that one major distinction is that Github is a tool designed to manage repos and make sharing code easier, with a ticket tracker bolted on. The whole Altassian suite is centered on JIRA, so it's more of a ticket tracker with code viewing and review tools bolted on.
It's a subtle but not insignificant difference and depending on your needs, either one could be a good fit.
At, $250/user/year its cheaper than any published perforce pricing (from http://www.perforce.com/purchase#) Of course perforce is about as expensive as it gets for enterprise vcs
Funny thing is we ditched ClearCase for SVN several years ago because of how horrible a product it was. I've generally enjoyed Perforce, but for our SCM needs at the time SVN more then suited our build and deployment strategies.
$250/seat/year is actually fairly cheap for enterprise development products. The administration cost in IT staff is likely to be much higher.
It sounds good, though I guess my fear would be that git's mindshare in the kind of locked-down IT environments this is targetted at is still fairly low. Clearcase still rules in that world, and a SCM system is among the least flexible infrastructure items.
We're using Gitorious at Forbes, which has been great for us. $5k is more expensive than free, but I think Github has the development community mindshare (more free tools) and, in some cases, a technology advantage, such as managing pull requests.
- Enterprise is delivered in an OVF, which means it's a fully contained VM. This simplifies deployments astronomically from the previous FI architecture.
- We've spent a lot of time on the runtime and packaging of Enterprise in relation to how it runs the code. It's now much faster.
- We've changed how we merge the two codebases (.com and FI/Enterprise). Effectively, they are the same now. This means new features that come to .com will come to Enterprise quickly/immediately. Previously we had to do hard, manual merges which meant new features got to FI very late (3, 6, 8 months later).
I'm a huge fan of apps released as VM images. I've seen this used extensively in testing and development, but not for production applications. Do you know of other companies who follow the same "our default install is an OVF" strategy?
I first heard the idea from Jeff Atwood in 2006 [1], neat to see the idea taking root with a high-profile product.
It's written using Ruby on Rails and Erlang. My guess is that it's compiled or partially compiled. You can probably hack it and decompile it, but for all that work, you might as well just use an open source alternative.
A lot of reasons, but the largest was that part of the big push for Enterprise was to mimic our github.com environment as much as possible. Every difference between the two is a real cost to support. A different Ruby interpreter definitely falls into the "big difference" category. :)
And on the other side of the coin, why not release it as open source? I would be interested to know if they'd considered that. It works very well for Redhat.
I hope they're going to offer pro rata on seat volumes between multiples of 20. If I have just 25 users it's $10,000 (assuming their pricing widget is completely accurate).
(the point of block pricing is to extract some extra revenue from people in your situation. as a bonus, you get a slight user-license runway so you can add people without paying more if you are in the middle of a license block. also, some companies vastly overestimate their users and will order much more capacity than needed. free money is the best money.)
If two of those devs decided to throw their workstations off the roof once a year, would the $5000 make a difference?
Spending money you don't have to is always a bad idea, so while the unused license space may not make a huge dent on the bottom line, a company that pays attention to those things will likely outperform one that doesn't.
Not 25 devs (although that doesn't necessarily change the salary question) - if you want to go "full GitHub" and use the issue tracker for everything, you want all your staff to have access.
Yeah but you also wound't want to run an equal number of seats to developers either. If you hire a new dev there is a time + $ cost to raising the PO to allow the procurement of a new seat, etc.
Additionally, you usually financially plan for annual spend so you would budget for the total number of seats needed by the end of the financial year.
I would assume that as soon as the trial nears its end, some contact will be made with a sales rep. I can't imagine prices aren't negotiable in cases like these. If they aren't it'd be the first time I've seen it. I've ever paid anything close to listed price on any contracts I've negotiated.
My first thought is who needs "social" features in an enterprise VCS? I love GitHub and think it's biggest benefit is the ability to {easily} fork and watch projects. Does this really translate to the enterprise? I can't imagine a corporation where its a good think to have two groups disagreeing on a direction and causing a fork. Management would have a cow!
The bottom line is what does GitHub Enterprise buy my over something like Redmine or Gitorious? GHE is probably easier to install but I still have to manage my own hardware & drive space. And with the open source alternatives I don't have to worry about licensing and can crack it open to add adapters to other software (#include "standard open source header").
I can think of at least one fairly large development organization that has moved to the github model internally - with pull requests and everything. Their developers love it.
On my team at Forbes we're doing our code reviews via pull requests on Gitorious. The changeset is all there, and you can click a line of code to leave a comment about that line, and there are revisions. It's great.
One thing that I believe this product will have that Gitorious does not (to my knowledge) is the ability to create pull requests from branch to branch. The only way I've found for creating pull requests in Gitorious is to clone the whole repo. Not a huge deal, but it would be easier to just to do branch and merge vs. fork and pull (then branch and merge) for smaller changes.
So on a team I manage, we've used github::fi (github enterprise looks to be the next evolution) for the past year. If you don't have an option to put code out onto github.com, then it's great to essentially have github.com inhouse - minus of course all the public repos.
We find it's the developers go-to place, so using the wiki along with where the source is hosted, is fantastic. As a dev team manager, I love the browsing the codebase via the web browser, reviewing what's going on in the code base instead of pulling down code locally.
From a customer, if you've got the funds, and can't go with github.com hosted, then it's the next best thing. It's been rock solid.
Yea, but my point stands that something like Redmine would fulfill your requirements and be open source. It has a wiki that is tied into the Git repo, and a (better) issue tracking system, and browser access to source, etc.
I guess I'm just missing why an Enterprise would spend $$$ when they can get everything they need without $$$. Then again, I'm not a bean counter and I guess I just don't understand how budgets work. :/
A big part of it, is everyone is familiar with github.com, it's exactly the same experience with github::fi. Just business as usual in-house. For development teams that are open source based, pretty much everyone knows github, so the 'feel at home' factor is there. VS getting yet another tool in the mix that you have to get people upto speed on.
I like Github and use it every day but as a longtime advocate of Fog Creek's software I'm a little sad to see Github continuing to move in on Fogbugz/Kiln territory (not to mention competition from the Australians) with not much response from Fog Creek to compete on the lower end of the market. Github enterprise Pricing/features are about on par with the Fog Creek offering. Git vs. Mercurial but it's still DVCS and though I would consider Fogbugz/Kiln a bit more advanced as far feature implementation all the major types of features are in both products.
What I would REALLY love to see is Fog Creek compete a bit more in Githubs space with their hosted service. I think there is room in the market for a Fogbugz/Kiln lite product and the competition would do everyone, especially the users, a lot of good. I think Joel even wrote an article on pricing and market segmentation [1] unfortunately they may have already figured out the sweet spot with their current price points putting the prices in the range of me being able to get the bank I used to work for to use their product but not the little bootstrapped company where I currently work.
> Fogbugz/Kiln financially scales way better after 40 users.
I don't agree with how you're using the word scales. It actually scales fine, as a percent of their budget per employee. It's flat.
With GitHub Enterprise it's approximately 250 * (n + n % 20) dollars per year. For companies they're targeting, $250/yr is less than a percent of their total budget per employee (including salary, benefits, workspace, etc). If it saves each employee fifteen minutes a week it's worth it.
Disagree. Fogbugz gives a greater and greater savings per employee as your employee count goes up.
Here's a Perl script I wrote to visualize the idea. Feed the output into gnuplot and you'll see what I mean.
use warnings;
use strict;
use 5.010;
use POSIX qw(ceil floor);
# Let's start at 100 employees and walk up by 25.
for(my $count = 100; $count < 1000; $count+=25)
{
# Flat rate for fogbugz/kiln.
my $fb = 15000 / $count;
# ceil(number of users / 20) * blocks of 20-seats to buy.
my $gh = (ceil($count / 20) * 5000) / $count;
say "$count $fb $gh";
}
This asymptotically trends towards about $20/employee for Fogbugz; GitHub hangs around $250 per. At no point in these calculations is GitHub cheaper per than FogBugz.
Now, in the < 100 employee range where the different FogCreek pricings apply, I am not sure who wins, I'd guess it trades off back and forth depending on the # of employees.
edit: awkward formatting. Also, if I've biffed my formulas, let me know and I'll update it!
Nice graph, but why does it need to be so much cheaper per seat as the business gets larger? Many items in the budget don't get much cheaper per seat as the business grows. A company that buys 1000 MacBook Pros doesn't pay half as much per MacBook Pro as a company that buys 10.
I'm a little sad to see Github continuing to move in on Fogbugz/Kiln territory
Competition is healthy for everyone and no company would expect to own an entire vertical (I'm sure Fog Creek doesn't).
In this instance, this is actually a good thing for companies already using Kiln because there are high switching costs and so you wouldn't want to be on a platform that isn't being innovated and developed. A bit of healthy competition will ensure innovation continues and also prices stay competitive.
I agree that competition is healthy and what I'm saying is I'd like to see a volley back from Fog Creek into the lower end of the market that Github seems to control.
GitHub's not sad, and it's good they aren't. If you want to help your customers and your own business, it's best not to be too cozy with potential partners that may wind up being competitors. They've already been through this with LightHouse, and GitHub and their customers are better for it.
I did not want to bring them into the mix and it was the nicest thing I could think to say about them. Bitbucket and SourceTree (acquired) are quite usuable however I find JIRA and Confluence to be really kludgy ugly products but the same could be said for some of the stuff I produce so whatever.
Someone joked that they'd sell a lot more at $4995.
I second that! People, don't under-estimate the issue of signature limits! My old signing limit at one job was $5000, meaning that I needed to get my boss to approve something like this, whereas if it were a dollar cheaper, I could approve it myself.
As I am not "enterprise", these questions are more out of curiosity than anything else:
1. How often do you get updates? One of the things I love about GitHub is the constant stream of new features. Do these make it into github:enterprise fairly soon after?
2. What happens after your "subscription" runs out? That is to say, if I pay for a year, then don't pay next year, do I simply not get any more updates/support? Or is there some kill switch and I lose my content too? I'm sure the answer to this is similar to all enterprise products, but again, I've never experienced anything in the enterprise.
Can't answer the second question, but we haven't gotten very frequent updates. I'm hoping that will change with the transition to Enterprise, but GitHub:FI lagged behind "public" GitHub pretty badly.
(to question 1...) It's worth considering that if you're an enterprise then you* might not actually want a constant stream of new releases to deal with.
Where you = the CTO/CIO/Security/VP Operations, and the purchase decision maker. Many enterprises are (still) anally retentive about acceptance testing any new version from a vendor.
You = the engineer definitely do, but sadly in the enterprise world the engineer isn't the customer.
Oh, and don't shoot the messenger. I'm not saying I agree with that status quo, simply that if GitHub aspires to make a decent revenue stream from the Enterprise then they'll have to work to those kinds of dynamics.
1. Very frequently. The reason this launch took so long was in large part due to reconfiguring how we merge the differences between .com and the installable (FI/Enterprise). Previously, it was painful and slow and lagged embarrassingly behind. But now it should be no more than a week or a month at most behind .com so long as you upgrade your instance.
2. The instance will lock you out (no web interface, cannot push to repos) but you own all your data so you will never lose your content.
The OVF will be updated infrequently — there is a software package you upload in a management interface that installs the new software and configures your instance with the updates. It's pretty seamless — download a file, upload it, wait a few minutes for install and you've got an updated version of GitHub Enterprise.
This sounds like a support nightmare. I hope GitHub has learned from the mistakes that SourceForge ran into when they tried packaging their product for the enterprise.
I like that it is distributed as an OVF, but is there any thought to doing an AMI as well? I know it isn't meant for public use, but in my case I don't want it in the internal datacenter, nor is it easy to bridge subnets in remote offices. An AMI for EC2 deployment behind a VPN would be really nice.
> The VM Import process currently supports VMware ESX VMDK images, Citrix Xen VHD images and Microsoft Hyper-V VHD images for Microsoft Windows Server 2003 (R2) and 2008 (R1 & R2).
We've been using a demo of this at my day job for a few weeks now. It's been pretty awesome, we use an internal IRC server (which could never talk to the outside world) and using the hooks it provides is super useful.
We also have a complex code pushing system, and integrating with github enterprise will be a bit easier than raw git.
I wonder if this pricing includes things like read-only users (analysts, QA staff, etc.) and deployment activities in the user count. It would suck to have to pay for a license to deploy from GHE using Capistrano. :/
At least for FI, all users count towards your user cap. I've asked about this before because it really sucks. For 100 projects we might have 200+ users that don't really need access, but could use it. Since the prices don't get better at the higher levels, it creates and incentive to limit access which reduces the usability of GH in the first place.
What we're not really talking about is how good github is as a product. As far as I'm concerned, it's a 10x improvement over other ticketing and SCM systems.
I don't think they're charging enough. Congrats guys!
This news comes just hours after I finished installing Gitorious on my company's own server. I'm glad I went through that trouble because $5k is crazy for a startup to pay for a self-hosted git web interface.
Heck, I'll install your own Gitorious on Rackspace Cloud Server for $99 for anyone who requests. Host your own code.
I love GitHub and all, but the whole Enterprise label is kind of a joke. You slap "Enterprise" on a service, make a few nominal features available to the people who buy into the ploy and then charge them out the nose for it.
It's a product distribution strategy that fills a need in the enterprise marketplace. I wouldn't marginalize OVF as a "nominal feature" or the value of offering a secure, localized version for clients.
104 comments
[ 5.8 ms ] story [ 170 ms ] threadHow does this fare against other enterprise hosted scm/version control products?
Obviously, the feature set is pretty different, but I think it still falls into the Enterprise SCM category.
So summed up: 10 Users: $3600 20 Users: $4400
So, they are definitely cheaper, but I'd say that $5000 for 20 users is a competitive price for such a huge infrastructure.
They also have a free plan for up to 5 developers.
http://www.atlassian.com/software/starter/overview
So if your team is 10 users or less, you get all of Atlassian's products for $100.
The equivalent for Code review in Github is the fork/pull request/compare mechanic, which can be used in between repositories as well.
Ticket management: Github Tickets. It also has basic support for Milestone planning etc.
It's a subtle but not insignificant difference and depending on your needs, either one could be a good fit.
It sounds good, though I guess my fear would be that git's mindshare in the kind of locked-down IT environments this is targetted at is still fairly low. Clearcase still rules in that world, and a SCM system is among the least flexible infrastructure items.
Edit: We first launched the precursor to GitHub Enterprise, GitHub Firewall Install, over two years ago.
Same pricing, but better branding. I wonder what else has changed?
- Enterprise is delivered in an OVF, which means it's a fully contained VM. This simplifies deployments astronomically from the previous FI architecture.
- We've spent a lot of time on the runtime and packaging of Enterprise in relation to how it runs the code. It's now much faster.
- We've changed how we merge the two codebases (.com and FI/Enterprise). Effectively, they are the same now. This means new features that come to .com will come to Enterprise quickly/immediately. Previously we had to do hard, manual merges which meant new features got to FI very late (3, 6, 8 months later).
GitHub Enterprise is the latest release of our on-premise product with a re-engineered back end and our new customer dashboard.
I first heard the idea from Jeff Atwood in 2006 [1], neat to see the idea taking root with a high-profile product.
[1] http://www.codinghorror.com/blog/2006/01/our-virtual-machine...
(Previous versions were a tarball of PHP code and a lot of brittle install scripts.)
https://github.com/blog/978-introducing-github-enterprise#co...
(the point of block pricing is to extract some extra revenue from people in your situation. as a bonus, you get a slight user-license runway so you can add people without paying more if you are in the middle of a license block. also, some companies vastly overestimate their users and will order much more capacity than needed. free money is the best money.)
Spending money you don't have to is always a bad idea, so while the unused license space may not make a huge dent on the bottom line, a company that pays attention to those things will likely outperform one that doesn't.
Additionally, you usually financially plan for annual spend so you would budget for the total number of seats needed by the end of the financial year.
The bottom line is what does GitHub Enterprise buy my over something like Redmine or Gitorious? GHE is probably easier to install but I still have to manage my own hardware & drive space. And with the open source alternatives I don't have to worry about licensing and can crack it open to add adapters to other software (#include "standard open source header").
One thing that I believe this product will have that Gitorious does not (to my knowledge) is the ability to create pull requests from branch to branch. The only way I've found for creating pull requests in Gitorious is to clone the whole repo. Not a huge deal, but it would be easier to just to do branch and merge vs. fork and pull (then branch and merge) for smaller changes.
We find it's the developers go-to place, so using the wiki along with where the source is hosted, is fantastic. As a dev team manager, I love the browsing the codebase via the web browser, reviewing what's going on in the code base instead of pulling down code locally.
From a customer, if you've got the funds, and can't go with github.com hosted, then it's the next best thing. It's been rock solid.
I guess I'm just missing why an Enterprise would spend $$$ when they can get everything they need without $$$. Then again, I'm not a bean counter and I guess I just don't understand how budgets work. :/
http://www.fogcreek.com/kiln/for-your-server.html
What I would REALLY love to see is Fog Creek compete a bit more in Githubs space with their hosted service. I think there is room in the market for a Fogbugz/Kiln lite product and the competition would do everyone, especially the users, a lot of good. I think Joel even wrote an article on pricing and market segmentation [1] unfortunately they may have already figured out the sweet spot with their current price points putting the prices in the range of me being able to get the bank I used to work for to use their product but not the little bootstrapped company where I currently work.
[1] http://www.joelonsoftware.com/articles/CamelsandRubberDuckie...
E.g., if you have a 200-user company, that's still a flat rate of 15K initial & 5K/year for Fog Creek's stuff (plus maintenance).
But for github, that's 50K/year.
Github is a high-quality product, no question about it. But the price is steep compared to Kiln/Fogbugz, IMO.
I don't agree with how you're using the word scales. It actually scales fine, as a percent of their budget per employee. It's flat.
With GitHub Enterprise it's approximately 250 * (n + n % 20) dollars per year. For companies they're targeting, $250/yr is less than a percent of their total budget per employee (including salary, benefits, workspace, etc). If it saves each employee fifteen minutes a week it's worth it.
Here's a Perl script I wrote to visualize the idea. Feed the output into gnuplot and you'll see what I mean.
This asymptotically trends towards about $20/employee for Fogbugz; GitHub hangs around $250 per. At no point in these calculations is GitHub cheaper per than FogBugz.Now, in the < 100 employee range where the different FogCreek pricings apply, I am not sure who wins, I'd guess it trades off back and forth depending on the # of employees.
edit: awkward formatting. Also, if I've biffed my formulas, let me know and I'll update it!
edit2: forgot to comparatively do analysis
Competition is healthy for everyone and no company would expect to own an entire vertical (I'm sure Fog Creek doesn't).
In this instance, this is actually a good thing for companies already using Kiln because there are high switching costs and so you wouldn't want to be on a platform that isn't being innovated and developed. A bit of healthy competition will ensure innovation continues and also prices stay competitive.
WTF?
I second that! People, don't under-estimate the issue of signature limits! My old signing limit at one job was $5000, meaning that I needed to get my boss to approve something like this, whereas if it were a dollar cheaper, I could approve it myself.
So it's no joke.
1. How often do you get updates? One of the things I love about GitHub is the constant stream of new features. Do these make it into github:enterprise fairly soon after?
2. What happens after your "subscription" runs out? That is to say, if I pay for a year, then don't pay next year, do I simply not get any more updates/support? Or is there some kill switch and I lose my content too? I'm sure the answer to this is similar to all enterprise products, but again, I've never experienced anything in the enterprise.
Where you = the CTO/CIO/Security/VP Operations, and the purchase decision maker. Many enterprises are (still) anally retentive about acceptance testing any new version from a vendor.
You = the engineer definitely do, but sadly in the enterprise world the engineer isn't the customer.
Oh, and don't shoot the messenger. I'm not saying I agree with that status quo, simply that if GitHub aspires to make a decent revenue stream from the Enterprise then they'll have to work to those kinds of dynamics.
2. The instance will lock you out (no web interface, cannot push to repos) but you own all your data so you will never lose your content.
Does that mean one can still clone repos?
> The VM Import process currently supports VMware ESX VMDK images, Citrix Xen VHD images and Microsoft Hyper-V VHD images for Microsoft Windows Server 2003 (R2) and 2008 (R1 & R2).
Fortunately, the format if question is an open specification[1], so you can use a[2] number[3] of[4] tools[5] to convert the OVF to an interim format.
That is, obviously, a pretty ugly workaround.
[1] http://en.wikipedia.org/wiki/Open_Virtualization_Format
[2] http://www.vmware.com/support/developer/ovf/
[3] http://www.citrix.com/english/ss/downloads/details.asp?downl...
[4] http://www.virtualbox.org/manual/ch01.html#ovf
[5] http://www.microsoft.com/en-us/server-cloud/system-center/vi...
We also have a complex code pushing system, and integrating with github enterprise will be a bit easier than raw git.
I don't think they're charging enough. Congrats guys!
Heck, I'll install your own Gitorious on Rackspace Cloud Server for $99 for anyone who requests. Host your own code.