Comment by to3m
10 years ago
1 year ago: https://news.ycombinator.com/item?id=9330482
What changed? Is BitKeeper still an ongoing business with some other model, or is that, as they say... it? I hope not.
10 years ago
1 year ago: https://news.ycombinator.com/item?id=9330482
What changed? Is BitKeeper still an ongoing business with some other model, or is that, as they say... it? I hope not.
This is to answer this question and all the "too late" comments.
Too late? Maybe. But we had a viable business that was pulling in millions/year. The path to giving away our stuff seemed like:
And still does. So what changed? Git/Github has all the market share. Trying to compete with that just proved to be too hard. So rather than wait until we were about to turn out the lights, we decided to open source it while we still had money in the bank and see what happens. We've got about 2 years of money and we're trying to build up some additional stuff that we can charge for. We're also open to being doing work for pay to add whatever it is that some company wants to BK, that's more or less what we've been doing for the last 18 years.
Will it work? No idea. We have a couple of years to find out. If nothing pans out, open sourcing it seemed like a better answer than selling it off.
My $0.02 canadian; Build something that kicks Gitlab and Github's ass. What an opportunity. Support both BK and GIT repos. Provide a distributed workflow that enterprises will love. Enterprises are obviously where the remaining dollars are. There are billions of dollars of inefficiencies in that sector. Many of these enterprises do NOT want to host their code on Github and are buying Gitlab. Be better than Gitlab.
Github sucks for corporate version control, it's just not designed for the kind of strict role-based change control that enterprise needs. Great support though.
I haven't checked out Bitbucket because last time I evaluated (2+ years ago) they didn't have good on-prem options.
^^ this. PLEASE. :-(
Bitbucket has been rotting since Atlassian bought them, and now there's really no "killer app" for Mercurial hosting. There are Mercurial hosting services out there, but nothing anywhere close to Github/Gitlab.
4 replies →
At GitLab we're unlikely to support BK due to lack of demand. What do you mean with a distributed workflow, something like https://gitlab.com/gitlab-org/gitlab-ce/issues/4084 ?
Great comment. Good points. Also - for enterprise, it's OK if the model ends up being a bit simpler than git - may actually be a positive. Give up some things, but get simplicity that scales to a 1,000 folks using some old VCS.
Looking forward to some hopefully differentiated features.
Just supporting big binary files in a hassle-free way would go a huge way to being better than Git and Gitlab.
1 reply →
As someone who's also read about how Git and Mercurial started (and how Bitkeeper is involved in it), I'm interested in seeing how it will play out. I hope it does work out for you and your team. Thanks for getting it out there.
I'm also interested how open-sourcing BK will improve the other systems, too.
> I'm also interested how open-sourcing BK will improve the other systems, too.
#mercurial in Freenode right now is monitoring this thread, very relevant to our interests.
Someone at Facebook in #mercurial right now is trying it on some Facebook repo, to compare performance.
2 replies →
Thanks for providing this level of detail; it's interesting to see the considerations that went into your decision.
How / why did you decide to use the Apache license rather than the GPL?
(It seems like a viral license might protect you a little bit, if you want to prevent your competitors from forking and improving your code base and then using it to compete against you.)
We decided to go all in on open source. Given our history, anything but a "here ya go" license wasn't going to go over well. We're aware that someone could fork it and compete against us, good on them if they can. Making money in this space isn't easy and if they can do better than us we'll ask 'em for a job. We know the source base :)
As to why that license, I think it was because LLVM or clang or both had recently picked that and all the lawyers at all the big companies liked that one. We don't particularly care, if everyone yells that it should have been GPL we'll fork it and relicense it under the GPL. Our thought was that Apache is well respect and even more liberal than the GPL but we can be convinced otherwise.
6 replies →
Here's my dream DVCS: easily self-hostable like Fossil, but with good wiki and ticketing system. (Fossil's wiki and ticketing system are awful, but what really sunk it for me was its unexpected behavior for basic commands like "fossil rm".)
I'm just not super-fond of relying on Bitbucket, reliable though they've been, for hosting my stuff.
But a package I could toss on my own VPS? I'd toss some money at that. Wouldn't even need it to be open-source, but I'm no zealot.
> Fossil's wiki and ticketing system are awful
Care to be more specific?
I'll grant that Fossil's wiki is not a competitor to MediaWiki, but that doesn't make it "awful." It just makes it less featureful. So, what feature do you need in a wiki that Fossil's wiki does not provide?
As for the ticketing system, again, it isn't going to replace the big boys out of the box, but it also doesn't have to match them feature-for-feature to be useful. Also, the Fossil ticketing system's behavior is not fixed: it can be modified to some extent to behave more like you need. Did you even try modifying its behavior, or are you just complaining about its out-of-the-box defaults? Be specific!
> unexpected behavior for basic commands like "fossil rm".
If you mean that you want fossil rm to also delete the checkout copy of the file in addition to removing it from the tip of the current branch, and you want fossil mv to rename the checkout copy in addition to renaming it in the repository, then you can get that by building Fossil with the --with-legacy-mv-rm flag, then setting the mv-rm-files repository option. You can enable it for all local Fossil repositories with "fossil set mv-rm-files 1".
Alternately, you can give the --hard flag to fossil mv and fossil rm. That works even with a stock binary build of Fossil.
> I'm just not super-fond of relying on Bitbucket
For some of us, relying on a cloud service just isn't an option. We're willing to give up many features in order to keep control of our private repositories.
> a package I could toss on my own VPS? I'd toss some money at that.
Fossil runs great on a VPS, even a very small one, due to its small footprint. I wrote a HOWTO for setting it up behind an nginx TLS proxy using Let's Encrypt here:
https://www.mail-archive.com/fossil-users@lists.fossil-scm.o...
3 replies →
i think that bitkeeper could fill in the enterprise niche (like perforce or clearcase) - very big organisations with a lot of developers don't like it that every developer can check out the whole source tree. They usually like to have access control by department/group. Also stuff like 'read only access' or 'right to commit' can be added for greater bureaucratic bliss.
There is plenty of people doing "lets turn opensource and blame the community if does not work" arround.
It's a good excuse to blame that opensource broke your business, and that opensource could not save you from dying...
A South Park reference, ehe?
Well clearly in retrospect, step two should have been renaming it "Dawson's Creek Trapper Keeper Ultra Keeper Futura S 2000" [1], adding incredibly advanced computerized features including a television, a music player with voice recognition, OnStar and the ability to automatically hybrid itself to any electronic peripheral device, absorbing the secret military computer at Cheyenne Mountain, and taking over the world.
[1] https://en.wikipedia.org/wiki/Trapper_Keeper_(South_Park)