David Moreno blog

Is GitHub really necessary for your startup engineering team?

Sun 11 Mar 2012 11:52:52 PM UTC

For the last few months, I’ve been ranting a little too much with our engineering team about GitHub. These rantings, of course, didn’t come out of the blue. I haven’t been too satisfied with GitHub’s reliability lately since we use it for our daily development and constant deployment on our different staging environments and our own operation has been affected by their recent multiple technical difficulties. This has led me to analyze whether we really need them, why we started paying for their service in the first place and if it’s really necessary for our product development in the first place.

Being an startup that originated its main product on Ruby and Ruby on Rails, some of our initial engineers were more oriented towards Ruby and open source technologies. We started using GitHub because it was the natural and de facto choice. Creation of repositories and private contributors was easy and would put you up to speed with collaboration. As we grew in developers count, our repositories did too as well as different projects. We even brought a system administrator in place. Do we still need GitHub right now? I won’t be dropping Git as our main version control system, but what has GitHub provided my company and project in exchange for the $200 we are paying them every month? Is it only hype for a company to use it for their internal repositories? Or is it hype to use them for their open repositories?

The lack of site reliability on their side is what has led me thinking about whether we should still use them. What really concerns me is that they seem to have operational issues on a daily basis, they’re constantly announcing new hires, new pub meetings and new Octocat designs, and little effort has been shown about the technical operations. It sometimes amazes me how people is so much in love with GitHub to the point where I even find “liked” articles on their feed on Google Reader whenever they announce downtimes and br0kenage (now +1’s). It’s like people enjoy what’s wrong.

Are we using their issues functionality? The nice thread comments per commit, per line? Are we using pull requests? Are we using any of their actual offering compared to what a native Git server setup offers? No. The only thing is just pretty much the collaboration management, and even then, the “Groups” feature per organization is still lacking. The only main feature we use is the web browsing for the repos, which we can do with open source tools anyway. At the end, there’s other great GUIs for Git we also use on a daily basis, such as GitX or Tower (and for now, yes, GitHub’s GUI client).

The issue they were attacked with last week makes me wonder whether they are the right organization to give us version control system services or we’re just using them because we haven’t know any better or even looked at our own resources (people and machines). Someone got commit access to an open source repository. What if it would have been a malicious user getting access to private repositories where passwords and other sensitive are stored? How serious is this company? $200 is not much for a startup to spend on a neat service, but when that provider seems to be more concerned about stickers or beer than fixing their tech operations from the inside out is when it gets worrying. I like to see how other similar services we’re using compare to GitHub, how stable they feel and how notorious that reliability is shown. For example, New Relic which we also use, seems rock solid and they don’t show issues at all. What’s the difference here anyway?

Site reliability is tricky anyway: when it’s faulty, it shows and screams because it affects business operations and reaches the entire company; when it’s working perfectly, the way it should, you can barely realize people are doing an stupendous job. GitHub, however, doesn’t seem to have this clear.

comments powered by Disqus
<- earlier post older post ->