The GitHub guys are just iterating and growing so fast. I'd hate to be SourceForge right about now (it seems to have caused the SF.net folks to wake up, though, as they've begun to improve at a very rapid clip).
I ordinarily recommend folks not go the installable application route (even though our business is all installable based) if they can avoid it, but I think it definitely makes sense for GitHub. It's an area where the prices are very high, and the products are generally pretty bad.
SF woke up a bit around the time Google Code project hosting was released. But with GitHub and BitBucket kicking things up a notch, it's definitely a bad time to be SF. And despite all their changes, it still feels like a pain to use SF.net.
I don't understand why you need obfuscation for this. With customers of this size, you can have them sign a contract that protects your IP. Price in what you think is the risk, and insist on a contract.
So roughly how much would this cost for a small team, say <10? I'm assuming far too much for me, since it's not visible anywhere, but I'm still curious :)
I'm not from Github, but the blog post says "Please keep in mind that FI is priced competitively with other internal code management solutions and is well over the cost of our most-expensive hosted plan." Their most expensive hosted plan is the Giga at $200/month.
How much are you willing to pay? :) Seriously, though, it's probably priced beyond what most small teams could afford, but it's on a per-company basis which is why we're not posting prices.
GitHub:FI was really built with large customers in mind, places with tens to hundreds of developers bridled with restrictions that prevent them from hosting their code on GitHub.com.
There's no reason smaller companies can't use it, but for the time being we want to dedicate more attention and support to fewer well-paying customers.
We may offer a pricing model in the future that's more affordable for smaller teams, but I can't state emphatically enough that if your team doesn't have the type of restrictions mentioned earlier, you should absolutely be using GitHub.com.
I mentioned this in another comment, but I just wanted to note that even as a very small company, we tend to avoid solutions that won't readily integrate with our existing LDAP users and group-based access control, backup system, single-sign-on, etc.
Not using web services has less to do with being bridled corporate restrictions and more to do with preferring to use our nice, fully automated infrastructure. Hosting another small java servlet isn't going to make us break a sweat -- it'll be less work than trying to maintain user accounts and access controls across another web service.
For this reason, we solely use products that drop right into our standing infrastructure. I don't think we're too unusual in this, although we may be amongst the HN sample set.
For companies where the code is the primary product they sell, hosting it on a remote server seems like a hard thing to ask for from upper managment no matter how secure it is. I can see the case for a lot of small software companies that really would want to use github, but someone on the team refuses to let the code be placed outside their network.
Awesome job, PJ and team. I first heard about this at Startup Riot 2009 when Chris came to speak.
Although, my initial concern is how this is being spun to customers in terms of customization. One of my design clients is a SaaS vendor that had a large potential customer request an on-site deployment of their big product. Along with packaging up their software for a remote deployment, the customer was asking for all kinds of modifications to match up with their very particular needs. This was sort of spreading them thin on what they could work on for the customer and for the core product. So, my question is are you going to provide customization options for purchasers, or is the product just a rebuilt copy of whatever state the GitHub code is at? I'm a fan of what you guys have built, so I'd hate to see it suffer.
I think one of the most exciting points here is that they were able to get one of the most popular Rails applications running on JRuby without too much apparent hassle. Hopefully we'll hear a bit more from them about this process and how it went, but this is an exciting announcement for the Ruby community!
Does it do custom branding? I might've missed this, but I don't think the video mentioned it. Gitorious does that rather nicely (see http://qt.gitorious.org/), but your repositories will still be hosted somewhere else.
We're not an IBM, but tend to avoid solutions that won't readily integrate with our existing LDAP users and group-based access control, backup system, etc.
This is one of the main reasons that I'm not using Git at work, there hasn't been a super solid way to get the Github functionality on an internal network where it's 100% secure. This is a REALLY smart move for the guys at Github.
agreed. I don't feel comfortable uploading all my code to a third party, which in this case is even located in a different country I'm not familiar with the legislation details.
I'm using gitosis and redmine internally now, but this one is really interesting
Not to be pedantic, but there's no way that you're going to make anything 100% secure, even if you host it internally. I do agree with your point though and can understand some companies wanting to keep all of their code in-house though.
I've been happily using Gitosis for quite a while now. It's like Github without the web interface (so it manages central repositories and user authentication).
I recall it took a bit of finagling to set it up, but I haven't had a single issue with it since. It's also cool that the configuration files are stored in a Git repository (once you try it, it will be clear how that works).
In the demo
- They show a license agreement, but I don't seem to see it online to view and review.
- X86 only?
- Hopefully the password scott put in isn't the one he uses everywhere :)
I ordinarily recommend folks not go the installable application route (even though our business is all installable based) if they can avoid it, but I think it definitely makes sense for GitHub. It's an area where the prices are very high, and the products are generally pretty bad.