Source code hosting sets pricing all wrong

Where's the love?

The way GitHub structured their pricing plan looks like a way to punish long-term customers.

They don't charge based on how much value they are providing: they just charge based on how much you must be willing to pay after your data starts gathering there. And they are not alone -- most other do the same wrong customer segmentation tricks.

Many small projects

It's good form to have separate repositories for separate projects, so with each new project hosted on GitHub you would create a new private repository.

Well -- pretty soon you will run out of private repositories so you'll need to upgrade to a new plan.

If you look at their pricing plans they are for 5, 10 and 20 private repositories, and then you get into the over $100/month business plans.

Am I silver business or micro ?

If I look at my own server, I have 34 mercurial repositories dating 2 years back alone. Of course, some are big, some are small, some represent my own ideas while other are repositories for client projects.

But do you know how many am I actually using nowadays? The answer is 4.

So according to this I would need to be on a silver business plan with $100/month. But what is the value they are providing? It's the equivalent of $7/month of the micro plan, plus the value of having your old projects archived and available. Now, I wouldn't say the value of archiving old projects is $93/month.

Metered please

My solution is metered code hosting.

Amazon's EC2 might have spoiled me but I like to know that I'm paying for what I am actually using.

So, how do I see a sane pricing plan ? Well, there are 3 axes to look at: it's the disk I'm using, the bandwidth I'm using and then the actual hosting extras I'm accessing like online source code visualizer, wiki, merge tool, code review or whatever. If you think about it, the "extras" I am talking about might be seen like the CPU-time of running their software.

Now, all the trick is setting a right storage/bandwidth/CPU price.

Storage can't be more than 130% of the S3 price, meaning about 20 cents/GB ($0.20)

Bandwidth can't be more than 130% of the EC2 data transfer, meaning again about 20 cents/GB ($0.20)

Setting a price on the CPU time is interesting as this basically tells you how they value their product. It's impossible to guess but they would have to set the number pretty high to make normal usage exceed their current pricing plan.

... or the simpler change

The other notion they could introduce is that of active repository.

If I am pushing changesets to a repository, editing the wiki it's pretty safe to say I should pay for that repository.

But if I haven't touched the repository in any way for the whole month it would sure be nice to charge me only for the storage (or nothing at all if we see storage as "unlimited").

Compiling is such a chore

I'm using Hudson as my build server and I would love to patch some things about it, especially the JUnit reports and charts.

Well, one of the reasons I dislike getting to this small change is that I would first:

• need to checkout Hudson,
  
• then figure out how to build it,
  
• then do the patch,
  
• then compile it and finally
  
• start using the changed Hudson.

Thus, there are quite a few things that stop you from doing the smallest changes, and I would say the biggest culprit is that you have to compile the code. In a scripting language:

• I would not need to checkout anything as the installed sources are everything I need.
  
• There would be no "build" rules.
  
• The patch would be done in-place.
  
• There would be no "compilation" step and
  
• There would be no "deploy" step so I can start using the new Hudson right away.

So while I dislike PHP, for example, as it seems too easy to break anything, having a strong typed, compiled language does hinder the desire to do small changes.

Imagine how easy would be to keep your changes in a separate branch (or Mercurial queues) and just rebase once in a while with the upstream codebase, tweak your patch a bit and have the latest running version as well as your changes.

Having everything pluggable is nice, but sometimes it would just be faster to edit the source.

Forget the removable battery, what about the easily removable hard drive? (Get well soon, trusty mac!)

Get well soon, trusty Mac

Last Wednesday my MacBook Pro's display stopped working. Actually, it might be the logic board since the fans do seem to start but nothing else happens: it needs to be sent to an Apple Service. (It could also be that wide-spread NVidia problem MacBook Pros had, who knows).

Anyhow, I had to migrate some data to a new machine I received this morning.

I have bought about a month ago an Intel SSD hard drive so I already knew how to dismantle the laptop. This time I just had to swap the hard drive of the replacement machine with my own SSD drive and I was back to work. Well, one hour later anyhow.

User serviceable

This whole experience made me think how convenient it really is to have user-serviceable components. As laptops basically replace desktops, it's important to be able to access hardware in your laptop.

Actually, not everything is important, there are 2 big things that matter: RAM and hard drive. RAM access is just a nice to have feature since adding more RAM is the best upgrade one could make. CPU and GPU would be nice to have, but not high on my list.

Hard drive access is crucial though, because your work isn't actually on the machine itself.  Your work is just the hard drive. Having swapped the drive into this new laptop I'm back to work just like it's the same machine (if you ignore the annoying German keyboard).

So, it's a bit weird to think about these new MacBooks that are unibody and seem to be harder to dismantle. Taking your machine to a service for a battery or hard drive replacement is odd: in Timisoara this means I have to send it via post 600km to Bucharest, and it's not cheap either.

Plus that all this doesn't take into account the importance of data: I wouldn't want to send my laptop with the work data on it. Even if I were to use FileVault, there is something unsettling about knowing your data is exposed like that.


The right to private data

The right to private data should be as important as the right to privacy. Just because people buy a laptop they shouldn't give away the right to private data. I don't really need a replaceable battery, I don't mind Apple keeping the old battery if they need to replace it. But I need a replaceable hard drive.

So, instead of a removable battery, laptop manufacturers should actually make a removable hard drive. In a few easy steps any user should be able to pop-out his hard drive and then send the empty laptop shell to service worry free.