For the unenlightened, Git is a distributed version control system that’s recently taken the software development world by storm. It’s what we use to manage all of our source code at 37signals. GitHub is an online service providing Git repository hosting and collaboration tools (we featured them recently on the Product Blog).
Rails, Capistrano, and Prototype are already hosted on Github, and we’re going to be releasing some of our internal libraries and plugins there as well. Feel free to follow, fork, clone, and contribute!
Benjamin
on 21 Aug 08And thanks to Signal vs. Noise being abbreviated ‘svn’, Google will be sending you lots of traffic from those wishing to convert to git from (the other) svn…such as myself.
DanGTD
on 21 Aug 08This is great.
I heard when they developed GitHub, they took a lot of inspiration from Getting Real book.
Paul Campbell
on 21 Aug 08That’s awesome news! Can’t wait to have a play with some 37signals developed stuff.
MikeInAZ
on 21 Aug 08Github just makes it so damn easy to share your code.
I wubs me some github.
Robby Russell
on 21 Aug 08Glad to see that more people are adopting Git. I have a few blog posts on using git.
If you’re stuck with subversion for now, you can still reap (most) of the benefits of git with git-svn.
Here is one of those blog posts… git-svn is a gateway drug
Bogdan Gaza
on 21 Aug 08You said a few month back that you`ll release some internal libraries. Are you going to do that in the near future or we`ll have to wait more ?
Chris Wanstrath
on 21 Aug 08Welcome to the club!
If any SVN readers are curious about switching, we’ve got a wealth of helpful information in the GitHub Guides. Videos, tutorials, FAQs, the works.
Ben Atkin
on 21 Aug 0837Signals:
Do you use GitHub for any of your proprietary code? I know GitHub has support for private repositories. Would you trust GitHub enough to let them store your code?
I think it makes sense for a lot of companies, including the one I work for. It would be nice to be able to point to a prestigious company like 37 signals trusting an outside company to manage their repository.
Kevin
on 21 Aug 0837s: Do you guys host the source of your internal apps (Basecamp, Highrise, etc) on GitHub, or are you paranoid like us and pass on GitHub’s awesomeness in exchange for a little extra protection of your IP?
Zack
on 22 Aug 08Posting any patches to the ical libs you are using (ref: from long ago svn post) to fuel the backpack calendar would be greatly appreciated!
JH
on 22 Aug 08We host all the source code for our applications internally for obvious security reasons. That’s not to say Github’s private repository hosting isn’t a good option, especially if you want a hassle-free setup. It’s just not for us.
Jesus A. Domingo
on 22 Aug 08Hi guys, this is irrelevant to this entry but I just couldn’t figure out how to get to you. Do you have a publicly available email address that we can send questions to? I couldn’t find any “Contact Us” on any of your sites.
My question is when you guys were just starting up, how did you get your traffic moving? We’re hoping you could post about this, keeping in mind those who don’t have funding for PR and marketing.
Roger
on 22 Aug 08Does it mean that you do not trust Github to be able to secure your data?
Paul Campbell
on 22 Aug 08Roger,
At a recent Contrast (http://www.contrast.ie) strategy weekend, we had a long, heated debate about the level of trust required using services like GitHub.
The most interesting question for me was: No matter how tight your own personal principles are, would you be able to stop yourself from looking at the sourcecode to Basecamp, Backpack, Campfire?
We personally trust Chris, PJ and Tom with all our source code ( we use Github for http://getexceptional.com ) ... but if it was you, would you be able to resist a quick peep?
Thankfully, the question remains broadly academic, but that’s the nature of these kinds of privacy concerns for any software as a service.
JH
on 22 Aug 08It’s not that we don’t trust the security of Github. Many of us use it for our own private projects. We just prefer to host the source code for our applications ourselves.
I think the private hosting option is especially great if you don’t have (or want to procure) the resources to set up your own hosting infrastructure. If I were doing client work, I’d likely choose that option over configuring repositories, permissions, and a web client for collaborators.
GeeIWonder
on 22 Aug 08We just prefer to host [anything] ourselves.
I think this is a perfectly reasonable statement and decision. But don’t be surprised when people jump all over you for this.
The most interesting question for me was: No matter how tight your own personal principles are, would you be able to stop yourself from looking at the sourcecode to Basecamp, Backpack, Campfire?
If the whole thing is encrypted and you remove super-user access to individual account pages, this goes away.
Emil
on 22 Aug 08It’s interesting that 37s can’t use Github because “obvious security reasons” when they tell you to trust them with all your company data (all intranet data via Backpack, all client/own project data via Basecamp, your network of ppl via Highrise and your communication through Campfire.
I love webapps but the data security is a problem.
PJ Hyett
on 23 Aug 08Frankly, I’m surprised that 37signals thinks there are “obvious” security reasons when they’re also in the business of storing sensitive company information.
We take security very seriously at Github.
Anonymous Coward
on 23 Aug 08Oh oh…
Anonymous Coward
on 23 Aug 0837s, and most companies, have to treat their lifeblood – their source code – with extra caution. That’s understandable and simply good business. It’s not commentary on Github, it’s just an extra level of protection to maintain the core of their business.
will
on 23 Aug 08nice post
Bedzilla
on 23 Aug 08As with many posts it applies to some companies more than other, some statements are taken as generalisations and get most reaction from readers. Same applies here.
MI
on 24 Aug 08PJ, Jeff didn’t intend to disparage GitHub in any way. There are implications involved with hosting our repository outside of 37signals that go beyond simple data security. An example that leaps to mind is dependence on that outside repository being available whenever we want to deploy our applications. GitHub is a fantastic service, and by and large it’s very stable, but that’s a possible external failure point that we don’t want to introduce into our infrastructure.
Berserk
on 25 Aug 08@MI: An example that leaps to mind is dependence on that outside repository being available whenever we want to deploy our applications.
Kind of like having all your project documents handy whenever someone wants to do something in a project?
What I mean is that this exact problem is the one you combat yourselves, and it is interesting to see your take on it when the roles are reversed. (I agree though, outsourcing your source code takes a big leap of faith.)
Chris
on 25 Aug 08Let’s see: 37signals also hosts the respositories, right?. Presumably on one of their servers. So ideally they entrust their source code to the same security measures to which we trust the data entered into 37s application (except for files, but Amazon S3 security has to my knowledge never been questioned). I don’t know the next thing about Git Hub and its security (probably great, as well) , but I think 37signals using their own and hence our storage facilities isn’t bad news, because it creates internal motivation to keep security tight.
Am I jumping to conclusions?
Anonymous Coward
on 25 Aug 08Kind of like having all your project documents handy whenever someone wants to do something in a project?
No, that isn’t even close to the same thing. Your entire business isn’t “dependent” on that document like an application is dependent on source code (plus, when you upload a document to Basecamp(or a similar product someone has a copy of that document locally).
37signals can’t deploy a bug fix if their code is hosted remotely and that source code storage service isn’t working. That means they are entirely 100% dependent on a third party service for something that is 100% absolutely core to their business.
You, on the other hand, can still call a client and discuss a document or do something else on the project if you can’t get access to a specific file for a short period of time. But not being able to deploy an app would be paralyzing.
This discussion is closed.