Linus' earlier decision to test the BitKeeper source management tool with the 2.5 kernel tree has continued to create wakes of dissent. One group went so far as to start a petition against the usage of the tool, saying "We, the undersigned members and officers of the Open Source Club at the Ohio State University, are unhappy with the advocacy of the proprietary[1] BitKeeper software for use in maintaining the Linux kernel." Details on the BitKeeper licenses that so many are opposed to can be found here.

The posting of this petition led to a frenzy of replies, in a thread that continues to grow. Many pointed out that the time spent protesting this tool could be much more productively invested into writing an open source alternative of at least equal caliber. All seem to agree that such an alternative does not currently exist.

Towards the end of the many samples from this thread that follow is a reply from Linus, making it clear that he is content using BK himself, but will in no way force it upon anyone else. In his email, he says, "And I personally refuse to use inferior tools because of ideology. In fact, I will go as far as saying that making excuses for bad tools due to ideology is _stupid_, and people who do that think with their gonads, not their brains".

---

From: The Open Source Club at The Ohio State University
To: lkml
Subject: Petition Against Official Endorsement of BitKeeper by Linux Maintainers
Date: 	Tue, 5 Mar 2002 16:52:34 -0500

Petition Against Official Endorsement of BitKeeper by Linux Maintainers

We, the undersigned members and officers of the Open Source Club at
the Ohio State University, are unhappy with the advocacy of the
proprietary[1] BitKeeper software for use in maintaining the Linux
kernel.  The Linux kernel is an important symbol of Open Source and
Free Software for many people, and a project in which many thousands
have participated in active development.  It is fine if some kernel
developers choose to use BitKeeper on their own machines, but
officially endorsing proprietary software as the means of working on
the kernel is a large step backwards for Linux, and for the Open
Source and Free Software communities.

If the core Linux maintainers begin to advocate using BitKeeper, then
there will be strong pressure on these peripheral developers to use
BitKeeper too, since it would likely be easier than browsing the
web-exported changelogs or fetching the latest diff from kernel.org.

Using a closed-source, proprietary source control system for the
kernel is even worse than using other forms of proprietary software
such as source code analysis systems, because the revision control
metadata (version numbers, branches, changelog comments, etc.), would
be stored in a format defined by the proprietary software.  This
metadata is really a part of Linux, because people will want to use it
when talking about the kernel.  Those who can't[2] or don't want to
use BitKeeper are left out in the cold.  One of the most important
parts of Open Source and Free Software is that we, the community, are
in control.  But by using and advocating BitKeeper, we would lose part
of that control.

In summary, please do not advocate BitKeeper for use by the general
community.  The Linux development process seems to have worked up till
now, and we can wait a little longer until Arch[3] or Subversion[4]
are completed.  Moreover, full-featured, completely functional free 
versioning sytems are currently available, such as PRCS[5] and CVS[6].
We respect the kernel maintainer's freedom to use proprietary software 
for their own purposes.  And we ask the kernel maintainers to respect 
the community's freedom from entrapment by proprietary software.

-- The Open Source Club at The Ohio State University
Signed by:
Michael Benedict 
Colin Walters
Matt Curtin
Martin Jansche
Balbir Thomas
Nicholas Hurley
Ryan McCormack
Shaun Rowland

[1] http://www.mit.edu/afs/athena/user/x/i/xiphmont/Public/critique.html
[2] Perhaps they aren't connected to the internet regularly enough,
    for instance.
[3] http://www.regexps.com/#arch
[4] http://subversion.tigris.org
[5] http://prcs.sourceforge.net
[6] http://www.cvshome.org



From: Alan Cox
Subject: Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers
Date: 	Tue, 5 Mar 2002 23:58:06 +0000 (GMT)

Right from the start Linus has always said he isn't going to force anyone
to use bitkeeper. End of story. If you think its free enough -  use it, if
you don't (or you just think its crap software, dont use it)


In fact if it offends you enough to start a petition take the list of
names you get at the end and between you go write a better one under a
licence you prefer between the signatures.

Alan

From: Troy Benjegerdes
Subject: Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers
Date: 	Tue, 5 Mar 2002 16:38:09 -0600

> In summary, please do not advocate BitKeeper for use by the general
> community.  The Linux development process seems to have worked up till
> now, and we can wait a little longer until Arch[3] or Subversion[4]
> are completed.  Moreover, full-featured, completely functional free 
> versioning sytems are currently available, such as PRCS[5] and CVS[6].
> We respect the kernel maintainer's freedom to use proprietary software 
> for their own purposes.  And we ask the kernel maintainers to respect 
> the community's freedom from entrapment by proprietary software.

First, CVS is COMPLETELY inadequate for the kind of distributed, 
non-centralized development that goes on for the kernel.

Bitkeeper solves some rather difficult problems that *NOTHING ELSE SOLVES* 
right now. This is why I've continued to use it for the last 2 years, even 
though I occasionally get annoyed that it's not free software.

Your efforts on this petition would be FAR better spent (and appreciated) 
by attempting to mirror several BK kernel trees with Arch or Subversion. 
You will soon find out the limitations of both, and maybe even improve 
both projects to the point that they will be useable instead of bitkeeper.

Instead of whining about developers using BK, go out and give us an
alternative. Maybe then we will listen.



From: Larry McVoy
Subject: Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers
Date: 	Tue, 5 Mar 2002 16:51:23 -0800

This is great, I was about to type in what Troy said.  I had the same
reaction, if CVS/Subversion/Arch were good enough, BitKeeper wouldn't
exist.  The BitKeeper team is about 75% kernel hackers, not SCM people.
If CVS had been good enough, we would all be doing Linux clusters of
some sort, something we hope to get back some day in the distant future.

Troy is right, instead of writing petitions, spend your time by providing
people with options.  Do what he said, mirror the tree into CVS/etc
and you will very quickly learn why CVS/etc have serious problems.
By learning about those problems, you'll either develop some insight
which will aid you in making CVS/etc better, and you'll develop a healthy
respect for what BitKeeper can do.

As for the replacements mentioned, Subversion in particular, the SVN team
admitted before they started that SVN would certainly not be able to do
what BK can do anytime soon, in fact, they admitted it was unlikely to
ever do so.  The reason for that is that they started with a centralized
design and when you try and distribute that, you learn about the zillions
of places where you needed to make a different choice.  It's virtually
impossible to take a centralized SCM system and make it truly distributed
(a TCP connection back to the one CVS server is *not* distributed).

While you are thinking about replacements, it might help to know the
magnitude of what you are discussing.  BitKeeper is a non-trivial project,
it has:
	* close to 200 commands, with about 800 different options.
	* 25,000 lines of regressions, running the full suite wraps
	  16 bit process ids almost twice.
	* more source code written by the BitMover team than all of
	  Version 7 Unix, kernel and userland combined.
	* a dedicated team of full time professional programmers.
More than a year ago, we had some research done to see what it would cost

to reproduce BitKeeper from scratch.  At that point, it was estimated

to be about $12,000,000 and at least 3.5 years from the time a good

team started.
Anyone and everyone is welcome to try and build a better SCM system, just

don't be naive about what it is you are trying to do.  It's a constant

source of frustration and amusement that people think this space is easy.
From: Kent Borg

Subject: Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

Date: 	Wed, 6 Mar 2002 09:54:34 -0500
On Tue, Mar 05, 2002 at 04:51:23PM -0800, Larry McVoy wrote:

> BitKeeper is a non-trivial project, it has:

> 	* close to 200 commands, with about 800 different options.
When I was recently doing some PPC work I used Bitkeeper (because PPC

folks do) and I didn't like it.  It was so complicated to use, hell,

seemed like there were 200 commands with 800 options.  And when I

couldn't get it to correctly export a tree I couldn't tell if I was
doing it wrong or it was a bug.
I can appreciate that the problem BK tries to solve is a big one with

subtleties that have to get done right, and, as I type this on my

notebook sitting in front of my work computer, I wish CVS were

distributed.  But I am not convinced BK is as elegant in its design as

it could be, I *know* it is not as elegant in its user interface as it

could be.
I also dislike the irony of BK being proprietary.  Sure, they might

have an enlightened and generous attitude not, but PGP used to be

free, then it became kinda free and then it became orphaned.  Luckily

GPG came along, luckily PGP didn't have a monoploy on our history.
From: Larry McVoy

Subject: Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

Date: 	Wed, 6 Mar 2002 08:56:46 -0800
On Wed, Mar 06, 2002 at 09:54:34AM -0500, Kent Borg wrote:

> When I was recently doing some PPC work I used Bitkeeper (because PPC

> folks do) and I didn't like it.  It was so complicated to use, hell,

> seemed like there were 200 commands with 800 options.  And when I

> couldn't get it to correctly export a tree I couldn't tell if I was

> doing it wrong or it was a bug.
And apparently you didn't file a bug because I just looked in the bug

database.  Was typing "bk sendbug" too difficult?
> I can appreciate that the problem BK tries to solve is a big one with

> subtleties that have to get done right, and, as I type this on my

> notebook sitting in front of my work computer, I wish CVS were

> distributed.  But I am not convinced BK is as elegant in its design as

> it could be, I *know* it is not as elegant in its user interface as it

> could be.
There are *lots* of things in BK that aren't as good as they could be.

If you want them better, you need to complain about them.
> I also dislike the irony of BK being proprietary.  Sure, they might

> have an enlightened and generous attitude not, but PGP used to be

> free, then it became kinda free and then it became orphaned.  Luckily

> GPG came along, luckily PGP didn't have a monoploy on our history.
PGP didn't have a business model, we do, and part of our business model

is to give it away to some of the world.  It's a good business model,

BK is dramatically better because the PPC team used it and Cort went

through all sorts of stuff as BK improved.  BK would easily be a year

back in terms of usefulness if it weren't for Cort and there is no way

he would have been using it if we charged for it.  We get something by

letting people use it for free.  It's part of our business model and

it works.
From: Pavel Machek

Subject: Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

Date: 	Wed, 6 Mar 2002 23:13:05 +0100
Hi!
> > I also dislike the irony of BK being proprietary.  Sure, they might

> > have an enlightened and generous attitude not, but PGP used to be

> > free, then it became kinda free and then it became orphaned.  Luckily

> > GPG came along, luckily PGP didn't have a monoploy on our history.

>

> PGP didn't have a business model, we do, and part of our business model

> is to give it away to some of the world.  It's a good business model,

> BK is dramatically better because the PPC team used it and Cort went

> through all sorts of stuff as BK improved.  BK would easily be a

> year
So you basically give bk for free because it is good for you. What if

it will stop being good for you ten years from now?
Also it would be nice to apt-get install bk, but your license probably

means we'll not see it in debian any time soon. (Should check, but do

other vendors distribute bk?)

									Pavel
From: Troy Benjegerdes

Subject: Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

Date: 	Thu, 7 Mar 2002 10:17:01 -0600
On Wed, Mar 06, 2002 at 11:13:05PM +0100, Pavel Machek wrote:

> So you basically give bk for free because it is good for you. What if

> it will stop being good for you ten years from now?
Then we move on to another system. This is why I think we need some kind

of gateway to another SCM. If BK goes away, we could export everything to

tarballs and patches or whatever, but it would be a large PITA, and stop

lots of people's development for awhile. (I've done bk->cvs this way once

before, it was really ugly, and I never want to do it again given the

choice).
I'd really like everyone that's bitching about BK to shut the hell up and

go work on some scripts to allow a maintainer to easily manage a

BK<->$OTHER_SCM gateway. Either give me a working alternative to BK or go

run for political office. Until I see an alternative, I'm going to

continue advocating for real developers to use BK, and complainers to show

me an alternative.
From: Andrew Morton

Subject: Re: Petition Against Official Endorsement of BitKeeper by Linux  Maintainers

Date: 	Thu, 07 Mar 2002 11:54:43 -0800
Troy Benjegerdes wrote:

>

> I'd really like everyone that's bitching about BK to shut the hell up and

> go work on some scripts to allow a maintainer to easily manage a

> BK<->$OTHER_SCM gateway.
ie: "We broke it.  You fix it".
It's not reasonable to expect people who shall not be using bitkeeper

to go off and perform enhancements to bitkeeper so that they can

continue to be effective kernel developers.
If bitkeeper proves to be significantly disadvantageous to non-bitkeeper

developers then it simply is not appropriate that bitkeeper be used

for kernel development at all.
If additional development around bitkeeper is needed then the onus

is upon the bitkeeper side to do that work.  (And yes, there are

sides now).
That being said, I don't see any need for additional development,

unless people actually want increased functionality over that

which we've traditionally had.  Things generally will appear to

be unchanged for non-bitkeeper users because Linus will continue

to push out the regular prepatches.  This *has* to be done anyway,

so the testers can get at the tree promptly.
Also. The things being discussed here *matter* to some people.  Some

of the comments made by Larry, David, Cort, Rik and others have

coarsely sought to deligitimise the very reasons why a significant number

of kernel contributors and users are here at all.  Those comments

are monumentally insulting.
From: Larry McVoy

Subject: Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

Date: 	Thu, 7 Mar 2002 12:15:09 -0800
It's also "monumentally insulting" to be asking for BitKeeper to be able

to do what it already can do, exactly for the reasons you outlined.

We have done piles and piles of work to make sure that we can export

and import patches, so that if you want, your work habits do not change

one iota.  We did all that work.  It's done.  It's in the system.

Linus uses both import and export.  And we continue to fix things as it

becomes apparent that they need to be fixed.  We're busting our asses to

keep you happy and we get flamed.  And the flamers seem to think that

we are getting some great financial benefit by having the kernel crowd

use BK.  It's certainly true that BK is improving because the kernel

crowd demands enhancements.  It's not true that that has turned into

any financial benefit to us, we haven't made a single sale as a result

of Linus using BK.  That's OK, that's not why we did it.  But don't use

that as a justification to beat us up, it's simply not true.
The thing that seems to escape you is that BK came into existence because

I was scared to death of Linus burning out.  I still am.  I see no Linus

replacement on the horizon.  BK exists because I hope it will make him

able to last longer as the leader here, I do not foresee good things

happening if he goes away.  Our goal is to get him more relaxed.  Try and

remember that we are trying to help.  You can hate the fact that BK isn't

open source, I don't blame you one bit.  If I had stayed at Cobalt and

cashed out my millions, BitKeeper would be open source.  But I didn't.

So it isn't.  Get over it.  It can help now, we're trying to help now,

we make it easy to get out of BK, so if/when a better open source answer

arrives, you can get out.  What more can you possibly ask for?  I'm giving

you an answer which helps, with no lock in, and the most extensive set of

tools designed to make it so you can get out with all of your data intact.

And you say you are insulted.  I'm not sure it is you who should be insulted.

From: Rik van Riel

Subject: Re: [opensource] Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

Date: 	Thu, 7 Mar 2002 19:17:48 -0300 (BRT)
On Thu, 7 Mar 2002, michael bernstein wrote:
> Last time I checked, it didn't matter if a person had "cashed out

> their millions" for a program to go opensource.  So fucking what.

>

> Serve others, not yourself.
Larry is doing us all a service by getting bitkeeper the

funding it needs to improve at the rate it has.
If the program had to survive as an open source program

without several people working on it full-time, I bet

many of the boring but necessary tasks still wouldn't

have been done ...
Source control just isn't one of those sexy things that

everybody wants to work on and on top of that it's deep

magic most people (especially me) can't figure out. ;)
regards,
Rik

From: Alan Cox

Subject: Re: [opensource] Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

Date: 	Thu, 7 Mar 2002 23:21:14 +0000 (GMT)
> programs coming out.  The Gimp, for one, was written by students at

> Berkeley.  Last time I checked, no one was making money off of

> enlightenment, and they are all still poor.  Stop fucking whining about 
Thats their planning. Some of them made poor business decisions, some of

them joined the wrong companies. If you think that being poor and suffering

are good for the soul there are a wide collection of religious orders to

choose from most of whom are full of people doing a lot more useful things

that whining on a mailing list
> it and stop compromising your ideals for money.  Also, before you can 
I have a better idea - its called keeping your ideals and making some

money 8) I've done that in the open source world both before and as part

of Red Hat. 
I've also had long talks with Larry and I agree with him about the BK stuff.

There are certain places where open source does not work well for business

models - Bitkeeper is IMHO -not-  commodity [Yet...]
Alan

From: Cort Dougan

Subject: Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

Date: 	Thu, 7 Mar 2002 13:50:43 -0700
We're here to discuss kernel development, right?  Not debate software

ideologies.
I move the PPC tree over to BitKeeper and it was worthwhile.  I made

rsync updates and plain old 'diff' patches against Linus' tree available

nightly.  It was easy and very quick to do that, I had it running for

nearly 2 years very well.  In fact, you can still grab the patches from

ftp://ftp.kernel.org/pub/linux/kernel/people/cort/.  What is your problem with BK

apart from the license religion?  Linus has made it clear he'll provide

patches in the same old style.  I don't see what you think you lose here.

The gain for people who ship him patches is well worth it.  Before I handed

the PPC tree over to Paul I would have killed to get Linus to use BK so

shipping him patches would be easier for everyone involved.  If I were

still a maintainer my response would be a lot less mild to those people

that fight against BK on something so intangible as "feelings" about the

license.  I put in a lot of hours shipping patches that were for nothing,

BK is helping avoid that for the current crew.
Seriously, what is your problem with BK?  What do you feel that you lose?
From: Rik van Riel

Subject: Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

Date: 	Thu, 7 Mar 2002 18:12:33 -0300 (BRT)
The development speed and code quality of -rmap have also gone

up as a consequence of moving over to bitkeeper.
Merging patches up to a new version of the kernel has gone from

tiring (with patch and vi) to almost relaxing (with bitkeeper's

automatic and graphical 2-way merge tools)...
This in turn has allowed me to spend my time and energy on

improving the code, without having to fear large patches and

the maintenance those require.
regards,
Rik

From: Andrew Morton

Subject: Re: Petition Against Official Endorsement of BitKeeper by Linux  Maintainers

Date: 	Thu, 07 Mar 2002 13:23:35 -0800
Troy Benjegerdes wrote:

> > ie: "We broke it.  You fix it".

> >

> > It's not reasonable to expect people who shall not be using bitkeeper

> > to go off and perform enhancements to bitkeeper so that they can

> > continue to be effective kernel developers.

>

> No. Try:

> "You're whining, here's how fix it, because I don't have time or

> motivation"
Let's be clearer:
- If bitkeeper makes non-bitkeeper developers less effective than

  they traditionally have been then Larry gets to fix that.
- If non-bitkeeper users want *additional* functionality over what

  has traditionally been available then they get to implement it.
And Linus will keep pushing prepatches in the time-honoured

manner, so there's no loss in non-bk users effectiveness.
> Larry went to a lot of trouble to listen to what kernel developers

> wanted, and a lot of work to implement some of it. I expect same courtesy

> of everyone who is complaining.
I don't think anyone has been criticising bk featureset or reliability.

A few performance mumblings, maybe. It seems to be a fantastic piece

of software.
But that's not the point!   Nobody, repeat nobody is happy with the

licensing thing.  For some people, the day-to-day benefits outweigh

the philosophical concerns.  For others they do not.  That is what is

being discussed here.
I see two things being discussed here:
1: I don't want bitkeeper use to *decrease* my ability to do Linux

   work.  Linus will continue to push patches at the same rate, so

   I have no problem.  I'm OK with others using bitkeeper.  EOT.
2: Kernel has a leading role in free software development. Other

   people do not want kernel's use of bitkeeper to weaken that

   movement.
   Me, I don't think the "movement" is weak enough for damage to

   come about.  And SCM is a space where the free tools are weak.

   It's a once-off special-case and it's hard to see how anything

   bad will come about from it.
> If Larry can make good on his 'threat' to write a read-only cvs pserver

> interface to BK, I think he's done his part. (BK -> $OTHER_SCM)
Well that would be icing on the cake.  But I don't believe it's

reasonable to expect bitmover to provide non-bitkeeper users

with *more* stuff than they have traditionally had.
That being said, the adoption of bitkeeper does reduce the

chances of non-bitkeeper users from ever getting more features,

but realistically, that would never have happened anyway.
And the non-bitkeeper users *do* have more than they used to

have - the web logs and changelogs.  That's nice.  It'd be

nicer if the web interface was more up-to-date, but I am told

that's a person thing, not a tool thing.

From: Linus Torvalds

Subject: Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

Date: 	Thu, 7 Mar 2002 19:18:15 +0000 (UTC)
Pavel Machek wrote:

>So you basically give bk for free because it is good for you. What if

>it will stop being good for you ten years from now?
Guys, calm down.
A few points:
 - I certainly don't require BK use of anybody.  It makes my life

   simpler with some people (mainly the ones that tend to be maintainers

   of subsystems and send me lots of patches), but there are many

   developers who do NOT use BK, and it doesn't slow them down at all. 
   For example, see the FS patches from Al Viro: the only thing that BK

   has resulted in as far as Al is concerned is that the changelogs are

   a lot better and include his email comments. 
   And I also export my tree as regular patches, the way I always have

   (well, the actual format changed subtly, but that's purely syntactic)
 - If Larry turns to the dark side (or, as some would say, the "even

   darker side" ;) we're _still_ ok. The data isn't going anywhere, he

   can't close that down. We'd just have to export it into a new format.
   If worst comes to worst, and nobody has fixed CVS/subversion/whatever

   by then, I can even just go back to how I used to work. Nothing lost.
 - If people in the open-source SCM community wake up and notice that

   the current open-source SCM systems aren't cutting it, that's _good_.

   But it's absolutely NOT an excuse to use them today.  Sorry.  I use

   CVS at work, and I could never use it for Linux.  I took a look at

   subversion, and it doesn't even come close to what I wanted. 
   And I personally refuse to use inferior tools because of ideology. In

   fact, I will go as far as saying that making excuses for bad tools

   due to ideology is _stupid_, and people who do that think with their

   gonads, not their brains. 
In short: nobody requires BK of anybody else.  A lot of people really

like using it, though, and it does make some things easier.  Some people

aren't convinced - David Miller is trying it out, and I haven't heard

all happy sounds from him about it. Others have taken to BK like fish to

water, and you'll pry it out of their dead cold hands.
The most productive thing people could do might be to just do a BK->CVS

gateway, if you really feel like it.  Or just go on and ignore the fact

that some people are using BK - you don't actually have to ever even

know. 
		Linus

And inevitably in response to Linus' long public ideological stance against kernel debuggers:
From: george anzinger

Subject: Re: Petition Against Official Endorsement of BitKeeper by Linux  Maintainers

Date: 	Thu, 07 Mar 2002 12:12:37 -0800
Linus Torvalds wrote:

>    And I personally refuse to use inferior tools because of ideology. In

>    fact, I will go as far as saying that making excuses for bad tools

>    due to ideology is _stupid_, and people who do that think with their

>    gonads, not their brains.
Does this mean you will admit kgdb into the tree?  
(Sorry, I couldn't help myself :-)
-g
From: Jeff V. Merkey

Subject: kernel debuggers (was Bitkeeper Bashing)

Date: 	Thu, 7 Mar 2002 14:37:07 -0700
>    And I personally refuse to use inferior tools because of ideology. In

>    fact, I will go as far as saying that making excuses for bad tools

>    due to ideology is _stupid_, and people who do that think with their

>    gonads, not their brains. 
Linus,
A reasonable explanation.  However, this begs the question as to

**WHY** you are so opposed to kernel debuggers in Linux.   Code

reviews don't catch hardware bugs or other types of performance

issues related to bus architecture, etc.
Opposition to a kernel debugger in Linux, at least from the

view of some folks, is a case of someone using inferior methods

because of ideaology.  
Not meant as a recrimination, but you've just made the case for

kernel debuggers in Linux.
:-)
Jeff

---

Those wishing to read more of this debate can follow the lkml thread in an online archive. (For example, the thread starts here or here.)

Find some interesting history on LWN, with this page from 1998 and this page from 1999.

A more recent debate on Slashdot regarding Linus' decision to test BitKeeper can be found here.