Introducing GitHub Enterprise(github.com)
github.com
Introducing GitHub Enterprise
https://github.com/blog/978-introducing-github-enterprise
104 comments
Also $4995 (or even $4990) is better than $4999 as several large companies audit purchases that are very near the limit.
Agree it's no joke. I thought everyone already knew this. Certainly whoever is in charge of sales should.
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.
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.
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.
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.
> 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?
Does that mean one can still clone repos?
How are the updates delivered? New OVF?
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.
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.
http://news.ycombinator.com/item?id=3183497 says they merged FI/Enterprise, & .com so Enterprise shouldn't lag behind.
(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.
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.
I love felixge's comment on a bug he found with the price estimator:
https://github.com/blog/978-introducing-github-enterprise#co...
https://github.com/blog/978-introducing-github-enterprise#co...
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.
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...
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...
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.
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.
Fogbugz/Kiln financially scales way better after 40 users.
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.
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.
> 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.
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.
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
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";
}
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
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.
Well, if you want to not be fiscally efficient...
[deleted]
"the Australians"? Who calls Atlassian that unless they work for FogCreek?
WTF?
WTF?
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.
At the company I am at we use Gitorious, the initial setup took some time, but after that it has been smooth running.
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.
For those concerned about the total costs: Don't worry. Looks like there's a bit of a discount at the higher levels. http://i.imgur.com/8A9Dx.png
How do they ensure that their code is not stolen? Any insights on that?
Firewall Install used JRuby to precompile our models and controllers; GitHub Enterprise uses code obfuscation with MRI.
Why didn't you choose to go the JRuby route again?
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. :)
Curious then.. Do you run the obfuscator in production as well?
Nope, just in Enterprise.
How do you do the code obfuscation? rubyencoder or something homegrown?
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.
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.
What makes github great is the execution and the community, I think any decent team could clone Github as it's now given enough time.
They obfuscate with JRuby. Mingle, also a ruby based tool, does this too.
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!
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.
Heck, I'll install your own Gitorious on Rackspace Cloud Server for $99 for anyone who requests. Host your own code.
This isn't for startups. It's for companies that want to use GitHub but can't, because people are afraid of letting the code outside their walls.
Or they are legally required to by their clients and or government regulation.
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).
Enterprise pricing. Learn it, live it, love it.
(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.)
(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 you have 25 devs, you're going to spend a minimum of 1.5/2 millions a years on salaries. Does a $5,000 difference really matters at that point ?
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.
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.
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.
Interesting to see they are forwarding links from the Firewall Install page (fi.github.com) to this.
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?
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?
Notably:
- 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).
- 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.
[1] http://www.codinghorror.com/blog/2006/01/our-virtual-machine...
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...
Squiz switched to distributing a free VM for the trial and production versions of their CMS: http://squiz.com.au/products/squiz-cms
(Previous versions were a tarball of PHP code and a lot of brittle install scripts.)
(Previous versions were a tarball of PHP code and a lot of brittle install scripts.)
OpenVPN Technologies distributes a virtual appliance for their Access Server product, in addition to packages for the various distros.
Thanks for jumping in! Are there screenshots of this customer dashboard available anywhere?
GitHub Enterprise is the latest release of our on-premise product with a re-engineered back end and our new customer dashboard.
GitHub Enterprise is the latest release of our on-premise product with a re-engineered back end and our new customer dashboard.
The OVF format is a large change.
>> "GitHub Enterprise is priced at $5,000 per 20 users"
How does this fare against other enterprise hosted scm/version control products?
How does this fare against other enterprise hosted scm/version control products?
$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.
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.
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
Preforce is a steal compared to Clearcase (https://www-112.ibm.com/software/howtobuy/buyingtools/paexpr...) which is from 2500 to 5000 a user.
Not exactly analogous, but FishEye from Atlassian is less money/user and LOTS less money for teams less than 10.
http://www.atlassian.com/software/fisheye/pricing
Obviously, the feature set is pretty different, but I think it still falls into the Enterprise SCM category.
Obviously, the feature set is pretty different, but I think it still falls into the Enterprise SCM category.
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.
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.
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:
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.
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.
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.
They also have a free plan for up to 5 developers.
Is Bitbucket something I can install on my own hardware behind my corporate firewall?
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.
It's a subtle but not insignificant difference and depending on your needs, either one could be a good fit.
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 wrote that this is _roughly_ the same feature set.
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.
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.
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.
[deleted]
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.
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.
If you're OK with an externally hosted Github, why can't you use Github itself?
Exactly. And it is WAY cheaper. $100/month gets you more users and one less thing you have to worry about backing up and keeping up and running.
Amazon has tools for importing other virtual machine formats into EC2 -- http://aws.amazon.com/ec2/vmimport/
... none of which are the format in question.
> 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).
> 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).
You are correct.
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...
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...
I guess you can use the VMWare one to get it to an AMI importable format.
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").
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").
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.
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.
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.
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.
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. :/
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.
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.
We also have a complex code pushing system, and integrating with github enterprise will be a bit easier than raw git.
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.
GitHub has been selling "Firewall Install" for a couple years. Any mistakes they've learned from were on their own.
I wonder if it has anything to do with release of http://gitlabhq.com
Considering GitHub:FI has been around for a really long time, no.
Nope.
Interesting. $20/month/user seems pretty damn cheap.
And that includes support.
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.
Actually, having an internal server host your intellectual property is a big deal in the enterprise.
Agreed, it's strange how people continue to support that kind of marketing.
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.