I heard that you are toying with the idea of trying to be a GitHub-like SaaS yourselves. Why not use GitLab codebase? It’s FLOSS and more important they are not inclined to add BK support to it. So, there is no competition - this is your chance. Though, it’s huge and in Ruby.
Ruby isn’t a problem, so far as I know, but huge is not really fun. We’re focussing first on the basics like
- defining the model (like this is the gate, that’s where you integrate, this is a clone of that gate, etc)
- being able to (optionally) push to a gate without having an account (you shouldn’t need an account for little stuff)
- doing the handshake for pull requests so the gatekeeper has your email
etc. We’ll go a little way and see if we have something useful, if not we’ll punt and go look at Gitlab or some other system.
We’d welcome a laundry list of things that would have to be there before you would be willing to pay for hosting.
Time to market is important too. Microsoft already has it. Perforce already has it. Developing it from scratch could take eons, time is money. There is market for it because GitLab has a bunch of rich enterprise customers. That’s despite that three hundred pounds gorilla called GitHub.
All of Gitlab’s customers are on 2 servers (and I suspect the 2nd is a live mirror, so really one server).
That doesn’t sound like a lot of revenue. Do you have any idea what they make?
No idea. But I suspect that they don’t make money from their public cloud hosting. They are selling support and software for the on premises installations of GitLab EE. And that looks popular for enterprise customers who don’t want to move their assets to public clouds and yet are not satisfied with GitHub offers.
P.S. I should’ve guessed that before. Perforce GitSwarm is built on GitLab. So, a major SCM vendor already went that way.
P.P.S. GitLab also offers githost.io private hosting.
Your main idea is a good one. We need a hosting solution and so we could take one of the existing open source solutions and extend it to support hosting BitKeeper. I had the same idea and did that exercise a while back. When I was looking I discounted GitLab, not because it is huge but because it only supports git. What this means to me is that git’s models for how things are done will be baked pretty deeply into the code. Better in my mind to find a code base that already supports multiple different SCMs. In that case, the code has already needed to be structured to abstract the SCM into a set of different operations and then code different backends for the different models.
When I was looking I was attracted to Kallithea. It already supports Mercurial and Git and the code separates the SCMs into contained backend code that doesn’t look too hard to support. This project is not widely used, but that isn’t really the point if you are looking for something to build on. BTW Kallithea is a fork of RhodeCode.
Phabricator is another option. We looked at that, it pretty much ignores the SCM and stores every cset as a patch and tracks the cset DAG internally. BitKeeper could probably be made to work OK with Phabricator.
That also doesn’t really matter and answers a different question. “Is it worth working on this at all?”
Now I should state the above post is just my personal musing. Larry has his own direction for how to do hosting and will be pursuing that. I am just listing alternative idea ideas that people could look into.
Phabricator is actually a collection of apps, the most important in this case are
arcanist , a couple of notes JFYI:
We looked at that, it pretty much ignores the SCM and stores every cset as a patch and tracks the cset DAG internally.
That’s true about
Differential, i.e. their app for doing code reviews.
Repository hosting is responsibility of
Diffusion and AFAIK it delegates hosting itself to
hg and provides an UI for browsing. That is very likely separated for every SCM, but might depend quite a lot on
hg models as difference between them is less than difference between
And the last piece is
arcanist which is widely-used CLI tool for accessing
Phabricator. It handles sending
revisions to review and also landing them usually with squashing commits, i.e. it knows quite a lot about underlying SCM too.
I’d probably recommend contributing to Kallithea, because it also makes it possible for people to mix and match in the beginning, which allows people to be flexible. Buy-in is much easier when people can migrate at their own pace, or even pick the right tool for the job.
Although not exactly along the lines of GitLab, conceptually I really alike how Fossil has the repo, wiki, tickets, site, etc… all part of the repository itself. And hosting the site/repo/project is very simple, you can use cgi to host from cheap shared hosting. Gogs too seems to be simple to self-host and is clean.
Neither would provide much by way of code, they’re too tightly bound to their SCM, but I like the simplicity they offer.
We had a vision for the same thing, I think we called it software development in a box. The idea was to do the same thing as Fossil, just fire up a bkd and you get all that stuff. We never got there because the commercial people pushed us in different directions (BAM, Nested, etc).