GitHub

Open Source or not?

Slashdot has an interesting discussion on whether or not a small start-up company has to Open Source their code or not. From one of the comments I followed a link to an excellent blog post by Tom Preston-Werner, one of the co-founders of GitHub.

Lastly, it’s the right thing to do. It’s almost impossible to do anything these days without directly or indirectly executing huge amounts of open source code. If you use the internet, you’re using open source. That code represents millions of man-hours of time that has been spent and then given away so that everyone may benefit. We all enjoy the benefits of open source software, and I believe we are all morally obligated to give back to that community. If software is an ocean, then open source is the rising tide that raises all ships.

In a nutshell he basically says that you should Open Source everything, except things that are at the core of your business value. His arguments are insightful and I suggest you read the whole thing.

Interestingly, this reminds me of a few discussions I had on outsourcing. And I was saying is that a company should outsource as much as possible, except for things which are at their core business value. As in, IT company should outsource accounting and legal, not IT, while accounting companies should outsource IT and legal, not accounting. And so forth.

That leads me to think that Open Source community is a huge outsourcing resource. Something that I’ve known for a long time, but now arrived to through a totally different route.

GitHub Enterprise announced

GitHub – the place to host and manage your source code – announced the release of GitHub Enterprise. GitHub Enterprise is a self-hosted version of GitHub. What I find the most interesting is the pricing.

GitHub Enterprise is priced at $5,000 per 20 users, per year. It comes with everything you need in one tidy package: code browsing, code review, issue tracking, wikis. No extra software to buy, no extra software to install, no extra software to manage.

The target is not on the disk space (understandable, with your own severs) or private repositories, but on the number of developers. $5,000 per 20 developers per year is $250 per developer per year, or about $20 per developer per month. That’s not too much, especially when compared with the salaries paid to the same developers each month. A fraction of the salary.

So, not only GitHub Enterprise is an excellent option for those companies that cannot use third-party hosting for source code, but it is also a Christmas present for those companies that work on a lot of projects. With private repositories, the price of a regular GitHub organizational subscription can go up pretty fast. With GitHub Enterprise you’d be able to have everything in-house for a tiny fee, compared.

It’ll be interesting to see how well this business will go for GitHub. It sounds viable to me. Convenient and not too expensive. With easy OVF-based installation, that would work on many virtual machines (VMware, VirtualBox, etc), with additional features for enterprise integration (LDAP!), I don’t see why not.

Pagoda Box – scalable platform for your PHP application

I got my hands on a private beta of Pagoda Box. It is a platform that you can deploy your PHP applications to. I gave it a brief look around and I have to say it’s pretty sweet.

Right after you register and get access to your dashboard, you can add applications. Applications are cloned from GitHub repositories. Both public and private repositories are supported. Once you add an application, you can access it at http://your-app-name.pagodabox.com. If you’d rather have your own domain – you can assign it to your application from the dashboard and all that will remain to be done is adding an A-record in your DNS zone. Super easy!

There is more to it, even at this beta stage. Pagoda Box supports a number of PHP frameworks, including all major ones – CakePHP, CodeIgniter, Lithium, Symfony, Zend, and more. You can also optionally have a MySQL database for your application. They even help you out with outgoing email.

On top of that, you have control as to how many instances of the application you want (the more you have, the more requests you can serve at the same time, and the more you’ll have to pay). There are statistics of your application performance, requests, and a few other parameters (I’m sure those will grow together with the project).

I’ll admit, I am too used to hosting my projects on my own servers to take immediate advantage of Pagoda Box. But I am now seriously considering which projects I can move out of my server and into this platform. It just makes things so much easier. Deploying and re-deploying works wonders for any GitHub commit of your project. Initial resources that one usually needs to try an idea out are free of charge. If the idea picks up, the prices are more than reasonable (and comparable to other hosting solutions).

Out of those things that I consider necessary, I haven’t see any mentioning of files (uploaded via application, for example), support for build systems (such as Phing), and some sort of common library of frequently used code (PEAR modules, for example). But I’m sure that either I simply didn’t look for these hard enough, or they will be added in the future.

If you are a PHP developer or involved with PHP source on GitHub in any other way, I suggest you try it out. You can request a private beta invite directly from Pagoda Box website. Or, if you prefer, I can send you one (I have about 10 of them left for now). Also watch the demonstration screencasts, and read through other platform features.

Branches graph at GitHub

One of my favorite features of GitHub (and, probably, pretty much any other git client) is the graphical representation of branches. It usually gives a crystal clear picture of how the source tree came about to be. But I think today I actually managed to confuse the heck out of it. Have a look at the screenshot below.

A couple of commits ago it was a master branch (black) and a stable branch (magenta). Then I (if I remember correctly) created a test branch from the latest stable, pushed it, switched to stable branch, reverted one commit, and pushed it as well, then added a couple of commits to master and merged it into test. Pushed and got the thing above. Weird looking source tree mutant.

Anyway, I’m sure it will sort itself out some time later.

P.S.: Indeed, as expected, after just a few more merges, commits, and pushes the tree sorted itself out. Lovely GitHub, very lovely!