Sunday, April 10th, 2011
“If Mercurial is so awesome, why doesn’t someone make HgHub?”
If your company’s mission statement is “like X but for Y” you’re in trouble. There’s nothing in there that will inform the thousands of decisions you’ll make about your product in the future. You’ll be simply copying X over and over again — forever a clone.1
Truth be told, Git is probably the least interesting part of GitHub. In fact, GitHub will probably still be around when the next generation version control systems appear, and GitHub’s mission — embodied in statements like “GitHub is the best way to collaborate with others” and “GitHub: Social Coding” — will lead them smoothly into the future.
My advice to someone interested in creating another Mercurial-based tool for code hosting2 would be to examine GitHub’s features and see what you think you could do better. What gaps are there in GitHub’s offerings? What class of users are served poorly by GitHub?3 How can you reduce the costs of switching to your service? Are those people going to be willing to pay you money? If you can answer these questions — and decide to use Mercurial for the basis for your system — you’ll be well on your way to developing a serious GitHub competitor.
However, “like X for Y” is a reasonable place to start brainstorming — it can help you to identify Ys that are underserved by X — but it’s often not enough to support an entire product. ↩
My own personal sore spot with GitHub is its pricing structure. As a software consultant, I have a ton of repositories that need to be private but many of which I won’t come back to for ages, if ever. GitHub’s pricing structure, where the more private repositories you have the more you pay, isn’t a good value for me. ↩