Following up after a day in the shop

Following up after a day in the shop

I agree entirely with the need for BK to be proprietary. I have no doubt that it is ahead of everything else due to having a full-time team of really good people. OSS can get full-time paid developers, but it doesn't tend to happen until a project is as big as Linux or Apache. I'd guess that someday arch will reach the point of being important enough to enough major projects that it will get enough development effort to surpass BK, but I'd bet that you and your current team will retire before then. Ironically, I think that the existance of people prohibited from using BK forces projects to use arch instead, and that gives arch market share and attention, meaning that it improves more quickly. If anyone could use BK, I bet arch would progress about as quickly as Hurd, and nobody but Tom Lord and RMS would really care about it.

On the other hand, I doubt that a competitor could learn anything significant from using BK. Actually, that's not quite true. I doubt that a competitor could learn anything more from personally using BK than from reading Documentation/BK-usage and similar documents. I'm fairly certain that everything that is really clever about BK would require as much effort to identity as something that could be reverse-engineered from BK as it did to work it out in the first place. You are, after all, constantly having to tell people that there are hard problems in version control; these people are hardly going to identify the hard problems and the solutions to them simply be using a tool which hides from the user just how hard the problems are. Linus has, at this point, used BK probably more intensely than anyone who doesn't work for BM (and quite possibly anyone who does). Linus is good enough to write a C compiler just because it seems like a good idea. Linus clearly cares a lot about version control and having it work right. But Linus hasn't decided to write his own version control system. Chances are that, if he hasn't done it, nobody else will.

A number of years ago, I used Purify from Rational. It was pretty easy to tell what it was doing from what it produced (plus, there were whitepapers provided which explained a bit more). On the other hand, there was absolutely no danger of anyone reverse=engineering and reimplementing it from using it (Years later, valgrind came out, which has a similar effect but using a very different method). Rational was perfectly willing to let whoever wanted to buy and use Purify to work on whatever they wanted. For that matter, they even gave me tech support, despite me using a trial license at a point when my employer's license hadn't been renewed (they were fanatical about the quality of the software; I was just telling them that -fomit-frame-pointer should be mentioned as a reason you can't debug a program; they wanted to make it work for my case). As far as I can tell, Rational did well on Purify. So there's at least that example of a successful model: let anyone of no commercial significance use your software for free; let anyone whose budget is noticable buy a license for a lot of money; don't worry about the competition. Just focus on getting as many people as possible, whoever they are, to pay you and your developers.

With 20/20 hindsight, I bet Google would now be even more thrilled with BK developed at Google and released under the GPL than they are with Orkut. Too bad there wasn't any way at the time to know it would work out that way...