The kernel and BitKeeper part ways
Posted Apr 7, 2005 6:33 UTC (Thu) by ekj
Parent article: The kernel and BitKeeper part ways
Larry just does not get it. And for once I think our editor is being overly nice to him.
A person working on developing a good, scalable, capable SCM is not in any way a "Bad apple". Even if he does so by reverse engineering a closed product the license disallowing, or attempting to disallow reverse engineering is the "bad apple". Indeed in many jurisdictions such a clause in a license is void.
Also, BitKeeper was very likely the best choise at the time, probably still is. But there's a second effect: choosing BitKeeper over one of the free tools has helped BitKeeper develop faster and that other free tool develop slower. Like you say: hosting the kernel is a wonderful way of shaking out bugs and scalability issues.
So, in other words, choosing some other free (as in speech) tool back then likely would've made the kernel-development somewhat slower, atleast initially, but on the other hand would've ensured that that tool improved quicker. It's not clear that this is such a clear win.
Furthermore -- on several points the critics have just been prooved rigth: Choosing a closed tool *does* give a single comercial entity the rigth to pull the rug out from under us at their discretion. One of the benefits of free software is precisely *not* to be in a situation where that can happen.
I think the whole thing is good, overall. Not because BitKeeper has helped us so much, but because it has showed a lot of people (including Linus) that sometimes free matters. I *very* much doubt that Linus would even consider a hypotetical new closed SCM with the same licence BitKeeper had when he once choose that.
to post comments)